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>
As FEC is not supported below 10 Gbps,
CMD(HNS3_OPC_CONFIG_FEC_MODE) offered from
Firmware read will return fail in 10 Gbps device.
This patch will prevent read this CMD when below 10 Gbps,
as this is non-sense.
Fixes: 9bf2ea8dbc ("net/hns3: support FEC")
Cc: stable@dpdk.org
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Here the printing of MAC addresses is adjusted. After the
modification, only some bytes of the MAC address are
displayed.
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.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>
The HW and SW DCB configurations need to be updated only
after the DCB configuration information changed. But the
change of tx/rx queue number is ignored. If user decreases
the number of tx queue after configuring multi-TC, the queue
mapping information in hns3_tc_queue_info can not be updated.
And then accessing the released queue resource in
"hns3_init_tx_ring_tc" will trigger a segment fault.
Fixes: 62e3ccc2b9 ("net/hns3: support flow control")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Reasons for building not supported generally start with lowercase
because printed as the second part of a line.
Other changes:
- "linux" should be "Linux" with a capital letter.
- ARCH_X86_64 may be simply x86_64.
- aarch64 is preferred over arm64.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: David Marchand <david.marchand@redhat.com>
According to bit operator reliability style, variables in
the right expression participating int bit operation
must be an unsigned type.
Signed-off-by: Hongbo Zheng <zhenghongbo3@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>
Here adds a check for the return value when calling
rte_pci_write_config.
Coverity issue: 363714
Fixes: cea37e5133 ("net/hns3: fix FLR reset")
Cc: stable@dpdk.org
Signed-off-by: Lijun Ou <oulijun@huawei.com>
According to the rule of the used static check tool,
each member is initialized on a separate lines when
struct and union members are initialized, here is
tempting to adjust some code lines in order to remove
the warning.
Signed-off-by: Hongbo Zheng <zhenghongbo3@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>
Scheduling rate of port-level in hns3 PF driver configured to
hardware is obtained from firmware, which determines the
bandwidth capability of the port. The rate in firmware is
generally configured with the maximum value for network engine
supporting multiple rates, such as 10G and 25G. It may cause
the following issues:
1) When a 10G optical module is used on the network engine, scheduling
rate of this port will also be configured to hardware with 25G.
However, the MAC rate of this port is 10G. In this case, it is
unreasonable that the port scheduling rate is different from the MAC
rate.
2) If default speed in firmware is not the maximum value, the 25G port
may not reach the capability of the port.
Therefore, we fix configurations of port-level scheduling rate
according to updating of MAC link speed.
Fixes: 59fad0f321 ("net/hns3: support link update operation")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@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>
For Kunpeng920, both tx and rx promisc is set when the promisc mode
is enabled. In other words, all the ingress packets and the packets sent
from the PF and other VFs on the same physical port will be copied
to the function which set promisc mode on.
Kunpeng930 support to turn off the tx unicast promisc. A limit promisc
mode is introduced, which means turn off the tx unicast promisc when
promisc is set.
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
The ARM SVE vector implementation defined macro is
__ARM_FEATURE_SVE and RTE_MACHINE_CPUFLAG macros
have replaced by regular compiler macros.
Besides, we remove the unused macro RTE_LIBRTE_HNS3_INC_VECTOR_SVE.
Fixes: 952ebacce4 ("net/hns3: support SVE Rx")
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Currently hns3vf_reinit_dev only judge whether the return value of
setting PCI bus function is not 0, while it will return a negative
value when execute failed.
Fixes: 243651cb6c ("net/hns3: check PCI config space reads")
Cc: stable@dpdk.org
Signed-off-by: Hongbo Zheng <zhenghongbo3@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>
There are coverity defects related "calling
hns3_reset_all_tqps without checking return value
in hns3_do_start".
This patch fixes the warning by add "void" declaration
because here is exception handling, hns3_reset_all_tqps
will have the corresponding error message if it is
handled incorrectly, so it is not necessary to check
hns3_reset_all_tqps return value, here keep ret as the
error code causing the exception.
Coverity issue: 363048
Fixes: fa29fe45a7 ("net/hns3: support queue start and stop")
Cc: stable@dpdk.org
Signed-off-by: Hongbo Zheng <zhenghongbo3@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>
Currently, driver uses the maximum number of queues configured by user
as the maximum queue id that can be specified by the RSS rule or the
reta_update api. It is unreasonable and may trigger an incorrect
behavior in the multi-TC scenario. The driver must ensure that the queue
id configured in the redirection table must be within the range of the
number of queues allocated to a TC.
Fixes: c37ca66f2b ("net/hns3: support RSS")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@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>
For Kunpeng930 NIC hardware, it supports to use dst/src port to
RSS hash for ipv6-sctp packet type. However, the Kunpeng920 NIC
hardware is different with it. The Kunpeng920 NIC only supports
dst/src ip to RSS hash for ipv6-sctp packet type.
Signed-off-by: Lijun Ou <oulijun@huawei.com>
The legacy filter API, including rte_eth_dev_filter_supported() and
rte_eth_dev_filter_ctrl() is removed. Flow API should be used.
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
Since each version map file is contained in the subdirectory of the library
it refers to, there is no need to include the library name in the filename.
This makes things simpler in case of library renaming.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Rosen Xu <rosen.xu@intel.com>
Queue stats are stored in 'struct rte_eth_stats' as array and array size
is defined by 'RTE_ETHDEV_QUEUE_STAT_CNTRS' compile time flag.
As a result of technical board discussion, decided to remove the queue
statistics from 'struct rte_eth_stats' in the long term.
Instead PMDs should represent the queue statistics via xstats, this
gives more flexibility on the number of the queues supported.
Currently queue stats in the xstats are filled by ethdev layer, using
some basic stats, when queue stats removed from basic stats the
responsibility to fill the relevant xstats will be pushed to the PMDs.
During the switch period, temporary 'RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS'
device flag is created. Initially all PMDs using xstats set this flag.
The PMDs implemented queue stats in the xstats should clear the flag.
When all PMDs switch to the xstats for the queue stats, queue stats
related fields from 'struct rte_eth_stats' will be removed, as well as
'RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS' flag.
Later 'RTE_ETHDEV_QUEUE_STAT_CNTRS' compile time flag also can be
removed.
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Haiyue Wang <haiyue.wang@intel.com>
Acked-by: Xiao Wang <xiao.w.wang@intel.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
Change eth_dev_stop_t return value from void to int.
Make eth_dev_stop_t implementations across all drivers to return
negative errno values if case of error conditions.
Signed-off-by: Ivan Ilchenko <ivan.ilchenko@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
The function rte_eth_dev_release_port() is partially resetting
the struct rte_eth_dev. The drivers were completing this reset
with more pointers set to NULL in the close or remove operations.
More pointers are reset at ethdev level,
and some redundant assignments are removed from PMDs.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Reviewed-by: Haiyue Wang <haiyue.wang@intel.com>
Acked-by: Jeff Guo <jia.guo@intel.com>
Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
When closing a port, it is supposed to be already stopped,
and marked as such with "dev_started" state zeroed by the stop API.
Resetting "dev_started" before calling the driver close operation
was hiding the case of not properly stopped port being closed.
The flag "dev_started" is not changed anymore in "rte_eth_dev_close()".
In case the "dev_stop" function is called from "dev_close",
bypassing "rte_eth_dev_stop()" API,
the "dev_started" state must be explicitly reset in the PMD
in order to keep the same behaviour.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.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>
Forward error correction (FEC) is a bit error correction mode.
It adds error correction information to data packets at the
transmit end, and uses the error correction information to correct
the bit errors generated during data packet transmission at the
receive end. This improves signal quality but also brings a delay
to signals. This function can be enabled or disabled as required.
This patch adds FEC support for ethdev.Introduce ethdev
operations which support query and config FEC information in
hardware.
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Reviewed-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Reviewed-by: Chengwen Feng <fengchengwen@huawei.com>
Reviewed-by: Chengchang Tang <tangchengchang@huawei.com>
When an error occurs in the reset process, -EIO is returned.
The assignment of ret here is redundant, so deleted it.
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@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>
Currently, max scheduling rates configuration of pg, pri and port are
set to 100000Mbps, which is the maximum bandwidth of hns3 network engine
with revision_id equals 0x21. However, max scheduling rate configuration
should be set to hardware based on the actual hardware board
environment.
The max_tm_rate in struct hns3_hw, meaning the rate, is obtained from
firmware. So we should use the variable to configure the max scheduling
rate.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
In order to have more flexible selection of shapping algorithm based on
different versions of hns3 network engine, moves the algorithm of
calculating shapping parameter to firmware to execute. If bit
HNS3_TM_RATE_VLD_B of flag field of struct named hns3_pri_shapping_cmd,
hns3_pg_shapping_cmd or hns3_port_shapping_cmd is set to 1, firmware of
network engine, which device revision_id is greater than and equal to
0x30, will recalculate the shapping parameters according to the xxx_rate
field of struct hns3_xxx_shapping_cmd and the opcode of scheduling
level, and configure to hardware.
But driver still needs to calculate shapping parameters and configure
firmware, so as to be compatible with the network engine with
revision_id eqauls 0x21. And the rate and the flag will be ignored based
on the network engine with revision_id equals 0x21.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
The API of rte_flow_error_set is used to pass detail error information
to caller, this patch sets suitable type when calling rte_flow_error_set
API.
Fixes: fcba820d9b ("net/hns3: support flow director")
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>
Because the macro named RTE_FLOW_ERROR_TYPE_ACTION_CONF indicates a
action configuration and the macro named RTE_FLOW_ERROR_TYPE_ACTION
indicates a specific action, the driver needs to return
RTE_FLOW_ERROR_ACTION_CONF type and notify the user when a RSS
configuration is invalid with actions list in the internal function
named hns3_parse_rss_filter called by the '.validate' ops implementation
function named hns3_flow_validate.
Besides, this patch removes some unnecessary judgment lines in
hns3_parse_rss_filter.
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>
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>
The maximum number of queues for one TC hns3 PF PMD driver supported is
64 based on hns3 network engine with revision_id equals 0x21, while it
is expanded up to 512 on hns3 network engine with revision_id equals
0x30.
So the following points need to be modified to maintain better
compatibility.
1) Using a extended rss_size_max field as the maximum queue number of
one TC PF driver supported.
2) The data type of the RSS redirection table needs to be changed from
uint8_t to uint16_t.
3) rss_tc_mode modification
The bitwidth of tc_offset, meaning the rx queue index, has to expand
from 10 bit to 11 bits. The tc_size, meaning the exponent with base 2
of queues supported on TC, needs to expand from 3 bits to 4 bits.
4) RSS indirection table modification
Currently, a field with 7 bits width is used to record the queue
index for RSS indirection table. It means that PF needs to expand the
queue index field to 9 bits. As the RSS indirection table config
command reserved 4 bytes to configure the RSS queue index, a extern
field can be added. So an entries of RSS indirection table queue
index has two fields to set: rss_result_l and rss_result_h, while
rss_result_l records the lower 8 bits and rss_result_h records the
higher 1 bit.
In addition, 2~4 modifications is also compatible with hns3 VF PMD
driver.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
The temporary flag RTE_ETH_DEV_CLOSE_REMOVE is removed.
It was introduced in DPDK 18.11 in order to give time for PMDs to migrate.
The old behaviour was to free only queues when closing a port.
The new behaviour is calling rte_eth_dev_release_port() which does
three more tasks:
- trigger event callback
- reset state and few pointers
- free all generic port resources
The private port resources must be released in the .dev_close callback.
The .remove callback should:
- call .dev_close callback
- call rte_eth_dev_release_port()
- free multi-port device shared resources
Despite waiting two years, some drivers have not migrated,
so they may hit issues with the incompatible new behaviour.
After sending emails, adding logs, and announcing the deprecation,
the only last solution is to declare these drivers as unmaintained:
ionic, liquidio, nfp
Below is a summary of what to implement in those drivers.
* The freeing of private port resources must be moved
from the ".remove(device)" function to the ".dev_close(port)" function.
* If a generic resource (.mac_addrs or .hash_mac_addrs) cannot be freed,
it must be set to NULL in ".dev_close" function to protect from
subsequent rte_eth_dev_release_port() freeing.
* Note 1:
The generic resources are freed in rte_eth_dev_release_port(),
after ".dev_close" is called in rte_eth_dev_close(), but not when
calling ".dev_close" directly from the ".remove" PMD function.
That's why rte_eth_dev_release_port() must still be called explicitly
from ".remove(device)" after calling the ".dev_close" PMD function.
* Note 2:
If a device can have multiple ports, the common resources must be freed
only in the ".remove(device)" function.
* Note 3:
The port is supposed to be in a stopped state when it is closed.
If it is not the case, it is free to the PMD implementation
how to react when trying to close a non-stopped port:
either try to stop it automatically or just return an error.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Reviewed-by: Liron Himi <lironh@marvell.com>
Reviewed-by: Haiyue Wang <haiyue.wang@intel.com>
Acked-by: Jeff Guo <jia.guo@intel.com>
Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
The device operation .dev_close was returning void.
This driver interface is changed to return an int.
Note that the API rte_eth_dev_close() is still returning void,
although a deprecation notice is pending to change it as well.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Reviewed-by: Rosen Xu <rosen.xu@intel.com>
Reviewed-by: Sachin Saxena <sachin.saxena@oss.nxp.com>
Reviewed-by: Liron Himi <lironh@marvell.com>
Reviewed-by: Haiyue Wang <haiyue.wang@intel.com>
Acked-by: Jeff Guo <jia.guo@intel.com>
Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Currently, when calling the rte_flow_query API function to query the RSS
information, the queue related information is not as expected.
The root cause is that when application call the rte_flow_create API
function to create RSS action, the operation of storing the data whose typs
is struct rte_flow_action_rss is incorrect in the '.create' ops
implementation function named hns3_flow_create.
This patch fixes it by replacing memcpy with hns3_rss_conf_copy function to
store the RSS information in the hns3_flow_create.
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>
