Restore the original code, where VHOST_SET_OWNER is applied to
all vhostfds of the device.
Fixes: 06856cabb8 ("net/virtio: add virtio-user ops to set owner")
Cc: stable@dpdk.org
Signed-off-by: Thierry Herbelot <thierry.herbelot@6wind.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
This patch adds the configuration of fixed speed for the PF device.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
If the flow control auto-negotiation is not supported and the flow
control modes on the local and link partner is asymmetric, the flow
control on the NIC does not take effect. The support of the
auto-negotiation capability requires the cooperation of the firmware
and driver.
This patch supports the flow control auto-negotiation only for copper
port. For optical ports, the forced flow control mode is still used.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
This patch supports link speed auto-negotiation for PF. If the
device supports auto-negotiation, the device negotiates with
the link partner at all speeds supported by the device.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
The speed capability of the device can be reported to the upper-layer app
in rte_eth_dev_info_get API. In this API, the speed capability is derived
from the 'supported_speed', which is the speed capability actually
supported by the NIC. The value of the 'supported_speed' is obtained
once in the probe stage and may be updated in the scheduled task to deal
with the change of the transmission interface.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, the speed of fiber port is obtained by using the default
query type of HNS3_OPC_GET_SFP_INFO opcode. In this way, only
the speed of the optical module can be obtained. In fact, the opcode
also supports an active query type, which is a channel for obtaining
information such as the speed, the supported speed, auto-negotiation
capability, and FEC mode. This patch changes the query type of the
opcode from the default query type to the active query type to obtain
the supported speed of fiber port.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
The firmware compatibility configuration in PF driver is used to
maintain the compatibility of some features of the driver and
firmware, and requires firmware to enable these features. Currently,
the configuration is in hns3_init_hardware(), which is a little back.
Because firmware may clear some configurations (such as, MAC related)
after receiving the command. And firmware can not be aware of some
default initializations (such as, flow control) before executing the
command to set the copper PHY when the PHY is controlled by firmware.
Therefore, it is recommended that no other hardware resources are
configured before the compatibility configuration. And it should be
moved to hns3_cmd_init(), which is responsible for the firmware
command initialization of driver.
In addition, the driver needs to perform corresponding processing
if the command fails to be sent.
1) If firmware fails to take over the copper PHY, the copper port fails
to initialize.
2) If fails to enable the report of link events, the device does not
support the LSC capability.
Fixes: bff6ebfe30d4 ("net/hns3: refactor PF LSC event report")
Fixes: bac6a06441 ("net/hns3: fix link status change from firmware")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, hns3 driver doesn't support to flow control auto-negotiation.
The FC mode requested by user is the same as the current FC mode. It is
not necessary to maintain the current FC mode. We only report the current
FC mode based on actual flow control mode in hns3_flow_ctrl_get().
This patch removes this redundant field. In addition, "requested_mode" in
hns3_hw struct indicates the FC mode requested by user, and the name is
unreasonable. It needs to be modified to "requested_fc_mode".
Fixes: 62e3ccc2b9 ("net/hns3: support flow control")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
The bit(5) of supported, advertising and lp_advertising for copper
PHYs obtained from the firmware indicates 1000M full-duplex. This
speed capability bit is missing in the current codes.
Fixes: 2e4859f3b3 ("net/hns3: support PF device with copper PHYs")
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
The "supported capability" obtained from firmware on copper ports
includes the speed capability, auto-negotiation capability, and flow
control capability. Therefore, this patch changes "supported_capa" to
"supported_speed" and parses the speed capability supported by the
driver from the "supported capability".
Fixes: 2e4859f3b3 ("net/hns3: support PF device with copper PHYs")
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
In the previous patch, driver will calculate packet type by ignoring
VLAN information because the packet type may calculate error when
exist VLAN and VLAN strip.
So here remove the following ptypes from support list:
1) RTE_PTYPE_L2_ETHER_VLAN
2) RTE_PTYPE_L2_ETHER_QINQ
3) RTE_PTYPE_INNER_L2_ETHER_VLAN
4) RTE_PTYPE_INNER_L2_ETHER_QINQ
Fixes: bba6366983 ("net/hns3: support Rx/Tx and related operations")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Kunpeng 930 supports RXD advanced layout. If enabled the layout, the
hardware will report packet type by 8-bit PTYPE filed in the Rx
descriptor, and the supported ptypes are different from original
scheme. So this patch adds supported list for RXD advanced layout.
Fixes: fb5e906940 ("net/hns3: support Rx descriptor advanced layout")
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
The PTP depends on special packet type reported by hardware which
enabled rxd advanced layout, so if the hardware doesn't support rxd
advanced layout, driver should ignore the PTP capability.
Fixes: 4387523581 ("net/hns3: get device capability from firmware")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
This patch supports reporting TUNNEL GRE packet type when rxd advanced
layout enabled.
Fixes: fb5e906940 ("net/hns3: support Rx descriptor advanced layout")
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
This patch adds RTE_PTYPE_L4_UDP flag when parsed tunnel vxlan packet.
Fixes: bba6366983 ("net/hns3: support Rx/Tx and related operations")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
The type of return value of hns3_cmd_send is int, some function declare
the return value as hns3_cmd_status.
This patch fix the incorrect use of the enum hns3_cmd_status.
Fixes: 737f30e1c3 ("net/hns3: support command interface with firmware")
Fixes: 02a7b55657 ("net/hns3: support Rx interrupt")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, when processing MBX messages, the system timestamp is obtained
to determine whether timeout occurs. However, the gettimeofday function
is not monotonically increasing. Therefore, this may lead to incorrect
judgment or difficulty exiting the loop. And actually, in this scenario,
it is not necessary to obtain the timestamp.
This patch deletes the call to the gettimeofday function during MBX
message processing.
Fixes: 463e748964 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
VF will build two queues (csq: command send queue, crq: command receive
queue) with firmware, the crq may contain the following messages:
1) mailbox response message which was the ack of mailbox sync request.
2) PF's link status change message which may send by PF at anytime;
Currently, any threads in the primary and secondary processes could
send mailbox sync request, so it will need to process the crq messages
in there own thread context.
If the crq hold two messages: a) PF's link status change message, b)
mailbox response message when secondary process deals with the crq
messages, it will lead to report lsc event in secondary process
because it uses the policy of processing all pending messages at once.
We use the following scheme to solve it:
1) threads in secondary process could only process specifics messages
(eg. mailbox response message) in crq, if the message processed, its
opcode will rewrite with zero, then the intr thread in primary
process will not process again.
2) threads other than intr thread in the primary process use the same
processing logic as the threads in secondary process.
3) intr thread in the primary process could process all messages.
Fixes: 76a3836b98 ("net/hns3: fix setting default MAC address in bonding of VF")
Fixes: 463e748964 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, the mailbox synchronous communication between VF and PF use
the following fields to maintain communication:
1. Req_msg_data which was combined by message code and subcode, used to
match request and response.
2. Head which means the number of requests successfully sent by VF.
3. Tail which means the number of responses successfully received by VF.
4. Lost which means the number of requests which are timeout.
There may possible mismatches of the following situation:
1. VF sends message A with code=1 subcode=1.
Then head=1, tail=0, lost=0.
2. PF was blocked about 500ms when processing the message A.
3. VF will detect message A timeout because it can't get the response
within 500ms.
Then head=1, tail=0, lost=1.
4. VF sends message B with code=1 subcode=1 which equal message A.
Then head=2, tail=0, lost=1.
5. PF processes the first message A and send the response message to VF.
6. VF will update tail field to 1, but the lost field will remain
unchanged because the code/subcode equal message B's, so driver will
return success because now the head(2) equals tail(1) plus lost(1).
This will lead to mismatch of request and response.
To fix the above bug, we use the following scheme:
1. The message sent from VF was labelled with match_id which was a
unique 16-bit non-zero value.
2. The response sent from PF will label with match_id which got from the
request.
3. The VF uses the match_id to match request and response message.
This scheme depends on the PF driver, if the PF driver don't support
then VF will uses the original scheme.
Fixes: 463e748964 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, driver will copy mailbox messages body into arq ring when
process HNS3_MBX_LINK_STAT_CHANGE and HNS3_MBX_LINK_STAT_CHANGE
message, and then call hns3_mbx_handler API which will direct process
pre-copy messages. In the whole process, the arq ring don't have a
substantial effect.
Note: The arq ring is designed for kernel environment which could not
do much job in interrupt context, but for DPDK it's not required.
Also we rename hns3_handle_link_change_event to
hns3pf_handle_link_change_event which add 'pf' suffix to make it
better to distinguish.
Fixes: 463e748964 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Add a specific path for RX AVX512 (flexible descriptor).
In this path, support the HW offload features, like,
checksum, VLAN stripping, RSS hash.
This path is chosen automatically according to the
configuration.
'inline' is used, then the duplicate code is generated
by the compiler.
Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
Acked-by: Qi Zhang <qi.z.zhang@intel.com>
Add a specific path for RX AVX512 (traditional).
In this path, support the HW offload features, like,
checksum, VLAN stripping, RSS hash.
This path is chosen automatically according to the
configuration.
'inline' is used, then the duplicate code is generated
by the compiler.
Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
Acked-by: Qi Zhang <qi.z.zhang@intel.com>
Add a specific path for TX AVX512.
In this path, support the HW offload features, like,
checksum insertion, VLAN insertion.
This path is chosen automatically according to the
configuration.
'inline' is used, then the duplicate code is generated
by the compiler.
Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
Acked-by: Qi Zhang <qi.z.zhang@intel.com>
Add the offload flag for RX queues to know which offload
features are set.
Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
Acked-by: Qi Zhang <qi.z.zhang@intel.com>
Fix segment fault when failing to get the memory from the pool.
If there's no memory in the default cache, fall back to the
previous process.
The previous AVX2 rearm function is changed to add some AVX512
instructions and changed to a callee of the AVX2 and AVX512
rearm functions.
Fixes: e6a6a13891 ("net/i40e: add AVX512 vector path")
Cc: stable@dpdk.org
Reported-by: David Coyle <david.coyle@intel.com>
Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
Tested-by: David Coyle <david.coyle@intel.com>
Fix segment fault when failing to get the memory from the pool.
If there's no memory in the default cache, fall back to the
previous process.
The previous AVX2 rearm function is changed to add some AVX512
instructions and changed to a callee of the AVX2 and AVX512
rearm functions.
Fixes: 7f85d5ebcf ("net/ice: add AVX512 vector path")
Cc: stable@dpdk.org
Reported-by: David Coyle <david.coyle@intel.com>
Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
Tested-by: David Coyle <david.coyle@intel.com>
Fix segment fault when failing to get the memory from the pool.
If there's no memory in the default cache, fall back to the
previous process.
The previous AVX2 rearm function is changed to add some AVX512
instructions and changed to a callee of the AVX2 and AVX512
rearm functions.
Fixes: 31737f2b66 ("net/iavf: enable AVX512 for legacy Rx")
Cc: stable@dpdk.org
Reported-by: David Coyle <david.coyle@intel.com>
Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
Tested-by: David Coyle <david.coyle@intel.com>
'qfi' field is 8 bits which represent single bit for
PPP (paging Policy Presence) single bit for RQI
(Reflective QoS Indicator) and 6 bits for QFI
(QoS Flow Identifier)
This is based on RFC 38415-g30
https://www.3gpp.org/ftp/Specs/archive/38_series/38.415/38415-g30.zip
Updated the doxygen comment and the mask for 'qfi'
to properly identify the full 8 bits of the field.
note: changing the default mask would cause different
patterns generated by testpmd.
Fixes: 346553db5b ("ethdev: add GTP extension header to flow API")
Cc: stable@dpdk.org
Signed-off-by: Raslan Darawsheh <rasland@nvidia.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
Currently, when the user sets force link speed through 'link_speeds',
bit(0) of 'link_speeds' is not set to 1(ETH_LINK_SPEED_FIXED),
which conflicts with the definition.
Fixes: 88fbedcd5e ("app/testpmd: move speed and duplex parsing in a function")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Add support for single flow dump.
The CLIs to dump one rule: flow dump PORT rule ID
to dump all: flow dump PORT all
Examples:
testpmd> flow dump 0 all
testpmd> flow dump 0 rule 0
Signed-off-by: Haifei Luo <haifeil@nvidia.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Previous implementations support dump all the flows. Add new arg
rte_flow in rte_flow_dev_dump to dump one flow.
Signed-off-by: Haifei Luo <haifeil@nvidia.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Acked-by: Ori Kam <orika@nvidia.com>
These headers are used but not included explicitly, including them.
"arpa/inet.h" is included for 'htons' and friends.
"netinet/in.h" is included for 'IPPROTO_IP'.
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
Acked-by: Rasesh Mody <rmody@marvell.com>
Currently meter algorithms only supports bytes per second(BPS).
Check packet_mode set to TRUE are rejected.
Signed-off-by: Li Zhang <lizh@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
Acked-by: Liron Himi <lironh@marvell.com>
Currently meter algorithms only supports bytes per second(BPS).
Check packet_mode set to TRUE are rejected.
Signed-off-by: Li Zhang <lizh@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
add meter profile packet_mode to the ethernet device.
One example:
add port meter profile rfc2697 (port_id) (profile_id)
(cir) (cbs) (ebs) (packet_mode)
Signed-off-by: Li Zhang <lizh@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Currently meter algorithms only supports rate is bytes per second (BPS).
Add packet_mode flag in meter profile parameters data structure.
So that it can meter traffic by packet per second.
When packet_mode is 0, the profile rates and bucket sizes are
specified in bytes per second and bytes
when packet_mode is not 0, the profile rates and bucket sizes are
specified in packets and packets per second.
The below structure will be extended:
rte_mtr_meter_profile
rte_mtr_capabilities
Signed-off-by: Li Zhang <lizh@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
The hardware outer/inner VLAN protocol types are now updated to map to
new interface VLAN protocol types, so update the application to use new
VLAN protocol types when the rte_flow is QinQ filter type.
Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>
Acked-by: Qi Zhang <qi.z.zhang@intel.com>
Adds a support for switch filter: GTP-U using just inner fields.
If user doesn't specify outer protocol and its fields but wants to
add switch filter for GTP-U using inner protocols and related fields
such as inner L3 and/or inner L4, this patch enables such filtering.
Signed-off-by: Kiran Patil <kiran.patil@intel.com>
Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
Acked-by: Qiming Yang <qiming.yang@intel.com>
Add some new macros of PTYPE values to support PPPoL2TPv2oUDP.
Signed-off-by: Ting Xu <ting.xu@intel.com>
Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
Acked-by: Qiming Yang <qiming.yang@intel.com>
The dummy packet should be QinQ PPPoE ipv6 when ppp protocol is ipv6.
Fixes: bb3386f348 ("net/ice: enable QinQ filter for switch")
Cc: stable@dpdk.org
Signed-off-by: Yuying Zhang <yuying.zhang@intel.com>
Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
Acked-by: Qiming Yang <qiming.yang@intel.com>
Since VLAN protocol type 'ICE_VLAN_OFOS' has been changed to map
the hardware VLAN protocol ID to 'ICE_VLAN_OF_HW (16)' when in Double
VLAN mode, and to 'ICE_VLAN_OL_HW (17)' when in Single VLAN mode.
So 'ICE_VLAN_OFOS' can't be used with 'ICE_VLAN_EX' which is outer VLAN
hardware protocol ID 'ICE_VLAN_OF_HW (16)' to do the QinQ VLAN pattern.
Introduce the new inner VLAN protocol type 'ICE_VLAN_IN', which is inner
VLAN hardware protocol ID 'ICE_VLAN_OL_HW (17)'.
Now for QinQ VLAN pattern, the protocol 'ICE_VLAN_EX' and 'ICE_VLAN_IN'
should be used to set the related protocol header fields like VLAN ID.
Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>
Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
Acked-by: Qiming Yang <qiming.yang@intel.com>
Add helper functions to set the GPIO pin state or get the value of a
GPIO signal that's the part of the topology based on AQ commands.
This change is needed to setup GPIO pins state for PTP, SyncE etc.
Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com>
Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
Acked-by: Qiming Yang <qiming.yang@intel.com>
Enable I2C read/write AQ commands. They are now required for
controlling the external physical connectors via external I2C
port expander on E810-T adapters.
Signed-off-by: Maciej Machnikowski <maciej.machnikowski@intel.com>
Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
Acked-by: Qiming Yang <qiming.yang@intel.com>
Check priority when look for a recipe which matches our request
to enable flow priority for switch filter.
Signed-off-by: Yuying Zhang <yuying.zhang@intel.com>
Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
Acked-by: Qiming Yang <qiming.yang@intel.com>
Protocol id for first vlan in Double VLAN Mode (DVM) should be
ICE_VLAN_OF_HW = 16, but for Single VLAN Mode (SVM) this should be
ICE_VLAN_OL_HW = 17.
Change protocol id in type to id translation array for outer vlan
to 17 when DVM is enabled, which means the driver, package,
and firmware support DVM.
Signed-off-by: Michal Swiatkowski <michal.swiatkowski@intel.com>
Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>
Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
Acked-by: Qiming Yang <qiming.yang@intel.com>
Add support for PPPoL2TPv2oUDP RSS hash. L2TPv2 and PPP ptypes
and flow headers are added. Protocol id for PPP is added.
Signed-off-by: Ting Xu <ting.xu@intel.com>
Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
Acked-by: Qiming Yang <qiming.yang@intel.com>
Set E823C device's MAC type as generic.
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
Acked-by: Qiming Yang <qiming.yang@intel.com>
Remove the unused ptype entry, and use the gcc extension for
ranged initializers in arrays for Linux, and explicitly target
each table entry by index when initializing under Linux.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
Acked-by: Qiming Yang <qiming.yang@intel.com>
