There are coverity defects related "Unintended sign extension" in the
internal static function named hns3_get_regs_length used for dumping reg
operation.
This patch fixes them by replacing the data type of cmdq_lines,
common_lines, ring_lines and tqp_intr_lines with uint32_t in the inner
static function named hns3_get_regs_length of hns3 PMD driver.
Coverity issue: 349917, 349914
Fixes: 936eda25e8 ("net/hns3: support dump register")
Cc: stable@dpdk.org
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Currently, there are coverity defects warning as below:
CID 349937 (#1 of 1): Unintended sign extension (SIGN_EXTENSION)
sign_extension: Suspicious implicit sign extension: port_number with
type uint16_t (16 bits, unsigned) is promoted in port_number << cur_pos
to type int (32 bits, signed), then sign-extended to type unsigned long
(64 bits, unsigned). If port_number << cur_pos is greater than
0x7FFFFFFF, the upper bits of the result will all be 1.
CID 349893 (#1 of 1): Unintended sign extension (SIGN_EXTENSION)
sign_extension: Suspicious implicit sign extension: vlan_tag with type
uint8_t (8 bits, unsigned) is promoted in vlan_tag << cur_pos to type
int (32 bits, signed), then sign-extended to type unsigned long (64
bits, unsigned). If vlan_tag << cur_pos is greater than 0x7FFFFFFF, the
upper bits of the result will all be 1.
This patch fixes them by replacing the data type of port_number and
vlan_tag with uint32_t in the inner static function named
hns3_fd_convert_meta_data of hns3 PMD driver.
Coverity issue: 349937, 349893
Fixes: fcba820d9b ("net/hns3: support flow director")
Cc: stable@dpdk.org
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
There is a coverity defect related "Unchecked return value".
The internal static hns3_reset_err_handle function is reset error
process of hns3 PMD driver. If failure in reset process, it does not
mean that the network port is completely unavailable, so the command
interface between driver and firmware still needs to be initialized.
Regardless of whether the execution of the function named hns3_cmd_init
is successful or not, the next process after execution must be
continued, so there is no need to check the return value. If
hns3_cmd_init fails to execute, there will be corresponding log
information inside hns3_cmd_init.
This patch adds '(void)' Type conversion to avoid coverity warning.
Coverity issue: 349934
Fixes: 2790c64647 ("net/hns3: support device reset")
Cc: stable@dpdk.org
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
There is a coverity defect related "Argument cannot be negative".
This patch fixes it by passing '-ret' to the function strerror() when
ret is negative.
Coverity issue: 349933
Fixes: fcba820d9b ("net/hns3: support flow director")
Cc: stable@dpdk.org
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Base on hns3 network engine, when the rte_eth_tx_burst API is called
by Upper Level Process, if PKT_TX_TCP_SEG flag is set and tso_segsz
is 0 in the input parameter structure rte_mbuf, hns3 PMD driver will
process this packet as an non-TSO packet, otherwise hardware will enter
an abnormal state.
Fixes: 6dca716c9e ("net/hns3: support TSO")
Cc: stable@dpdk.org
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Currently, based on hns3 network engine, driver always reports the
incoming packet's VLAN tags to the structure rte_mbuf those are the
output parameter pointers in '.rx_pkt_burst' ops implementation
function, and never reports PKT_RX_VLAN_STRIPPED flag to the structure
rte_mbuf even if Upper Level Process configured hardware strip by
calling rte_eth_dev_configure or rte_eth_dev_set_vlan_offload API
function. It makes the ULP unable to know the stripping of VLAN.
It is supposed to present the stripped flags to the mbuf ol_flags, and
report the right VLAN tag.
And as hardware constraints, the stripped VLAN tag will always in the Rx
descriptor. Even if setting a PVID based on the function, the PVID will
be reported to the Rx descriptor. So the driver need to determine which
VLAN tag should be reported to output the structure rte_mbuf in
'.rx_pkt_burst' ops implementation function named hns3_recv_pkts.
Fixes: bba6366983 ("net/hns3: support Rx/Tx and related operations")
Fixes: 411d23b9ea ("net/hns3: support VLAN")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Currently, based on hns3 PF device, hardware will strip 2 vlan tags when
ULP calls rte_eth_dev_set_vlan_pvid API function to set a PVID whether
vlan strip related offload is turned on by calling rte_eth_dev_configure
or rte_eth_dev_set_vlan_offload API function.
When receiving a QinQ packet with the pvid tag, if ULP does not
configure the vlan strip by the method mentioned above, a layer of vlan
tag will be lost to ULP, which is not the expected result.
It is supposed to configure the vlan strip according to the upper level
process's configuration.
Fixes: 411d23b9ea ("net/hns3: support VLAN")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
When users set the length of RSS hash key greater than the supported
length by hardware, the driver should intercept and can not configure
the wrong key into the hardware.
Fixes: c37ca66f2b ("net/hns3: support RSS")
Cc: stable@dpdk.org
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Rx offload flag `DEV_RX_OFFLOAD_RSS_HASH` which can be used to
enable/disable PMDs write to `rte_mbuf:#️⃣:rss`. The hns3 PMD driver
already can notify the validity of `rte_mbuf:#️⃣rss` to the
application by enabling `PKT_RX_RSS_HASH` flag in `rte_mbuf::ol_flags`.
Fixes: 19a3ca4c99 ("net/hns3: add start/stop and configure operations")
Fixes: c37ca66f2b ("net/hns3: support RSS")
Cc: stable@dpdk.org
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Currently, when running testpmd application based on hns3 network engine
with csum fwd mode by "set fwd csum" command in the prompt line, sending
42 consecutive bytes of ARP packets to network port with packets
generator. But in fact hardware can't send the ARP packets and the
related logs as below:
"Preparing packet burst to failed: Invalid argument"
The hardware doesn't support transmit packets less than 60 bytes, and in
the '.tx_pkt_burst' ops implementation function named hns3_xmit_pkts
appending operation has been added for less than 60 bytes packets. So
the interception needs to be removed in the '.tx_pkt_prepare' ops
implementation function named hns3_prep_pkts.
Fixes: de620754a1 ("net/hns3: fix sending packets less than 60 bytes")
Fixes: bba6366983 ("net/hns3: support Rx/Tx and related operations")
Cc: stable@dpdk.org
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Hao Chen <chenhao164@huawei.com>
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Currently, promiscuous mode configuration are not cleared during
uninstallation based on hns3 PF device. The residual entries may cause
unnecessary bandwidth usage.
So, we need clear the PF's promisc mode status during the uninit.
Fixes: a45fd0aa0e ("net/hns3: fix Rx queue search with broadcast packet")
Fixes: d51867db65 ("net/hns3: add initialization")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
In hns3 PMD driver, the vport id 0 denote PF, and the vport id 1 denote
the first VF device of the port.
This patch adds two macros named HNS3_PF_FUNC_ID and
HNS3_1ST_VF_FUNC_ID, and replaces this two numbers to improve code
readability.
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Since the return value of the '.stats_reset' and '.xstats_reset'
callback function is int, when failing to issue command to firmware to
execute clear statistics, the relevant callback function should return
non-zero value.
Fixes: 8839c5e202 ("net/hns3: support device stats")
Cc: stable@dpdk.org
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Currently, based on hns3 VF device error may occur during initialization.
The root cause as below:
When the following formula is executed during initialization, the
private variable named hw->tqps_num has not been obtained from PF driver
through mailbox, further causes failure when mapping interrupt and
queues.
hw->num_msi = (num_msi > hw->tqps_num + 1) ? hw->tqps_num + 1 : num_msi;
We need to use hw->tqp_num after it is correctly assigned.
On the other hand, because the private variable named hw->num_msi, which
represents the number of MSI-x interrupt of hns3 PF/VF device, is used in
the '.get_reg' ops implementation function to dump all interrupt related
registers, it should be obtained from firmware directly and we'd better
not modify it in the driver.
Fixes: ef2e785c36 ("net/hns3: fix Tx interrupt when enabling Rx interrupt")
Fixes: 02a7b55657 ("net/hns3: support Rx interrupt")
Cc: stable@dpdk.org
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Hao Chen <chenhao164@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
In current version, when upper level application calls the
rte_eth_dev_configure API function, if pvid config is not set of the
input parameter which struct type is rte_eth_conf, hns3 pmd driver also
sets the VLAN pvid related configuration to hardware, and this is not
reasonable. For example, As pvid is set to 100 by
rte_eth_dev_set_vlan_pvid, when pvid config is not set in rte_eth_conf,
rte_eth_dev_configure will tell driver to delete pvid 0, and that is
meaningless.
This patch fixes it to ensure that driver does not set VLAN pvid related
configuration to hardware when pvid config is not set in rte_eth_conf.
Fixes: 411d23b9ea ("net/hns3: support VLAN")
Cc: stable@dpdk.org
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
The hns3 network engine is built-in multiple SoCs, such as kunpeng 920,
kunpeng 930, etc. The PCI revision id is 0x21 in kunpeng 920, and the PCI
revision id is 0x30 in kunpeng 930.
This patch gets PCI revision to identify different version of hardware
network engine.
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Here adds some prints for return value when the relative function fails
and enter the exception branch.
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
When upper level application calls the rte_eth_tx_burst API function to
send multiple packets at a time with burst mode based on hns3 network
engine, there are some abnormal conditions that cause the driver to fail
to operate the hardware to send packets correctly.
This patch adds some statistic counts for the abnormal errors of Tx data
path to the extend device statistics. The upper level application can
get them by calling the rte_eth_xstats_get API function.
Note: When using burst mode to call the rte_eth_tx_burst API function to
send multiple packets at a time. When the first abnormal error is
detected, add one to the relevant error statistics item, and then exit
the loop of sending multiple packets of the function. That is to say,
even if there are multiple packets in which abnormal errors may be
detected in the burst, the relevant error statistics in the driver will
only be increased by one.
The detail description of the Tx abnormal errors statistic items as
below:
- TX_OVER_LENGTH_PKT_CNT Total number of greater than
HNS3_MAX_FRAME_LEN the driver supported.
- TX_EXCEED_LIMITED_BD_PKT_CNT
Total number of exceeding the hardware limited bd which process a
packet needed bd numbers.
- TX_EXCEED_LIMITED_BD_PKT_REASSEMBLE_FAIL_CNT
Total number of exceeding the hardware limited bd fail which
process a packet needed bd numbers and reassemble fail.
- TX_UNSUPPORTED_TUNNEL_PKT_CNT
Total number of unsupported tunnel packet. The unsupported tunnel
type: vxlan_gpe, gtp, ipip and MPLSINUDP, MPLSINUDP is a packet
with MPLS-in-UDP RFC 7510 header.
- TX_QUEUE_FULL_CNT
Total count which the available bd numbers in current bd queue is
less than the bd numbers with the pkt process needed.
- TX_SHORT_PKT_PAD_FAIL_CNT
Total count which the packet length is less than minimum packet
size HNS3_MIN_PKT_SIZE and fail to be appended with 0.
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Hao Chen <chenhao164@huawei.com>
This patch adds getting Rx/Tx queue fbd information in extended device
statistics. The upper level application can get them by calling the
rte_eth_xstats_get API function.
The fbd registers of every Rx/Tx queue are very useful to identify the
Rx/Tx bottleneck.
1. The Rx queue fbd register is the number of the unprocessed buffer
descriptors which are waiting for driver to process;
2. The Tx queue fbd register is the number of the unprocessed buffer
descriptors which are waiting for network engine hardware to process.
As a result, we get the following output information in testpmd
application by using the command "show port xstats" as below:
rx_q0RX_QUEUE_FBD: 19
rx_q1RX_QUEUE_FBD: 18
tx_q0TX_QUEUE_FBD: 0
tx_q1TX_QUEUE_FBD: 0
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Huisong Li <lihuisong@huawei.com>
This patch modifies the print format for firmware version in the log, It
replaces "0x%08x" with "%lu.%lu.%lu.%lu" in the format control string.
By the way, this patch adds ".fw_version_get" ops implemation for hns3
VF PMD driver.
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Currently, when upper level application call the API function named
rte_eth_dev_set_vlan_offload to configure the hardware vlan filter
offload and call the rte_eth_promiscuous_enable API to enable
promiscuous mode based on hns3 PF device, driver can't receive the
packets with a vlan tag which has not been added by calling the API
function named rte_eth_dev_vlan_filter.
This patch fixes it by disabling the vlan filter when setting the
promiscuous mode and enabling the vlan filter again after the
promiscuous mode are disabled.
Fixes: 19a3ca4c99 ("net/hns3: add start/stop and configure operations")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Currently, By default VLAN filter is enabled during initialization and
couldn't be turned off based on hns3 PF device. If upper applications
don't call rte_eth_dev_vlan_filter API function to set vlan based on
hns3 PF device, hns3 PF PMD driver will can't receive the packets with
vlan tag. It will leads to some compatibility issues, the behaviors of
using hns3 network engine and other NICs are different.
This patch disables the VLAN filter during initialization and allows the
upper level applications to enable or disable the VLAN filter.
Fixes: 411d23b9ea ("net/hns3: support VLAN")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
When upper application calls the rte_eth_dev_rss_hash_conf_get API
function to get the RSS key parameters, the function should return the
RSS key length supported by the device. Otherwise, an error will occur
when the upper application needs to use the RSS key length supported
by this specified hardware for judgment and configure the specified
key into hardware.
For example, in the following scenario:
When users want to use their own RSS key, but the length of the key is
bigger than the one of the supported by hardware.
As a result, users need to get the RSS key length supported by hardware
according to the above API firstly, and then compare the actual obtained
RSS key length with the length of their own RSS key.
If the driver does not return the actual value, error may occur when
user calls the rte_eth_dev_rss_hash_update API function to configure
their own key into hardware.
Besides, this patch fixes the problem of stepping on memory when the RSS
key array configured by users are less than the RSS key length supported
by the driver at the same time.
Fixes: c37ca66f2b ("net/hns3: support RSS")
Cc: stable@dpdk.org
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Currently, when upper application calls rte_eth_dev_info_get API
function to query the Rx offload capability based on hns3 network
engine, RSS hash offload capacity is missing.
This patch fixes it by adding the related capacity in the
'.dev_infos_get' ops implementation function named hns3_dev_infos_get
and hns3vf_dev_infos_get for hns3 PF/VF PMD driver.
Fixes: c37ca66f2b ("net/hns3: support RSS")
Cc: stable@dpdk.org
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
This patch fixes that the flow director rules are not cleared during
initialization, which lead to remaining flow director rules after upper
application (such as testpmd) restarted.
Fixes: fcba820d9b ("net/hns3: support flow director")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Currently, Rx interrupt cannot work normally after reset (such as FLR,
global reset and IMP reset), when running l3fwd-power application based
on hns3 network engine.
The root cause is that the hardware configuration about Rx interrupt
does not recover after reset.
This patch fixes it with the following modification.
1. The internal static function named hns3(vf)_init_ring_with_vector is
moved from hns3_init_pf to hns3(vf)_init_hardware because
hns3(vf)_init_hardware is called both in the initialization and the
RESET_STAGE_DEV_INIT stage of the reset process.
2. The internal static function named hns3(vf)_restore_rx_interrupt is
added in hns3(vf)_restore_conf, it is used to recover hardware
configuration about interrupt vectors of rx queues in the
RESET_STAGE_DEV_INIT stage of the reset process.
3. The internal static function named hns3_dev_all_rx_queue_intr_enable
and hns3_enable_all_queues are added in hns3(vf)_dev_start(which
called in the initialization, so after calling the rte_eth_dev_start
API successfully, the driver is ready to work.
4. The function named hns3_dev_all_rx_queue_intr_enable and
hns3_enable_all_queues are also added in hns3(vf)_start_service(which
called in the RESET_STAGE_DEV_INIT stage of the reset process), so
after start_service, the driver is ready to work.
Note:
1. Because FLR will clear queue's interrupt enable bit hardware
configuration, so we add calling hns3_dev_all_rx_queue_intr_enable to
enable interrupt before enabling queues.
2. After finished the initialization, we can enable queues to work by
calling the internal function named hns3_enable_all_queues.
Fixes: 02a7b55657 ("net/hns3: support Rx interrupt")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Currently, when upper application calls the rte_eth_dev_mac_addr_add API
function to add a MC mac address based on hns3 PF/VF device, it will
fail.
In hns3 network engine adding UC and MC mac address with different
commands with firmware. We need to determine whether the input address
is a UC or a MC address to call different commands in the
'.mac_addr_add' and '.mac_addr_remove' ops implementation functions in
hns3 PF and VF driver as below:
hns3_add_mac_addr
hns3vf_add_uc_mac_addr
hns3_remove_mac_addr
hns3vf_remove_mac_addr
By the way, it is recommended calling the rte_eth_dev_set_mc_addr_list API
function to set the MC mac address, because using the
rte_eth_dev_mac_addr_add API function to set MC mac address may affect the
specifications of UC mac addresses.
Fixes: 7d7f9f80bb ("net/hns3: support MAC address related operations")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
This patch replaces the specific macro named RTE_INTR_VEC_ZERO_OFFSET
provided by DPDK framework instead of the magic number 0.
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Currently, the return value processing of some functions can be combined
and the result is that some codes can be optimized.
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Currently, the '.vlan_offload_set' ops implementation function named
hns3vf_vlan_offload_set always return 0 in hns3 VF PMD driver.
This patch fixes it with the following modification in the function
named hns3vf_vlan_offload_set.
1. Avoid setting hardware configuration and return -EIO during resetting.
2. Add the return value detection process for calling internal static
function named hns3vf_en_hw_strip_rxvtag.
Fixes: a5475d61fa ("net/hns3: support VF")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
The mailbox opcode is defined as one byte in datasheet which is not
compatible with that in the current hns3 PMD driver.
This patch fixes the data type of the local variable for mailbox opcode
in driver, changing from uint16_t to uint8_t.
Fixes: 463e748964 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Currently, when performing test case as follow:
1. Run testpmd application based on hns3 network engine with multiple
receive queues(--rxq=N --txq=N, N>1).
2. Create the special RSS rules by "create flow ..." command in the
command prompt of the testpmd application.
3. Flush the RSS rules created in step 2 by "flow flush ..." command.
4. Enable RSS by "port config all rss all" command.
In step 4, the command exeuctes successfully. This phenomenon is
inconsistent with the expectation. The API function named
rte_eth_dev_rss_hash_update called in the command should return error
and the command should fail.
This patch fixes it by adding a flag for disabling RSS in the driver.
When RSS rules is flushed, we set the the flag with true, and the
'.rss_hash_update' ops implementation function named
hns3_dev_rss_hash_update return -EINVAL.
Fixes: c37ca66f2b ("net/hns3: support RSS")
Cc: stable@dpdk.org
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
For the current hns3 PMD driver, there are some RSS related bugs at
the following scenes:
1. Start the application with the number of Rx queues equals 1(--rxq=1),
modify the number of Rx queue to some number greater than 1 during
normal operation. As a result, upper application can't receive packets
from multiple rx queues.
2. Start testpmd application with the option disable-rss and the number
of Rx queue is greater than 1(--disable-rss --rxq=N, N>1). As a result,
upper application still can receive packets from multiple rx queues.
The root cause as below:
There are some error configuration in the RSS indirection table of hns3
network engine.
This patch fixes them with the following modification.
1. When RSS size is changed, we need to update RSS redirection table
maintained by driver and configure them to hardware. Besides, during
the entire reset process, we need to ensure that the RSS table
information are not overwritten and configured directly to the hardware
in the RESET_STAGE_RESTORE stage of the reset process.
2. When sarting testpmd application with the options disable-rss, it
doesn't need to configure RSS redirection table to hardware.
Fixes: c37ca66f2b ("net/hns3: support RSS")
Cc: stable@dpdk.org
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Currently, when performing the following test case:
1. Run testpmd application based on hns3 PF device.
2. Inject reset(global/IMP reset) repeatedly.
After the reset, the network port can't link up.
In the RESET_STAGE_DEV_INIT stage of the reset process, the driver will
reinitialize the hardware. If global/IMP reset occurs at this time
again, the operation of reinitialize the hardware will fail because that
firmware don't respond to the configuration commands issued by driver.
In current driver, when failed to reinitialize the hardware, rollback
operation is done, such as clearing the relevant configuration of the
command queue registers.
If firmware detects that the function's command queue register is not
configured correctly, it will not complete the reset related hardware
configuration for this function, resulting in that driver can't detect
that the hardware reset has been completed. And then the reset process
of the driver exit abnormally, the hardware can not work normally after
reset.
This patch fixes it by avoid clearing the command queue related
registers when failed to reinitialize the hardware in the
RESET_STAGE_DEV_INIT stage of the reset process.
Fixes: 2790c64647 ("net/hns3: support device reset")
Cc: stable@dpdk.org
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Chunsong Feng <fengchunsong@huawei.com>
The VLAN pvid ranges from 0 to 4095. The hns3 PMD driver does not
support this situation that the VLAN pvid is larger than Maximum VLAN
ID(4095).
Fixes: 411d23b9ea ("net/hns3: support VLAN")
Cc: stable@dpdk.org
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Currently, we encounter segmentation fault when performing the following
test case:
1. Run testpmd application, config the flow filter rules then flush them
repeatedly.
2. Inject FLR concurrently every 5 second.
The calltrace info:
This GDB was configured as "aarch64-linux-gnu".
Reading symbols from ./testpmd...(no debugging symbols found)...done.
[New LWP 322]
[New LWP 325]
[New LWP 324]
[New LWP 326]
[New LWP 323]
[New LWP 327]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/
libthread_db.so.1".
Core was generated by `/home/root/app/testpmd -w 0000:00:01.0 -w
0000:00:02.0 -w 0000:00:03.0 -l 0-3 -'.
Program terminated with signal SIGSEGV, Segmentation fault.
libc.so.6
[Current thread is 1 (Thread 0xffff8bb35110 (LWP 322))]
(gdb) bt
#0 0x0000ffff8b936a90 in strlen () from /lib/aarch64-linux-gnu/
libc.so.6
#1 0x0000ffff8b905ccc in vfprintf () from /lib/aarch64-linux-gnu/
libc.so.6
#2 0x0000ffff8b993d04 in __printf_chk () from /lib/aarch64-linux-gnu/
libc.so.6
#3 0x0000000000754828 in port_flow_flush ()
#4 0x0000000000870f3c in cmdline_parse ()
The root cause as follows：
In the '.flush' ops implementation function named hns3_flow_flush, By
the way the '.flush' ops is defined in the struct rte_flow_ops, if
failed to call hns3_clear_rss_filter, the out parameter error is not
set, and then the member variable name message in the struct error is
invalid(filled with 0x44444444 in port_flow_flush function of the
testpmd application), it leads to segmentation fault when format the
message.
We fixes it by filling error parameter when failure in calling static
function named hns3_clear_rss_filter in the the '.flush' ops
implementation function named hns3_flow_flush.
Fixes: c37ca66f2b ("net/hns3: support RSS")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Currently, the hns3 PMD driver can interact with firmware through
command to complete hardware configuration. The driver calls internal
interface function named hns3_cmd_send to issues command to the
firmware, and check the execution result of the command through desc_ret
returned by firmware to driver.
As the design of error code, when device is resetting hns3_cmd_send will
only return -EBUSY or -EIO. But we found that if desc_ret is in
[12,65535], for example the item doesn't exist when issuing the command
to query some table item, hns3_cmd_send also return -EIO. This
phenomenon will affect the processing logic for the return value.
The root cause as below:
When desc_ret is in [12,65535], in the static function named
hns3_cmd_convert_err_code called by hns3_cmd_send, matches the default
case and return -EIO. And then hns3_cmd_send return -EIO.
This patch fixes it with the following modification.
1. Change the return value of the default case in the static function
named hns3_cmd_convert_err_code from -EIO to -EREMOTEIO.
2. Modify the comment add errcode description of the internal interface
function named hns3_cmd_send.
Fixes: 737f30e1c3 ("net/hns3: support command interface with firmware")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Currently there is a certain probability of the unexpected ol_flag of
the Rx packets's rte_mbuf when receiving packets.
The root cause as below:
1. The member variable named ol_flag of the structure named rte_mbuf is
not properly initialized to zero in the '.rx_pkt_burst' ops
implementation function named hns3_recv_pkts.
2. When multi-segment rte_mbufs are needed for long packet in Rx
operation, the driver should assign value to the ol_flag of the first
segment, not to the ol_flag of the last segment.
This patch fixes it with the following modification in the
'.rx_pkt_burst' ops implementation function named hns3_recv_pkts.
1. Where the first write operation in the '.rx_pkt_burst' ops
implementation function, assign PKT_RX_RSS_HASH to ol_flags directly
using '=' operation instead of '|=' operation.
2. In the static function named hns3_rx_set_cksum_flag, the last
rte_mbuf's ol_flags should be assigned when processing multi-segment.
We fix it by passing first_seg variable to the function instead of
rxm(the last segment's address).
Fixes: bba6366983 ("net/hns3: support Rx/Tx and related operations")
Fixes: ad7cf94823 ("net/hns3: fix offload flag for RSS hash")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
This patch modifies the name of some macro and local variable to avoid
devil number and increase code readability in the internal interface
function named hns3_set_port_vlan_filter.
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
This patch removes unnecessary MAC address validity check operation in
the .mac_addr_set ops implementation function named
hns3_set_default_mac_addr and hns3vf_set_default_mac_addr, because it
has been guaranteed that input parameter named mac_addr is valid address
in the rte layer of DPDK framework.
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
There is a common macro __rte_unused, avoiding warnings,
which is now used where appropriate for consistency.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
There is a common macro __rte_aligned for alignment,
which is now used where appropriate for consistency.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Reviewed-by: David Christensen <drc@linux.vnet.ibm.com>
Remove setting ALLOW_EXPERIMENTAL_API individually for each Makefile and
meson.build. Instead, enable ALLOW_EXPERIMENTAL_API flag across app, lib
and drivers.
This changes reduces the clutter across the project while still
maintaining the functionality of ALLOW_EXPERIMENTAL_API i.e. warning
external applications about experimental API usage.
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
Signed-off-by: David Marchand <david.marchand@redhat.com>
Currently, when promiscuous mode is enabled, it is just allowed to
accept all the unicast and broadcast packets in hns3 PF PMD driver. It
should also be able to receive multicast packets.
Fixes: 19a3ca4c99 ("net/hns3: add start/stop and configure operations")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Currently, we only support VF device is bound to vfio_pci or igb_uio and
then driven by DPDK driver when PF is driven by kernel mode hns3 ethdev
driver, VF is not supported when PF is driven by hns3 DPDK driver.
This patch adds promiscuous and allmulticast mode support for hns3 VF
PMD driver.
1) The promiscuous/allmulticast mode can be configured successfully only
based on the trusted VF device. If based on the non trusted VF
device, configuring promiscuous/allmulticast mode will fail. The hns3
VF device can be configured as trusted device by hns3 PF kernel
ethdev driver on the host by "ip link set <eth num> vf <vf id> turst
on" command.
2) After the promiscuous mode is configured successfully, hns3 VF PMD
driver can receive the ingress and outgoing traffic. In the words,
all the ingress packets, all the packets sent from the PF and other
VFs on the same physical port.
3) Note: Because of the hardware constraints, By default vlan filter is
enabled and couldn't be turned off based on VF device, so vlan filter
is still effective even in promiscuous mode. If upper applications
don't call rte_eth_dev_vlan_filter API function to set vlan based on
VF device, hns3 VF PMD driver will can't receive the packets with
vlan tag in promiscuous mode.
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
The hns3 PF/VF devices on the same port share the hardware MTU
configuration. Currently, we send mailbox to inform hns3 PF kernel
ethdev driver to finish hardware MTU configuration in hns3 VF PMD
driver, there is no need to stop the port for hns3 VF device, and
the MTU value issued by hns3 VF PMD driver must be less than or
equal to PF's MTU.
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Currently, when receiving and transmitting packets based on hns3 network
engine there are probably unexpected and redundant Tx interrupts if Rx
interrupt is enabled.
The root cause as below:
Tx and Rx queues with the same number share the interrupt vector in hns3
network engine, and in this case there are the residual hardware mapping
relationship configuration between queue and interrupt vector configured
in hns3 kernel ethdev driver.
We should clear the all hardware mapping relationship configurations in
the initialization. Because of the hardware constraints, we have to
implement clearing the relationship by binding all queues to the last
interrupt vector and reserving the last interrupt vector, this method
results in a decrease of the maximum queues when upper applications call
the rte_eth_dev_configure API function to enable Rx interrupt.
Fixes: 02a7b55657 ("net/hns3: support Rx interrupt")
Cc: stable@dpdk.org
Signed-off-by: Hao Chen <chenhao164@huawei.com>
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
This patch adds TCP segment offload support for hns3 PMD driver.
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Because the rte layer of DPDK framework has already processed the case
when the idx is zero before calling the '.mac_addr_remove' ops function,
the input parameter named idx can not be zero in the '.mac_addr_remove'
function. This patch removes unnecessary branch process to check whether
input parameter named idx is zero in the '.mac_addr_remove' ops
implementation function named hns3_remove_mac_addr.
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
