This patch fixes (out-of-bounds access) coverity issue.
Coverity issue: 349932
Fixes: 7d7f9f80bbfb ("net/hns3: support MAC address related operations")
Cc: stable@dpdk.org
Signed-off-by: Yunjian Wang <wangyunjian@huawei.com>
Reviewed-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
The descriptor of the command between firmware and driver consists of
8-byte header and 24-byte data field. The contents sent to firmware are
packaged into a command structure as the data field of command
descriptor.
There are some command structures in hns3_dcb.h file that are less than
24 byte. So this patch fixes these incomplete command structures.
Fixes: 62e3ccc2b94c ("net/hns3: support flow control")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Currently, default MAC address obtained from firmware in PF driver is
directly used by .mac_addr_set ops implementation function when the
rte_eth_dev_start API function is executed. At this moment, if the
default MAC addr isn't an unicast address, it will fail to set default
MAC addr to hardware.
So this patch adds the validity check of default MAC addr in PF driver.
We will use a random unicast address, if the default MAC address
obtained from firmware is not a valid unicast address.
In addition, this patch also adjusts the location of processing default
MAC addr in VF driver so as to increase relevance and readability of the
code.
Fixes: eab21776717e ("net/hns3: support setting VF MAC address by PF driver")
Fixes: d51867db65c1 ("net/hns3: add initialization")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
This patch uses RTE_MAX function in DPDK lib to replace the private
macro named max_t in driver.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
The FDIR counter was used to count the number of FDIR hit, the maximum
number of the counter is 128 based on kunpeng 920, and it was 256 based
on kunpeng 930.
The firmware is responsible to allocate counters for different PF
devices, so the available counter number of one PF may be bigger than
128.
Currently, there are two places using the counter in driver:
1. Configure the counter. Driver uses the command whose opcode is
HNS3_OPC_FD_AD_OP, now we extend one bit to hold the high bit of
counter-id in the command format.
2. Query the statistic information of the counter. Driver uses the
command whose opcode is HNS3_OPC_FD_COUNTER_OP, now the command
already support 16-bit counter-id.
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
The new firmware adds the hardware error types reported by MSI-x mode.
These errors are defined as RAS errors in hardware and belong to a
different type from the MSI-x errors processed by the driver.
When hardware detects an error which must be handled by the driver for
device to run properly it reports the error information through the
MSI-x interrupt. After receiving the interrupt reported by the hardware,
the driver queries the error information and identifies the error level,
then rectifies the error. All errors will be logged.
In addition, the hardware may be reset at the function or global level
based on the error level. After the reset is complete, the hardware will
recover to the normal status.
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
There are difference about padding ultra-short frame in Tx procession
for different versions of hardware network engine.
If packet length is less than minimum packet length supported by
hardware in Tx direction, driver need to pad it to avoid error. The
minimum packet length in Tx direction is 33 based on kunpeng 920, and 9
based on kunpeng 930.
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
There are difference about queue's interrupt configurations for
different versions of hardware network engine, such as queue's interrupt
mapping mode, coalesce configuration, etc.
The following uses the configuration differences of the interrupt
mapping mode as an example.
1) For some versions of hardware network engine, such as kunpeng 920,
because of the hardware constraint, we need implement unmmapping
relationship configurations by binding all queues to the last
interrupt vector and reserving the last interrupt vector. This
results in a decrease of the maximum queues when upper applications
call the rte_eth_dev_configure API function to enable Rx interrupt.
2) And for another versions, such as kunpeng 930, hns3 PMD driver can
map/unmmap all interrupt vectors with queues when Rx interrupt is
enabled.
This patch resolves configuration differences about Rx interrupts based
on kunpeng 920 and kunpeng 930.
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
This patch adds getting device capabilities from firmware, so driver can
supply different capabilities and specifications to upper level
applications base on different versions of hardware network engine.
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
This patch adds support for querying Rx/Tx queue information.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Currently, if there are not available Rx buffer descriptors in receiving
direction based on hns3 network engine, incoming packets will always be
dropped by hardware. This patch reports the '.rx_drop_en' information to
DPDK framework in the '.dev_infos_get', '.rxq_info_get' and
'.rx_queue_setup' ops implementation function.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
The rte_kernel_driver enum actually only pointed at PCI drivers and is
only used in the PCI subsystem.
Remove it from the generic device API and use a private enum in the PCI
code.
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
A decision was made [1] to no longer support Make in DPDK, this patch
removes all Makefiles that do not make use of pkg-config, along with
the mk directory previously used by make.
[1] https://mails.dpdk.org/archives/dev/2020-April/162839.html
Signed-off-by: Ciara Power <ciara.power@intel.com>
Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Start a new release cycle with empty release notes.
The ABI version becomes 21.0.
The ABI major is back to normal, having only one number (21 vs 20.0).
The map files are updated to the new ABI major number (21).
The ABI exceptions are dropped.
Travis ABI check is disabled because compatibility is not preserved.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Ray Kinsella <mdr@ashroe.eu>
According to the definition of RSS types of action attributes from
testpmd, the driver will not disable RSS but instead requests the
unspecified "best-effort" settings when upper application call
rte_flow_create API function to create flow using empty RSS types.
As a result, here use the default RSS types when RSS types is empty.
Fixes: c37ca66f2b27 ("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>
CRC is the end of frame, which occupies 4 bytes. Keeping CRC is a
feature of MAC, which will not strip CRC field when receiving frames.
The feature can be enabled using DEV_RX_OFFLOAD_KEEP_CRC offload by
upper level application. And the feature is only supported for hns3 PF
PMD driver, not supported for hns3 VF PMD driver
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
The 200G device has a new device id 0xA228, so adds this device id
to pci table for pci driver can probe it. Similar to the network port
with other speed, the hns3 PMD driver gets 200G speed information
from firmware, and passes them to DPDK framework.
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@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.
Copper media type is supported for hns3 PF device in kunpeng 930 and
later SoCs. The configuration operation for PHY is implemented by
firmware.
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Based on hns3 network engine, in order to configure hardware VLAN insert
offload in Tx direction, PMD driver reads the VLAN tags from the
vlan_tci_outer and vlan_tci of the structure rte_mbuf, fills them into
the Tx Buffer Descriptor and sets the related offload flag for every
packet.
Currently, there are two VLAN related problems in the 'tx_pkt_burst' ops
implementation function:
1) When setting the related offload flag, PMD driver inserts the VLAN
tag into the position that close to L3 header. So, when upper
application sends a packet with a VLAN tag in the data buffer, the
VLAN offloaded by hardware will be added to the wrong position. It is
supposed to add the VLAN tag from the rte_mbuf to the position close
to the MAC header in the packet when using VLAN insertion.
And when PF PVID is enabled by calling the API function named
rte_eth_dev_set_vlan_pvid or VF PVID is enabled by hns3 PF kernel
ether driver, the VLAN tag from the structure rte_mbuf to enable the
VLAN insertion should be filled into the position that close to L3
header to avoid to be overwritten by the PVID which will always be
inserted in the position that close to the MAC address.
2) When sending multiple segment packets, VLAN information is required
to be filled into the first Tx Buffer descriptor. However, currently
hns3 PMD driver incorrectly placed it in the last Tx Buffer
Descriptor. This results in VLAN insert offload failure when sending
multiple segment packets.
This patch fixed them by filling the VLAN information into the position
of the Tx Buffer Descriptor.
Fixes: bba636698316 ("net/hns3: support Rx/Tx and 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: Min Hu (Connor) <humin29@huawei.com>
This patch fixes up paylen calculation twice when processing TSO request
in the '.tx_pkt_burst' ops implementation function to avoid performance
loss.
Fixes: 6dca716c9e1d ("net/hns3: support TSO")
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: Hongbo Zheng <zhenghongbo3@huawei.com>
Currently, there is a coverity defect warning about hns3 PMD driver, the
detail information as blow:
CID 289969 (#1 of 1): Unchecked return value (CHECKED_RETURN)
1. check_return: Calling rte_mp_action_register without checking return
value (as is done elsewhere 11 out of 13 times).
The problem is that missing checking the return value of calling the API
rte_mp_action_register during initialization. If registering an action
function for primary and secondary communication failed, the secondary
process can't work properly.
This patch fixes it by adding check return value of the API function
named rte_mp_action_register in the '.dev_init' implementation function
of hns3 PMD driver.
Coverity issue: 289969
Fixes: 23d4b61fee5d ("net/hns3: support multiple process")
Cc: stable@dpdk.org
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Because of the hardware constraints, hns3 network engine doesn't support
sending packets with more than eight fragments. And hns3 pmd driver
tries to reassemble these kind of packets to meet hardware requirements.
Currently, there are two problems:
1) when the input buffer_len * 8 < pkt_len, the packets are impossible
to be reassembled into 8 Buffer Descriptors. In this case, the
packets will be passed to hardware, which eventually causes a
hardware reset.
2) The meta data in origin packets which are required to fill into the
descriptor haven't been copied into the reassembled pkts.
This patch adds a check for 1) to ensure such packets will be dropped by
driver and copies useful meta data from the origin packets to the
reassembled packets.
Fixes: bba636698316 ("net/hns3: support Rx/Tx and 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: Chengwen Feng <fengchengwen@huawei.com>
Currently, rx_buf_size of hns3 PMD driver is fixed on, and it's value
depends on the firmware which will decrease the flexibility of PMD.
The receive side mbufs was allocated from the mempool given by upper
application calling rte_eth_rx_queue_setup API function. So the memory
chunk used for net device DMA is depend on the data room size of the
objects in this mempool. Hns3 PMD driver should set the rx_buf_len
smaller than the data room size of mempool and our hardware only support
the following four specifications: 512, 1024, 2148 and 4096.
Fixes: bba636698316 ("net/hns3: support Rx/Tx and related operations")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
According to the user manual of Kunpeng920 SoC, the max allowed number
of segments per whole packet is 63 and the max number of segments per
packet is 8 in datapath.
This patch reports the Two segment parameters of Tx descriptor
limitations to DPDK framework.
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
When the last driver exits abnormally, for example, it is killed by
'kill -9', it may be too late to clear the configuration and cause the
configuration to remain. Therefore, to ensure that the hardware
environment is clean during initialization, the PF driver actively clear
the hardware environment during initialization, including PF and
corresponding VFs' vlan, mac, flow table configurations, etc.
Fixes: d51867db65c1 ("net/hns3: add initialization")
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: Chengwen Feng <fengchengwen@huawei.com>
This patch optimizes the code to get device capability in primary
process, and moves the code of getting PCI revision id in order to avoid
evaluating the private hw->revision of shared PMD-specific private data
in slave process.
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: Chengchang Tang <tangchengchang@huawei.com>
This patch adds support setting VF PVID by hns3 PF kernel ethdev driver
on the host by "ip link set <eth num> vf <vf id> vlan <vlan tag>"
command.
Because of the hardware constraints, the striped VLAN tag will always in
Rx descriptors which should has been dropped when PVID is enabled and
the PVID will overwrite the outer VLAN tag in Tx descriptor. So, hns3
PMD driver need to change the processing of VLAN tags in the process of
Tx and Rx according to whether PVID is enabled.
1) If the hns3 PF kernel ethdev driver sets the PVID for VF device
before the initialization of the related VF device, hns3 VF PMD
driver should get the PVID state from PF driver through mailbox and
update the related state in txq and rxq maintained by hns3 VF driver
to change the process of Tx and Rx.
2) If the hns3 PF kernel ethdev driver sets the PVID for VF device after
initialization of the related VF device, the PF driver will notify VF
driver to update the PVID state. The VF driver will update the PVID
configuration state immediately to ensure that the VLAN process in Tx
and Rx is correct. But in the window period of this state transition,
packets loss or packets with wrong VLAN may occur.
3) Due to hardware limitations, we only support two-layer VLAN hardware
offload in Tx direction based on hns3 network engine, so when PVID is
enabled, QinQ insert is no longer supported. And when PVID is
enabled, in the following two cases:
i) packets with more than two VLAN tags.
ii) packets with one VLAN tag while the hardware VLAN insert is
enabled.
The packets will be regarded as abnormal packets and discarded by
hardware in Tx direction. For debugging purposes, a validation check
for these types of packets is added to the '.tx_pkt_prepare' ops
implementation function named hns3_prep_pkts to inform users that
these packets will be discarded.
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Currently, hns3 PMD driver needs know the PVID configuration state and
do different processing in the 'rx_pkt_burst' ops implementation
function.
This patch adds a member to struct hns3_rx_queue/hns3_tx_queue of the
driver to indicate the PVID configuration status, so it isn't need
to access other data structure in the 'rx_pkt_burst' ops implementation,
to avoid performance loss because of reducing cache miss.
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
This patch adds support of LRO offload for hns3 PMD driver.
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
This patch adds support of symmetric algorithm of RSS.
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>
Introduce the RTE_LOG_REGISTER macro to avoid the code duplication
in the logtype registration process.
It is a wrapper macro for declaring the logtype, registering it and
setting its level in the constructor context.
Signed-off-by: Jerin Jacob <jerinj@marvell.com>
Acked-by: Adam Dybkowski <adamx.dybkowski@intel.com>
Acked-by: Sachin Saxena <sachin.saxena@nxp.com>
Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
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: 936eda25e8da ("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: fcba820d9b9e ("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: 2790c6464725 ("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: fcba820d9b9e ("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: 6dca716c9e1d ("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: bba636698316 ("net/hns3: support Rx/Tx and related operations")
Fixes: 411d23b9eafb ("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: 411d23b9eafb ("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: c37ca66f2b27 ("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: 19a3ca4c99cf ("net/hns3: add start/stop and configure operations")
Fixes: c37ca66f2b27 ("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: de620754a109 ("net/hns3: fix sending packets less than 60 bytes")
Fixes: bba636698316 ("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: a45fd0aa0ea1 ("net/hns3: fix Rx queue search with broadcast packet")
Fixes: d51867db65c1 ("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: 8839c5e202f3 ("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: ef2e785c36cf ("net/hns3: fix Tx interrupt when enabling Rx interrupt")
Fixes: 02a7b55657b2 ("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: 411d23b9eafb ("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>
