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: 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 the following commands in the CLI of testpmd
application, the driver reports an -EINVAL error when performing the No.3
step.
1) flow create 0 ingress pattern end actions rss key <key> func simple_xor
types all end / end
2) flow flush 0
3) port config dcb vt off pfc off
The root cause as below:
In the No.2 step, when RSS rules is flushed, we set the the flag
hw->rss_dis_flag with true to indicate RSS id disabled. And in the No.3
step, calling rte_eth_dev_configure API function, the internal function
named hns3_dev_rss_hash_update check hw->rss_dis_flag is true and return
-EINVAL.
When user calls the rte_eth_dev_configure API function with the input
parameter dev_conf->rxmode.mq_mode having ETH_MQ_RX_RSS_FLAG to enable RSS,
driver should set internal flag hw->rss_dis_flag with false to indicate RSS
is enabled in the '.dev_configure' ops implementation function named
hns3_dev_configure and hns3vf_dev_configure.
Fixes: 5e782bc2570c ("net/hns3: fix configuring RSS hash when rules are flushed")
Cc: stable@dpdk.org
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
When user create a flow without RSS by calling rte_flow_create API and then
destroy it by calling rte_flow_flush API, driver should not clear RSS rule.
A reasonable handling method is that when user creates an RSS rule, the
driver should clear the created RSS rule when flushing destroy all flow
rules. Also, hw->rss_info should save the RSS config of the last success
RSS rule. When create n RSS rules, the RSS should not be disabled before
the last RSS rule destroyed.
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>
When user specifies RSS queue num for 0 in action list by flow create API,
it should create a valid flow rule. The following flow rule should be
success in the command line of the testpmd application:
flow create 0 <pattern> actions rss queues / end
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>
Currnetly, when user create a flow RSS rule and then flush the rule, driver
will set 0 for the internal structure of hw->rss_info maintained in driver.
And then user create a flow RSS rule without specified RSS hash key, driver
configure a validate RSS hash key into hardware network engine and will
cause an RSS error. The related steps when using testpmd as
follows:
flow 0 <pattern> action rss xx end / end
flow flush 0
flow 0 <pattern> action rss queues 0 1 end / end
To slove the preceding problem, the flow flush processing is modified.
it don't clear all RSS configurations for hw->rss_info. Actually the RSS
key information in the hardware is not cleared, therefore, the
hw->rss_info.key is kept consistent with the value in the hardware. In
addition, because reset the redirection table, we need to set queues NULL
and queue_num for zero that indicate the corresponding parameters in the
hardware is unavailable. Also we set hw->rss_info.func to
RTE_ETH_HASH_FUNCTION_MAX that indicate it is invalid.
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>
This patch support for hash type input set configuration. That is, upper
level application can call the rte_flow_create or
rte_eth_dev_rss_hash_update API to set the specified tuples by RSS types.
As a result, the hardware can selectively use the tuples to perform hash
calculation based on the specific tuple to enable the fields.
The following uses the RSS flow as an example:
When application calls the rte_flow_create API to select tuple input for
ipv4-tcp l3-src-only, the driver can enable the ipv4-tcp src field of the
hardware register by calling the internal function named
hns3_set_rss_tuple_by_rss_hf according to the RSS types in actions list.
In testpmd application, the command as follows:
testpmd> flow create 0 ingress pattern end actions rss types \
ipv4-tcp l3-src-only end queues 1 3 end / end
The following use the rte_eth_dev_rss_hash_update as an example:
if the user set the select tuple input for ipv4-tcp l3-src-only by
rte_eth_rss_conf structure in rte_eth_dev_rss_hash_update. the next
flow is the same as that of the RSS flow. In testpmd application,
the command as follows:
testpmd> port config all rss ipv4-tcp l3-src-only
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
This patch adds checking the input RSS type when creating a flow with RSS.
If the input RSS type are not supported based on hns3 network engine, an
error is returned.
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
This patch enables to query some RSS configurations of the specified
rule. For example, show RSS hash function and rss types.
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Kunpeng 930 hardware support spread packets to region of queues which can
be configured by FDIR rule, it means user can create one FDIR rule which
action is one region of queues, and then RSS use the region info to spread
packets.
As we know, RTE_FLOW_ACTION_TYPE_RSS is used to spread packets among
several queues, user could config such as func/level/types/key/queue
parameter to control RSS function, so we provide this feature under the
RTE_FLOW_ACTION_TYPE_RSS framework.
Consider RSS input tuple don't have eth header, we use the following
rule to distinguish them (whether it's queue region configuration or
rss general configuration):
Case 1: pattern have ETH and action's queue_num > 0, indicate it is
queue region configuration.
Case other: rss general configuration.
So if user want to configure one flow which ipv4=192.168.1.192 spread to
queue region of queue 0/1/2/3, the patter should:
RTE_FLOW_ITEM_TYPE_ETH with spec=last=mask=NULL
RTE_FLOW_ITEM_TYPE_IPV4 with spec=192.168.1.192 last=mask=NULL
RTE_FLOW_ITEM_TYPE_END
the action should:
RTE_FLOW_ACTION_TYPE_RSS with queue_num=4 queue=0/1/2/3
RTE_FLOW_ACTION_TYPE_END
after calling rte_flow_create, one FDIR rule will be created.
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
This patch solves the redundant operation during traversal. In the internal
function named hns3_error_int_stats_add for adding error statistics,
because only one statistical item will be found in the for loop statement,
a break can be executed after finding the error statistical item without
traversing the remaining table entries.
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
This patch solves the static check warning in the internal function named
hns3_fd_convert_tuple as follow:
"The switch statement must have a 'default' branch".
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
According to the protocol of PCIe, FLR to a PF device resets the PF state
as well as the SR-IOV extended capability including VF Enable which means
that VFs no longer exist.
When PF device is in FLR reset stage, at this time, the register state
of VF device is not reliable, so VF device's register state detection
is not carried out in PF FLR.
In this case, we just ignore the register states to avoid accessing
nonexistent register and return false in the internal function named
hns3vf_is_reset_pending to indicate that there are no other reset states
that need to be processed by PMD driver.
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>
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>
Currently, the default VLAN (vlan id 0) will never be deleted from the
hardware VLAN table based on hns3 PF device. As a result, even a
non-zero PVID is set by calling rte_eth_dev_set_vlan_pvid based on hns3
PF device, packets with VLAN 0 and without VLAN are still received by PF
driver in Rx direction.
This patch deletes the restriction that VLAN 0 cannot be removed in PVID
configuration to ensure packets without PVID will be filtered when PVID
is set. And the patch adds VLAN 0 to the soft list when initializing
vlan configuration to ensure that VLAN 0 will be deleted from the
hardware VLAN table when device is closed.
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>
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: 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>
When Rx of scattered packets is off, we have some possibility of using
vector Rx process function or simple Rx functions in hns3 PMD driver.
If the input MTU is increased and the maximum length of received packets
is greater than the length of a buffer for Rx packets, the hardware
network engine needs to use multiple BDs and buffers to store these
packets. This will cause problems when still using vector Rx process
function or simple Rx function to receiving packets. So, when Rx of
scattered packets is off and device is started, it is not permitted to
increase MTU so that the maximum length of Rx packets is greater than Rx
buffer length.
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@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>
Currently, offload capabilities are only enabled for all Rx/Tx queues in
hns3 PF/VF PMD driver, and offload capability only applied in a Rx/Tx
queue is not supported.
So this patch moves 'DEV_TX_OFFLOAD_MBUF_FAST_FREE' from
tx_queue_offload_capa to tx_offload_capa.
Fixes: 1f5ca0b460cd ("net/hns3: support some device operations")
Fixes: a5475d61fa34 ("net/hns3: support VF")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
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>
