This patch moves the check for "link_speeds" in dev_conf to
dev_configure, so that users know whether "link_speeds" is valid in
advance.
Fixes: bdaf190f8235 ("net/hns3: support link speed autoneg for PF")
Fixes: 400d307e1a60 ("net/hns3: support fixed link speed")
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, the fdir lock was used to protect concurrent access in
multiple processes, it has the following problems:
1) Lack of protection for fdir reset recover.
2) Only part of data is protected, eg. the filterlist is not protected.
We use the following scheme:
1) Del the fdir lock.
2) Add a flow lock and provides rte flow driver ops API-level
protection.
3) Declare support RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE.
Fixes: fcba820d9b9e ("net/hns3: support flow director")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
HNS3 PF driver only supports RSS, DCB or NONE multiple queues mode.
Currently, driver doesn't verify the VMDq multi-queue mode completely.
This patch fixes the verification for VMDq mode.
Fixes: 62e3ccc2b94c ("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>
Currently, "ONLY DCB" and "DCB+RSS" mode are both supported by HNS3
PF driver. But the driver verifies only the "DCB+RSS" multiple queues
mode.
Fixes: 62e3ccc2b94c ("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>
Some mbx messages do not need to reply with data. In this case,
it is no need to set the response data address and the response
length.
This patch removes these redundant codes from mbx messages that do
not need be replied.
Fixes: a5475d61fa34 ("net/hns3: support VF")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Rx vector implementation depends on the mbuf fields
(such as rearm_data/rx_descriptor_fields1) layout, this patch adds
compile-time verification for this.
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
The i40evf PMD will be deprecated, iavf will be the only VF driver for
Intel 700 serial (i40e) NIC family.
To reach this, there will be 2 steps:
Step 1: iavf will be the default VF driver, while i40evf still can be
selected by devarg: "driver=i40evf".
This is covered by this patch, which include:
1) add all 700 serial NIC VF device ID into iavf PMD
2) skip probe if devargs contain "driver=i40evf" in iavf
3) continue probe if devargs contain "driver=i40evf" in i40evf
Step 2: i40evf and related devarg are removed, this will happen at DPDK
21.11
Between step 1 and step 2, no new feature will be added into i40evf
except bug fix.
Signed-off-by: Robin Zhang <robinx.zhang@intel.com>
Acked-by: Qi Zhang <qi.z.zhang@intel.com>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Beilei Xing <beilei.xing@intel.com>
Due to hardware limitations the VLAN push/pop and decap actions following
the sample action are supported in the FDB Tx steering domain only, the
flows with incorrect action order for other domains are rejected by
rdma-core.
To provide the action order requested in flow API this patch checks for
the VLAN or decap precedence to the sample action and moves the VLAN or
decap actions into the next flow in the new table and adds the jump
action in the prefix sample flow.
This patch also adds the validation for these combination actions.
Fixes: 255b8f86eb6e ("net/mlx5: fix E-Switch egress mirror flow validation")
Cc: stable@dpdk.org
Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Modify API mlx5_flow_dev_dump to support the feature.
Modify mlx5_socket since one extra arg flow_ptr is added.
The data structure sent to DPDK application from the utility triggering
the flow dumps should be packed and endianness must be specified.
The native host endianness can be used, all exchange happens within
the same host (we use sendmsg aux data and share the file handle,
remote approach is not applicable, no inter-host communication happens).
The message structure to dump one/all flow(s):
struct mlx5_flow_dump_req {
uint32_t port_id;
uint64_t flow_ptr;
} __rte_packed;
If flow_ptr is 0, all flows for the specified port will be dumped.
Signed-off-by: Haifei Luo <haifeil@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
This patch supports check max SIMD bitwidth when choosing NEON and SVE
vector path.
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, the L3L4P/L3E/L4E/OL3E/OL4E fields in Rx descriptor used to
indicate hardware checksum result:
1. L3L4P: indicates hardware has processed L3L4 checksum for this
packet, if this bit is 1 then L3E/L4E/OL3E/OL4E is trustable.
2. L3E: L3 checksum error indication, 1 means with error.
3. L4E: L4 checksum error indication, 1 means with error.
4. OL3E: outer L3 checksum error indication, 1 means with error.
5. OL4E: outer L4 checksum error indication, 1 means with error.
Driver will set the good checksum flag through packet type and
L3E/L4E/OL3E/OL4E when L3L4P is 1, it runs as follows:
1. If packet type indicates it's tunnel packet:
1.1. If packet type indicates it has inner L3 and L3E is zero, then
mark the IP checksum good.
1.2. If packet type indicates it has inner L4 and L4E is zero, then
mark the L4 checksum good.
1.3. If packet type indicates it has outer L4 and OL4E is zero, then
mark the outer L4 checksum good.
2. If packet type indicates it's not tunnel packet:
2.1. If packet type indicates it has L3 and L3E is zero, then mark the
IP checksum good.
2.2. If packet type indicates it has L4 and L4E is zero, then mark the
L4 checksum good.
As described above, the good checksum calculation is time consuming,
it impacts the Rx performance.
By balancing performance and functionality, driver uses the following
scheme to set good checksum flag when L3L4P is 1:
1. If L3E is zero, then mark the IP checksum good.
2. If L4E is zero, then mark the L4 checksum good.
The performance gains are 3% in small packet iofwd scenarios.
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
This patch supports runtime config of mask device capability, it was
used to mask the capability which queried from firmware.
The device argument key is "dev_caps_mask" which takes hexadecimal
bitmask where each bit represents whether mask corresponding capability.
Its main purpose is to debug and avoid problems.
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Right now, rte_flow_shared_action_* APIs are used for some shared
actions, like RSS, count. The shared action should be created before
using it inside a flow. These shared actions sometimes are not
really shared but just some indirect actions decoupled from a flow.
The new functions rte_flow_action_handle_* are added to replace
the current shared functions rte_flow_shared_action_*.
There are two types of flow actions:
1. the direct (normal) actions that could be created and stored
within a flow rule. Such action is tied to its flow rule and
cannot be reused.
2. the indirect action, in the past, named shared_action. It is
created from a direct actioni, like count or rss, and then used
in the flow rules with an object handle. The PMD will take care
of the retrieve from indirect action to the direct action
when it is referenced.
The indirect action is accessed (update / query) w/o any flow rule,
just via the action object handle. For example, when querying or
resetting a counter, it could be done out of any flow using this
counter, but only the handle of the counter action object is
required.
The indirect action object could be shared by different flows or
used by a single flow, depending on the direct action type and
the real-life requirements.
The handle of an indirect action object is opaque and defined in
each driver and possibly different per direct action type.
The old name "shared" is improper in a sense and should be replaced.
Since the APIs are changed from "rte_flow_shared_action*" to the new
"rte_flow_action_handle*", the testpmd application code and command
line interfaces also need to be updated to do the adaption.
The testpmd application user guide is also updated. All the "shared
action" related parts are replaced with "indirect action" to have a
correct explanation.
The parameter of "update" interface is also changed. A general
pointer will replace the rte_flow_action struct pointer due to the
facts:
1. Some action may not support fields updating. In the example of a
counter, the only "update" supported should be the reset. So
passing a rte_flow_action struct pointer is meaningless and
there is even no such corresponding action struct. What's more,
if more than one operations should be supported, for some other
action, such pointer parameter may not meet the need.
2. Some action may need conditional or partial update, the current
parameter will not provide the ability to indicate which part(s)
to update.
For different types of indirect action objects, the pointer could
either be the same of rte_flow_action* struct - in order not to
break the current driver implementation, or some wrapper
structures with bits as masks to indicate which part to be
updated, depending on real needs of the corresponding direct
action. For different direct actions, the structures of indirect
action objects updating will be different.
All the underlayer PMD callbacks will be moved to these new APIs.
The RTE_FLOW_ACTION_TYPE_SHARED is kept for now in order not to
break the ABI. All the implementations are changed by using
RTE_FLOW_ACTION_TYPE_INDIRECT.
Since the APIs are changed from "rte_flow_shared_action*" to the new
"rte_flow_action_handle*" and the "update" interface's 3rd input
parameter is changed to generic pointer, the mlx5 PMD that uses these
APIs needs to do the adaption to the new APIs as well.
Signed-off-by: Bing Zhao <bingz@nvidia.com>
Acked-by: Andrey Vesnovaty <andreyv@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
Kunpeng 930 uses a new RAS exception reporting solution.
The reset type and exception status are reported through
firmware. The driver modifies the corresponding code to
adapt to the new solution.
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
'HNS3_RXD_TSIND_S' and 'HNS3_RXD_TSIND_M' is unused, which should
be deleted.
This patch fixed it.
Fixes: bba636698316 ("net/hns3: support Rx/Tx and related operations")
Cc: stable@dpdk.org
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
This patch supports set notify and vring relay thread name which is
helpful for debugging.
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
This patch supports set monitor thread name which is helpful for
debugging.
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
This patch supports set VSI reset thread name which is helpful for
debugging.
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
This patch supports set delay packet generator start thread name which
is helpful for debugging.
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
There is no reason for the DPDK libraries to all have 'librte_' prefix on
the directory names. This prefix makes the directory names longer and also
makes it awkward to add features referring to individual libraries in the
build - should the lib names be specified with or without the prefix.
Therefore, we can just remove the library prefix and use the library's
unique name as the directory name, i.e. 'eal' rather than 'librte_eal'
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Ensure all lists of drivers are standardized:
* one driver per line
* lists double-indented with spaces (as they are line continuations)
* elements in alphabetical order
* opening and closing list brackets "[" & "]" on own lines
* last element has trailing comma
Any code snippets in the list files is adjusted to single-indent using
whitespace to correspond to the new style also.
The lists of standard library dependencies per class, and other short
lists are not formatted one-per-line as these lists are not expected to
grow beyond 2 or 3 entries.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
As with the library meson.build file, we can use the "continue" keyword to
reduce the level of indentation used for the majority of the build file.
Since we are changing the whitespace indentation level, we also update the
body of the foreach loop to use the meson standard, 4-space indentation.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Split AVX512 Rx data path into two, one is for basic,
the other one can support additional Rx offload features,
including Rx checksum offload, Rx vlan offload, RSS offload.
Signed-off-by: Leyi Rong <leyi.rong@intel.com>
Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
Tested-by: Qin Sun <qinx.sun@intel.com>
Add alternative Tx data path for AVX512 which can support partial
Tx offload features, including Tx checksum offload, vlan/QinQ
insertion offload.
Signed-off-by: Leyi Rong <leyi.rong@intel.com>
Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
Tested-by: Qin Sun <qinx.sun@intel.com>
When set default MAC address, use type VIRTCHNL_ETHER_ADDR_PRIMARY as this
case is changing device/primary unicast MAC. For other cases, such as
adding or deleting extra unicast addresses and multicast addresses, use
type VIRTCHNL_ETHER_ADDR_EXTRA.
Fixes: cb25d4323fbf ("net/avf: enable MAC VLAN and promisc ops")
Cc: stable@dpdk.org
Signed-off-by: Robin Zhang <robinx.zhang@intel.com>
Tested-by: Yan Xia <yanx.xia@intel.com>
Currently, there is no way for a VF driver to specify that it wants to
change its device/primary unicast MAC address. This makes it
difficult/impossible for the PF driver to track the VF's device/primary
unicast MAC address, which is used for VM/VF reboot and displaying on
the host. Fix this by using 2 bits of a pad byte in the
virtchnl_ether_addr structure so the VF can specify what type of MAC
it's adding/deleting.
Below are the values that should be used by all VF drivers going
forward.
VIRTCHNL_ETHER_ADDR_LEGACY(0):
- The type should only ever be 0 for legacy AVF drivers (i.e.
drivers that don't support the new type bits). The PF drivers
will track VF's device/primary unicast MAC using with best
effort.
VIRTCHNL_ETHER_ADDR_PRIMARY(1):
- This type should only be used when the VF is changing their
device/primary unicast MAC. It should be used for both delete
and add cases related to the device/primary unicast MAC.
VIRTCHNL_ETHER_ADDR_EXTRA(2):
- This type should be used when the VF is adding and/or deleting
MAC addresses that are not the device/primary unicast MAC. For
example, extra unicast addresses and multicast addresses
assuming the PF supports "extra" addresses at all.
If a PF is parsing the type field of the virtchnl_ether_addr, then it
should use the VIRTCHNL_ETHER_ADDR_TYPE_MASK to mask the first two bits
of the type field since 0, 1, and 2 are the only valid values.
For i40evf PMD, when set default MAC address, use type
VIRTCHNL_ETHER_ADDR_PRIMARY as this case is changing device/primary
unicast MAC. For other cases, such as adding or deleting extra unicast
addresses and multicast addresses, use type VIRTCHNL_ETHER_ADDR_EXTRA.
Fixes: 6d13ea8e8e49 ("net: add rte prefix to ether structures")
Fixes: caccf8b318ca ("ethdev: return diagnostic when setting MAC address")
Cc: stable@dpdk.org
Signed-off-by: Robin Zhang <robinx.zhang@intel.com>
Tested-by: Yan Xia <yanx.xia@intel.com>
Support rte flow priority attribute for DCF switch filter.
When a packet is matched by two rules, the behavior of it
is not defined. This patch supports flow priority to create
different recipes for this situation. Only priority 0 and 1
are supported and higher value denotes higher priority.
for example:
1. flow create 0 priority 0 ingress pattern eth / vlan tci is 2 / vlan
tci is 2 / end actions vf id 2 / end
2. flow create 0 priority 1 ingress pattern eth / vlan / vlan / ipv4 dst
is 192.168.0.1 / end actions vf id 1 / end
These two rules can be created at the same time in DCF switch
filter and priority of rule 2 is higher. Packet hits rule 2
when two conditions of rules are satisfied.
Signed-off-by: Yuying Zhang <yuying.zhang@intel.com>
Acked-by: Qi Zhang <qi.z.zhang@intel.com>
Enable additional PHY types (25G-AOC and 25G-ACC) for set PHY config
command.
Signed-off-by: Yury Kylulin <yury.kylulin@intel.com>
Tested-by: Ashish Paul <apaul@juniper.net>
This patch separates Tx burst function implementations to different
source files, thus allowing them to compile in parallel.
Signed-off-by: Michael Baum <michaelba@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
This patch separates Tx function implementations to different source
file as an optional preparation step for Tx cleanup.
Signed-off-by: Michael Baum <michaelba@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
This patch moves Tx burst and its inline functions declarations to
header file to allow its use from several separate source files and as a
possible preparation for Tx cleanup.
Signed-off-by: Michael Baum <michaelba@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
This patch separates Tx function declarations to different header file
in preparation for removing their implementation from the source file
and as an optional preparation for Tx cleanup.
Signed-off-by: Michael Baum <michaelba@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
This patch separates Rx function implementations to different source
file as an optional preparation step for further consolidation of Rx
burst functions.
Signed-off-by: Michael Baum <michaelba@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
The mlx5_rxtx.c file contains a lot of Tx burst functions, each of those
is performance-optimized for the specific set of requested offloads.
These ones are generated on the basis of the template function and it
takes significant time to compile, just due to a large number of giant
functions generated in the same file and this compilation is not being
done in parallel with using multithreading.
Therefore we can split the mlx5_rxtx.c file into several separate files
to allow different functions to be compiled simultaneously.
In this patch, we separate Rx function declarations to different header
file in preparation for removing them from the source file and as an
optional preparation step for further consolidation of Rx burst
functions.
Signed-off-by: Michael Baum <michaelba@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Currently, user could use runtime config "rx_func_hint=simple" to
select the hns3_recv_pkts API, but the API's name get from
rte_eth_rx_burst_mode_get is "Scalar" which has not reflected "simple".
So this patch renames hns3_recv_pkts to hns3_recv_pkts_simple, and
also change it's name which gets from rte_eth_rx_burst_mode_get to
"Scalar Simple" to maintain conceptual consistency.
Fixes: 521ab3e93361 ("net/hns3: add simple Rx path")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
Restore the original code, where VHOST_SET_OWNER is applied to
all vhostfds of the device.
Fixes: 06856cabb89b ("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: bac6a0644121 ("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: 62e3ccc2b94c ("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: 2e4859f3b362 ("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>
