For Kunpeng930, the NIC engine support 1280 tqps being taken over by
a PF. In this case, a maximum of 1281 interrupt resources are also
supported in this PF. To support the maximum number of queues, several
patches are made. But the interrupt related modification are missing.
So, in RX interrupt mode, a large number of queues will be aggregated
into one interrupt due to insufficient interrupts. It will lead to
waste of interrupt resources and reduces usability.
To utilize all these interrupt resources, related IMP command has been
extended. And, the I/O address of the extended interrupt resources are
different from the existing ones. So, a function used for calculating
the address offset has been added.
Fixes: 76d794566d ("net/hns3: maximize queue number")
Fixes: 27911a6e62 ("net/hns3: add Rx interrupts compatibility")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
One of the hot discussions in community recently was moving queue stats
to xstats. In this solution, a temporary
'RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS' device flag is created to implement
the smooth switch. And the first half of this work has been completed in
the ethdev framework. Now driver needs to remove the flag from the
driver initialization process and does the rest of work.
For better readability and reasonability, per-queue stats also should be
cleared when rte_eth_stats is cleared. Otherwise, the sum of one item in
per-queue stats may be greater than corresponding item in rte_eth_stats.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
pkt_len_errors and l2_errors in Rx datapath indicate that driver
needs to discard received packets. And driver does not discard
packets for l3/l4/ol3/ol4_csum_errors in Rx datapath and others
stats in Tx datapath. Therefore, it is necessary for improving
code readability and maintainability to encapsulate error stats
and dfx stats.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
The rte_ethdev_driver.h, rte_ethdev_vdev.h and rte_ethdev_pci.h files are
for drivers only and should be a private to DPDK and not installed.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Steven Webster <steven.webster@windriver.com>
Use C11 atomic builtins with explicit ordering instead of
rte_atomic ops with the resetting member of hns3_reset_data
structure.
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Building with SVE extension enabled stopped with error:
error: ACLE function ‘svwhilelt_b64_s32’ requires ISA extension ‘sve’
18 | #define PG64_256BIT svwhilelt_b64(0, 4)
This is caused by unintentional cflags reset.
Fixed the issue by not touching cflags, and using flags defined by
compiler.
Fixes: 952ebacce4 ("net/hns3: support SVE Rx")
Cc: stable@dpdk.org
Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
For kupeng 930, there are 3 registers to control the enable
status of a TQP(i.e. task queue pair, include a txq and a rxq).
One of them controls whether the TQP is enabled, and the other
two controls whether the rxq and txq are enabled. The registers
used to control the enabled status of the rxq and txq are enabled
by default. Therefore, after the TQP is enabled, the rxq and txq
are enabled by default.
Currently, when the number of rxq is not equal to the number of txq, the
unused rxqs or txqs are not disabled by driver, so these unused queues
will be enabled in this situation. And the related HW rings have not
been initialized which could lead to a hardware exception.
This patch fix it by disable these unused queues during enable the TQPs.
Fixes: fa29fe45a7 ("net/hns3: support queue start and stop")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
According to the rule of the static check tools
that arrange blank lines properly to keep the
code compact, here remove some unnecessary blank
line to fix the above rule warning.
Signed-off-by: Lijun Ou <oulijun@huawei.com>
FLR operation will reset the queue enabling state and
the driver needs to restore the state after reset.
If the driver does not restore the state, it will result
in unpredictable behavior with reset when user start or
stop queue by calling the relevant function if.
This patch fix it by add a queue enabling state restore
function to the reset handler.
Fixes: fa29fe45a7 ("net/hns3: support queue start and stop")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
In current driver print log function, some print format
symbols does not match with the actual variable types.
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Some header files have included by others. Also,
some header files have a header file self-contained
error will trigger building warning. As a result,
it is unnecessary and move it into the correct
location.
Beside, here also remove some unused lines.
Signed-off-by: Lijun Ou <oulijun@huawei.com>
If hardware does not support QL (quantity limiter), the int_ql_max
is 0, software should confirm ql_value is less than int_ql_max
before write QL register. This patch add check of int_ql_max
value from firmware and delete the unused variable coalesce_mode.
Fixes: 27911a6e62 ("net/hns3: add Rx interrupts compatibility")
Cc: stable@dpdk.org
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Kupeng920 support tso and checksum offload for VXLAN_GPE with
the next protocol id 3(i.e., Ethernet).
Kupeng930 support TSO and checksum offload for VXLAN_GPE with
the next protocol id 1,2,3(i.e., IPv4, IPv6 and Ethernet).
This patch add support for this tunnel type.
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Currently, the header length of all the layers are fixed, It would
lead to a csum error when the header length changed.
This patch fixes above problem by using the header length in mbuf
instead of the fixed header length to perform the TX cksum offload.
Fixes: bba6366983 ("net/hns3: support Rx/Tx and related operations")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Currently, there are two mistakes in Tx checksum outer header prepare.
1) Check whether the packet outer header is IPV4 based on PKT_TX_IPV4
which is incorrect.
2) For HIP08, the outer UDP cksum could not be offloaded. And driver
should ensure the outer udp cksum filed set to 0. In current code,
PKT_TX_UDP_CKSUM is used to determine whether the outer layer of
the packet is a UDP header. Actually, for tunnel TSO, the flag will
never be set.
For the first mistake, it is fixed by replacing PKT_TX_IPV4 with
PKT_TX_OUTER_IPV4. And the protocol number in L3 header is used to check
whether the outer L4 header is UDP.
Fixes: bba6366983 ("net/hns3: support Rx/Tx and related operations")
Fixes: 6dca716c9e ("net/hns3: support TSO")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Currently, the rx HW ring is not cleared after queue stop.
When there are packets remaining in the HW rings and the
queues have been stopped, if upper layer user calls the
rx_burst function at this time, an illegal memory access
will occur due to the sw rings has been released.
This patch fix this by reset the sw ring after disable the
queue.
Fixes: fa29fe45a7 ("net/hns3: support queue start and stop")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Currently, u8 type variable is used to control to release fake queues in
hns3_fake_rx/tx_queue_config function. Although there is no case in
which more than 256 fake queues are created in hns3 network engine, it
is unreasonable to compare u8 variable with u16 variable.
Fixes: a951c1ed3a ("net/hns3: support different numbers of Rx and Tx queues")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Currently, hns3 supports recognizing a lot of ptypes, but most
tunnel packet types are not reported to the API
rte_eth_dev_get_supported_ptypes.
And there are some errors in L2 and L3 packet recognition. The
ARP and LLDP are classified to L3 field in RX descriptor. So,
the ptype of LLDP and ARP packets will be set twice. And ptypes
are assigned by bitwise OR, which will eventually cause the ptype
result to be incorrect.
Besides, when a packet with only L2 header, its ptype will not
report by hns3 PMD. This is because the L2/L3 ptype table is not
initialized properly. In this case, the table query result is 0
by default.
As a result, it fixes missing supported ptypes and the mistake in
L2/L3 packet recognition and the unreported L2 packet ptype by
reporting its L2 type when the L3 type unrecognized..
Fixes: bba6366983 ("net/hns3: support Rx/Tx and related operations")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Implement the available and used rxd number count function.
In Kunpeng series, the NIC hardware supports to read the bd numbers
which wait processed from the hardware FBD (Full Buffer Descriptor),
and the driver maintains the bd number to be written back hardware.
Compare the number of FBDs with the number of BDs to be written back to
the hardware.
The number of used descriptors of a rx queue is computed as follows:
The fbd numbers of reading from FBD register plus the bd numbers to be
written back to hardware maintained by the driver.
Signed-off-by: Lijun Ou <oulijun@huawei.com>
This patch adds SVE vector instructions to optimize Tx burst process.
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>
The new generation hns3 network engine supports independent enabling and
disabling of a single Tx/Rx queue. So, it can support the queue start
and stop feature. In addition, when different numbers of Tx and Rx
queues need to be enabled in some applications, hns3 pmd does not need
to create fake queues to enable these scenarios.
This patch Add queue start and stop feature for the new generation hns3
networking engine. Cancel the creation of fake queue on the new
generation network engine. And the previously improperly named queue
related function was renamed to improve readability.
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
The maximum number of queues for hns3 PF and VF driver is 64 based on
hns3 network engine with revision_id equals 0x21. Based on hns3 network
engine with revision_id equals 0x30, the hns3 PF PMD driver can support
up to 1280 queues, and hns3 VF PMD driver can support up to 128 queues.
The following points need to be modified to support maximizing queue
number and maintain better compatibility:
1) Maximizing the number of queues for hns3 PF and VF PMD driver In
current version, VF is not supported when PF is driven by hns3 PMD
driver. If maximum queue numbers allocated to PF PMD driver is less
than total tqps_num allocated to this port, all remaining number of
queues are mapped to VF function, which is unreasonable. So we fix
that all remaining number of queues are mapped to PF function.
Using RTE_LIBRTE_HNS3_MAX_TQP_NUM_PER_PF which comes from
configuration file to limit the queue number allocated to PF device
based on hns3 network engine with revision_id greater than 0x30. And
PF device still keep the maximum 64 queues based on hns3 network
engine with revision_id equals 0x21.
Remove restriction of the macro HNS3_MAX_TQP_NUM_PER_FUNC on the
maximum number of queues in hns3 VF PMD driver and use the value
allocated by hns3 PF kernel netdev driver.
2) According to the queue number allocated to PF device, a variable
array for Rx and Tx queue is dynamically allocated to record the
statistics of Rx and Tx queues during the .dev_init ops
implementation function.
3) Add an extended field in hns3_pf_res_cmd to support the case that
numbers of queue are greater than 1024.
4) Use new base address of Rx or Tx queue if QUEUE_ID of Rx or Tx queue
is greater than 1024.
5) Remove queue id mask and use all bits of actual queue_id as the
queue_id to configure hardware.
6) Currently, 0~9 bits of qset_id in hns3_nq_to_qs_link_cmd used to
record actual qset id and 10 bit as VLD bit are configured to
hardware. So we also need to use 11~15 bits when actual qset_id is
greater than 1024.
7) The number of queue sets based on different network engine are
different. We use it to calculate group number and configure to
hardware in the backpressure configuration.
8) Adding check operations for number of Rx and Tx queue user configured
when mapping queue to tc Rx queue numbers under a single TC must be
less than rss_size_max supported by a single TC. Rx and Tx queue
numbers are allocated to every TC by average. So Rx and Tx queue
numbers must be an integer multiple of 2, or redundant queues are not
available.
9) We can specify which packets enter the queue with a specific queue
number, when creating flow table rules by rte_flow API. Currently,
driver uses 0~9 bits to record the queue_id. So it is necessary to
extend one bit field to record queue_id and configure to hardware, if
the queue_id is greater than 1024.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
In kunpeng 920, when process pkts which need TSO, the network driver
need to erase the L4 len value of the TCP TSO pseudo header and
recalculate the pseudo header checksum. kunpeng930 support not need
to erase the L4 len value of the TCP TSO pseudo header.
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Kunpeng 920 supports the maximum nb_segs of non-tso packet is 8 in Tx
direction, kunpeng 930 expands this limit value to 18, this patch sets
the corresponding value by querying the maximum number of non-tso nb_segs
supported by the device during initialization.
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
This patch solves the static check warning as follow:
"The switch statement must have a 'default' branch".
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Because of hardware limitation based on the old version of hns3 network
engine, there are some restrictions:
a) HNS3 PMD driver needs select different processing mode for VLAN based
on whether PVID is set which means our driver need sense the PVID
states.
b) For packets transmitting process, only two layer of VLAN tag is
supported. If the total number of VLAN tags in mbuf and VLAN offload
by hardware (VLAN insert by descriptor) exceeds two, the VLAN in mbuf
will be overwritten by VLAN in the descriptor.
c) If port based VLAN is set, only one VLAN header is allowed in mbuf or
it will be discard by hardware.
In order to solve these restriction, two change is implemented on the
new versions of network engine.
1) add a new VLAN tagged insertion mode, named tag shift mode;
2) add a new VLAN strip control bit, named strip hide enable;
The tag shift mode means that VLAN tag will shift automatically when the
inserted place has a tag. For PMD driver, the VLAN tag1 and tag2
configurations in Tx side do not need to be considered because the
hardware completes it. However, the related configuration will still be
retained to be compatible with the old version of network engine.
The VLAN strip hide means that hardware will strip the VLAN tag and hide
VLAN in descriptor (VLAN ID exposed as zero and related STRIP_TAGP is
off).
These changes make it no longer necessary for the hns3 PMD driver to be
aware of the PVID status and have the ability to send mult-layer (more
than two) VLANs packets. Therefore, hns3 PMD driver introduces the
concept of VLAN mode and adds a new VLAN mode named HNS3_PVID_MODE to
indicate that PVID-related IO process can be implemented by the
hardware. And VF driver does not need to be modified because the related
mailbox messages will not be sent by PF kernel mode netdev driver under
new network engine and all the related hardware configuration is on the
PF side.
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Currently, there is a possibility that segment faults occur when sending
packets whose payloads are stored in multiple buffers based on hns3
network engine. The related core dump information as follows:
Program terminated with signal 11, Segmentation fault.
0 hns3_reassemble_tx_pkts
2512 temp = temp->next;
Missing separate debuginfos, use:
(gdb) bt
0 hns3_reassemble_tx_pkts
1 0x0000000000969c60 in hns3_check_non_tso_pkt
2 0x000000000096adbc in hns3_xmit_pkts
3 0x000000000050d4d0 in rte_eth_tx_burst
4 0x000000000050fca4 in pkt_burst_transmit
5 0x00000000004ca6b8 in run_pkt_fwd_on_lcore
6 0x00000000004ca7fc in start_pkt_forward_on_core
7 0x00000000006975a4 in eal_thread_loop
8 0x0000ffffa6f7fc48 in start_thread
9 0x0000ffffa6ed1600 in thread_start
The root cause is that hns3 PMD driver invokes the rte_pktmbuf_free_seg
API function to release the same rte_mbuf multiple times. The rte_mbuf
pointer is not set to NULL in the internal function
hns3_rx_queue_release_mbufs which is invoked during queue setup, stop
and close. As a result the rte_mbuf in Rx queues will be repeatedly
released when the user application setup queues or stop/start the dev
for multiple times.
Probably for performance reasons, DPDK mempool lib does not check for
the repeated rte_mbuf releases. The Address of released rte_mbuf are
directly stored into the per lcore cache of the mempool. This makes the
rte_mbufs obtained from mempool by calling rte_mempool_get_bulk API
function repetitively. ultimately, it causes to access to a NULL
pointer in PMD driver.
This patch fixes this problem by setting released mbuf pointer to NULL
in the internal function named hns3_rx_queue_release_mbuf. And the other
internal function named hns3_reassemble_tx_pkts is optimized to avoid a
similar problem.
Fixes: bba6366983 ("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>
This patch adds simple Tx process function. When multiple segment
packets are not needed, Which means that DEV_TX_OFFLOAD_MBUF_FAST_FREE
offload is not set, we can simple Tx process.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
This patch adds simple Rx process function and support chose Rx function
by real Rx offloads capability.
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 adds the internal function named hns3_write_reg_opt to avoid
performance loss from address calculation during register access in the
'.rx_pkt_burst' ops implementation function named hns3_recv_pkts.
In addition, because hardware always access register in little-endian
mode based on hns3 network engine, so driver should also call
rte_cpu_to_le_32 to convert data in little-endian mode before writing
register and call rte_le_to_cpu_32 to convert data after reading from
register. Here the driver encapsulates the data conversion operation in
the register read/write operation function as below:
hns3_write_reg
hns3_write_reg_opt
hns3_read_reg
Therefore, when calling these functions, conversion is not required
again.
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
This patch reports .rx_free_thresh value in the .dev_infos_get ops
implementation function named hns3_dev_infos_get and
hns3vf_dev_infos_get.
In addition, the name of the member variable of struct hns3_rx_queue is
modified and comments are added to improve code readability.
Signed-off-by: Chengwen Feng <fengchengwen@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 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>
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>
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: bba6366983 ("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: 6dca716c9e ("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>
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: bba6366983 ("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: bba6366983 ("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>
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>
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, 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>
