Disable the MAC status report interrupt which hns3 driver not concern
currently.
Fixes: 5f8845f4ba ("net/hns3: process MAC interrupt")
Cc: stable@dpdk.org
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
This patch fixed wrong word in comments.
Fixes: f53a793bb7 ("net/hns3: add more hardware error types")
Fixes: d51867db65 ("net/hns3: add initialization")
Fixes: 411d23b9ea ("net/hns3: support VLAN")
Fixes: 5f8845f4ba ("net/hns3: process MAC interrupt")
Cc: stable@dpdk.org
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
In hns3_mbx.h, some macro and structure were defined in previous
versions but never used.
Fixes: 463e748964 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
The opcode of the link status notification message reported by the
firmware is zero, it will be filtered out because driver treats it as
already processed message. As a result, the PF can't update the link
status in a timely manner.
Because only VF can set opcode to zero when processing mailbox message,
we add a judgment to make sure the PF messages will not be filtered out.
Fixes: dbbbad23e3 ("net/hns3: fix VF handling LSC event in secondary process")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
The hns3_dev_handle_mbx_msg() could be called under both PF and VF,
but the error messages show VF.
Fixes: 109e4dd1bd ("net/hns3: get link state change through mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Fixes a few different things:
* Remove 'fw_version' NULL checks, it is allowed if the 'fw_size' is
zero, 'fw_version' being NULL but 'fw_size' not zero condition checked
in ethdev layer
* Be sure required buffer size is returned if provided one is not big
enough, instead of returning success (0)
* Document in doxygen comment the '-EINVAL' is a valid return type
* Take into account that 'snprintf' can return negative value
* Cast length to 'size_t' to compare it with 'fw_size'
Fixes: bb42aa9ffe ("net/atlantic: configure device start/stop")
Fixes: ff70acdf42 ("net/axgbe: support reading FW version")
Fixes: e2652b0a20 ("net/bnxt: support get FW version")
Fixes: cf0fab1d2c ("net/dpaa: support firmware version get API")
Fixes: 748eccb97c ("net/dpaa2: add support for firmware version get")
Fixes: b883c0644a ("net/e1000: add firmware version get")
Fixes: 293430677e ("net/enic: add handler to return firmware version")
Fixes: 1f5ca0b460 ("net/hns3: support some device operations")
Fixes: bd5b86732b ("net/hns3: modify format for firmware version")
Fixes: ed0dfdd0e9 ("net/i40e: add firmware version get")
Fixes: e31cb9a362 ("net/ice: support FW version getting")
Fixes: 4f09bc55ac ("net/igc: implement device base operations")
Fixes: eec10fb0ce ("net/ionic: support FW version")
Fixes: 8b0b565742 ("net/ixgbe: add firmware version get")
Fixes: 4d9f5b8adc ("net/octeontx2: add FW version get operation")
Fixes: f97b56f9f1 ("net/qede: support FW version query")
Fixes: 83fef46a22 ("net/sfc: add callback to retrieve FW version")
Fixes: bc84ac0fad ("net/txgbe: support getting FW version")
Fixes: 2191347120 ("ethdev: add firmware version get")
Cc: stable@dpdk.org
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Haiyue Wang <haiyue.wang@intel.com>
Acked-by: Rasesh Mody <rmody@marvell.com>
Acked-by: Jiawen Wu <jiawenwu@trustnetic.com>
Acked-by: Beilei Xing <beilei.xing@intel.com>
Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
In hns3 PMD, as the handler always return 0, the return value
of a function 'rte_kvargs_process' no need to be checked. But
the API definition has return value, so 'void' could be used
to ignore that.
Fixes: a124f9e959 ("net/hns3: add runtime config to select IO burst function")
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
params->leaf.cman has enum type which is not isomorphic with boolean
type, however it is used as a boolean expression.
This patch fixed it.
Fixes: c09c7847d8 ("net/hns3: support traffic management")
Cc: stable@dpdk.org
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
'HNS3_RXD_LKBK_B' was defined in previous versions but no used.
This patch deleted it.
Fixes: bba6366983 ("net/hns3: support Rx/Tx and related operations")
Cc: stable@dpdk.org
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
This patch moves the check for "link_speeds" in dev_conf to
dev_configure, so that users know whether "link_speeds" is valid in
advance.
Fixes: bdaf190f82 ("net/hns3: support link speed autoneg for PF")
Fixes: 400d307e1a ("net/hns3: support fixed link speed")
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, the fdir lock was used to protect concurrent access in
multiple processes, it has the following problems:
1) Lack of protection for fdir reset recover.
2) Only part of data is protected, eg. the filterlist is not protected.
We use the following scheme:
1) Del the fdir lock.
2) Add a flow lock and provides rte flow driver ops API-level
protection.
3) Declare support RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE.
Fixes: fcba820d9b ("net/hns3: support flow director")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
HNS3 PF driver only supports RSS, DCB or NONE multiple queues mode.
Currently, driver doesn't verify the VMDq multi-queue mode completely.
This patch fixes the verification for VMDq mode.
Fixes: 62e3ccc2b9 ("net/hns3: support flow control")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, "ONLY DCB" and "DCB+RSS" mode are both supported by HNS3
PF driver. But the driver verifies only the "DCB+RSS" multiple queues
mode.
Fixes: 62e3ccc2b9 ("net/hns3: support flow control")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Some mbx messages do not need to reply with data. In this case,
it is no need to set the response data address and the response
length.
This patch removes these redundant codes from mbx messages that do
not need be replied.
Fixes: a5475d61fa ("net/hns3: support VF")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Rx vector implementation depends on the mbuf fields
(such as rearm_data/rx_descriptor_fields1) layout, this patch adds
compile-time verification for this.
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
This patch supports check max SIMD bitwidth when choosing NEON and SVE
vector path.
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, the L3L4P/L3E/L4E/OL3E/OL4E fields in Rx descriptor used to
indicate hardware checksum result:
1. L3L4P: indicates hardware has processed L3L4 checksum for this
packet, if this bit is 1 then L3E/L4E/OL3E/OL4E is trustable.
2. L3E: L3 checksum error indication, 1 means with error.
3. L4E: L4 checksum error indication, 1 means with error.
4. OL3E: outer L3 checksum error indication, 1 means with error.
5. OL4E: outer L4 checksum error indication, 1 means with error.
Driver will set the good checksum flag through packet type and
L3E/L4E/OL3E/OL4E when L3L4P is 1, it runs as follows:
1. If packet type indicates it's tunnel packet:
1.1. If packet type indicates it has inner L3 and L3E is zero, then
mark the IP checksum good.
1.2. If packet type indicates it has inner L4 and L4E is zero, then
mark the L4 checksum good.
1.3. If packet type indicates it has outer L4 and OL4E is zero, then
mark the outer L4 checksum good.
2. If packet type indicates it's not tunnel packet:
2.1. If packet type indicates it has L3 and L3E is zero, then mark the
IP checksum good.
2.2. If packet type indicates it has L4 and L4E is zero, then mark the
L4 checksum good.
As described above, the good checksum calculation is time consuming,
it impacts the Rx performance.
By balancing performance and functionality, driver uses the following
scheme to set good checksum flag when L3L4P is 1:
1. If L3E is zero, then mark the IP checksum good.
2. If L4E is zero, then mark the L4 checksum good.
The performance gains are 3% in small packet iofwd scenarios.
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
This patch supports runtime config of mask device capability, it was
used to mask the capability which queried from firmware.
The device argument key is "dev_caps_mask" which takes hexadecimal
bitmask where each bit represents whether mask corresponding capability.
Its main purpose is to debug and avoid problems.
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Kunpeng 930 uses a new RAS exception reporting solution.
The reset type and exception status are reported through
firmware. The driver modifies the corresponding code to
adapt to the new solution.
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
'HNS3_RXD_TSIND_S' and 'HNS3_RXD_TSIND_M' is unused, which should
be deleted.
This patch fixed it.
Fixes: bba6366983 ("net/hns3: support Rx/Tx and related operations")
Cc: stable@dpdk.org
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, user could use runtime config "rx_func_hint=simple" to
select the hns3_recv_pkts API, but the API's name get from
rte_eth_rx_burst_mode_get is "Scalar" which has not reflected "simple".
So this patch renames hns3_recv_pkts to hns3_recv_pkts_simple, and
also change it's name which gets from rte_eth_rx_burst_mode_get to
"Scalar Simple" to maintain conceptual consistency.
Fixes: 521ab3e933 ("net/hns3: add simple Rx path")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
This patch adds the configuration of fixed speed for the PF device.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
If the flow control auto-negotiation is not supported and the flow
control modes on the local and link partner is asymmetric, the flow
control on the NIC does not take effect. The support of the
auto-negotiation capability requires the cooperation of the firmware
and driver.
This patch supports the flow control auto-negotiation only for copper
port. For optical ports, the forced flow control mode is still used.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
This patch supports link speed auto-negotiation for PF. If the
device supports auto-negotiation, the device negotiates with
the link partner at all speeds supported by the device.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
The speed capability of the device can be reported to the upper-layer app
in rte_eth_dev_info_get API. In this API, the speed capability is derived
from the 'supported_speed', which is the speed capability actually
supported by the NIC. The value of the 'supported_speed' is obtained
once in the probe stage and may be updated in the scheduled task to deal
with the change of the transmission interface.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, the speed of fiber port is obtained by using the default
query type of HNS3_OPC_GET_SFP_INFO opcode. In this way, only
the speed of the optical module can be obtained. In fact, the opcode
also supports an active query type, which is a channel for obtaining
information such as the speed, the supported speed, auto-negotiation
capability, and FEC mode. This patch changes the query type of the
opcode from the default query type to the active query type to obtain
the supported speed of fiber port.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
The firmware compatibility configuration in PF driver is used to
maintain the compatibility of some features of the driver and
firmware, and requires firmware to enable these features. Currently,
the configuration is in hns3_init_hardware(), which is a little back.
Because firmware may clear some configurations (such as, MAC related)
after receiving the command. And firmware can not be aware of some
default initializations (such as, flow control) before executing the
command to set the copper PHY when the PHY is controlled by firmware.
Therefore, it is recommended that no other hardware resources are
configured before the compatibility configuration. And it should be
moved to hns3_cmd_init(), which is responsible for the firmware
command initialization of driver.
In addition, the driver needs to perform corresponding processing
if the command fails to be sent.
1) If firmware fails to take over the copper PHY, the copper port fails
to initialize.
2) If fails to enable the report of link events, the device does not
support the LSC capability.
Fixes: bff6ebfe30d4 ("net/hns3: refactor PF LSC event report")
Fixes: bac6a06441 ("net/hns3: fix link status change from firmware")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, hns3 driver doesn't support to flow control auto-negotiation.
The FC mode requested by user is the same as the current FC mode. It is
not necessary to maintain the current FC mode. We only report the current
FC mode based on actual flow control mode in hns3_flow_ctrl_get().
This patch removes this redundant field. In addition, "requested_mode" in
hns3_hw struct indicates the FC mode requested by user, and the name is
unreasonable. It needs to be modified to "requested_fc_mode".
Fixes: 62e3ccc2b9 ("net/hns3: support flow control")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
The bit(5) of supported, advertising and lp_advertising for copper
PHYs obtained from the firmware indicates 1000M full-duplex. This
speed capability bit is missing in the current codes.
Fixes: 2e4859f3b3 ("net/hns3: support PF device with copper PHYs")
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
The "supported capability" obtained from firmware on copper ports
includes the speed capability, auto-negotiation capability, and flow
control capability. Therefore, this patch changes "supported_capa" to
"supported_speed" and parses the speed capability supported by the
driver from the "supported capability".
Fixes: 2e4859f3b3 ("net/hns3: support PF device with copper PHYs")
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
In the previous patch, driver will calculate packet type by ignoring
VLAN information because the packet type may calculate error when
exist VLAN and VLAN strip.
So here remove the following ptypes from support list:
1) RTE_PTYPE_L2_ETHER_VLAN
2) RTE_PTYPE_L2_ETHER_QINQ
3) RTE_PTYPE_INNER_L2_ETHER_VLAN
4) RTE_PTYPE_INNER_L2_ETHER_QINQ
Fixes: bba6366983 ("net/hns3: support Rx/Tx and related operations")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Kunpeng 930 supports RXD advanced layout. If enabled the layout, the
hardware will report packet type by 8-bit PTYPE filed in the Rx
descriptor, and the supported ptypes are different from original
scheme. So this patch adds supported list for RXD advanced layout.
Fixes: fb5e906940 ("net/hns3: support Rx descriptor advanced layout")
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
The PTP depends on special packet type reported by hardware which
enabled rxd advanced layout, so if the hardware doesn't support rxd
advanced layout, driver should ignore the PTP capability.
Fixes: 4387523581 ("net/hns3: get device capability from firmware")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
This patch supports reporting TUNNEL GRE packet type when rxd advanced
layout enabled.
Fixes: fb5e906940 ("net/hns3: support Rx descriptor advanced layout")
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
This patch adds RTE_PTYPE_L4_UDP flag when parsed tunnel vxlan packet.
Fixes: bba6366983 ("net/hns3: support Rx/Tx and related operations")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
The type of return value of hns3_cmd_send is int, some function declare
the return value as hns3_cmd_status.
This patch fix the incorrect use of the enum hns3_cmd_status.
Fixes: 737f30e1c3 ("net/hns3: support command interface with firmware")
Fixes: 02a7b55657 ("net/hns3: support Rx interrupt")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, when processing MBX messages, the system timestamp is obtained
to determine whether timeout occurs. However, the gettimeofday function
is not monotonically increasing. Therefore, this may lead to incorrect
judgment or difficulty exiting the loop. And actually, in this scenario,
it is not necessary to obtain the timestamp.
This patch deletes the call to the gettimeofday function during MBX
message processing.
Fixes: 463e748964 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
VF will build two queues (csq: command send queue, crq: command receive
queue) with firmware, the crq may contain the following messages:
1) mailbox response message which was the ack of mailbox sync request.
2) PF's link status change message which may send by PF at anytime;
Currently, any threads in the primary and secondary processes could
send mailbox sync request, so it will need to process the crq messages
in there own thread context.
If the crq hold two messages: a) PF's link status change message, b)
mailbox response message when secondary process deals with the crq
messages, it will lead to report lsc event in secondary process
because it uses the policy of processing all pending messages at once.
We use the following scheme to solve it:
1) threads in secondary process could only process specifics messages
(eg. mailbox response message) in crq, if the message processed, its
opcode will rewrite with zero, then the intr thread in primary
process will not process again.
2) threads other than intr thread in the primary process use the same
processing logic as the threads in secondary process.
3) intr thread in the primary process could process all messages.
Fixes: 76a3836b98 ("net/hns3: fix setting default MAC address in bonding of VF")
Fixes: 463e748964 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, the mailbox synchronous communication between VF and PF use
the following fields to maintain communication:
1. Req_msg_data which was combined by message code and subcode, used to
match request and response.
2. Head which means the number of requests successfully sent by VF.
3. Tail which means the number of responses successfully received by VF.
4. Lost which means the number of requests which are timeout.
There may possible mismatches of the following situation:
1. VF sends message A with code=1 subcode=1.
Then head=1, tail=0, lost=0.
2. PF was blocked about 500ms when processing the message A.
3. VF will detect message A timeout because it can't get the response
within 500ms.
Then head=1, tail=0, lost=1.
4. VF sends message B with code=1 subcode=1 which equal message A.
Then head=2, tail=0, lost=1.
5. PF processes the first message A and send the response message to VF.
6. VF will update tail field to 1, but the lost field will remain
unchanged because the code/subcode equal message B's, so driver will
return success because now the head(2) equals tail(1) plus lost(1).
This will lead to mismatch of request and response.
To fix the above bug, we use the following scheme:
1. The message sent from VF was labelled with match_id which was a
unique 16-bit non-zero value.
2. The response sent from PF will label with match_id which got from the
request.
3. The VF uses the match_id to match request and response message.
This scheme depends on the PF driver, if the PF driver don't support
then VF will uses the original scheme.
Fixes: 463e748964 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, driver will copy mailbox messages body into arq ring when
process HNS3_MBX_LINK_STAT_CHANGE and HNS3_MBX_LINK_STAT_CHANGE
message, and then call hns3_mbx_handler API which will direct process
pre-copy messages. In the whole process, the arq ring don't have a
substantial effect.
Note: The arq ring is designed for kernel environment which could not
do much job in interrupt context, but for DPDK it's not required.
Also we rename hns3_handle_link_change_event to
hns3pf_handle_link_change_event which add 'pf' suffix to make it
better to distinguish.
Fixes: 463e748964 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, after the reset is complete, the PMD restores the FEC
according to the FEC configuration reserved in the driver. If there is a
concurrency between the FEC setup operation and the restore operation
after a reset, the FEC status of the last hardware may be unknown.
This patch adds the step of obtaining the lock when setting the FEC to
avoid concurrency between restore operation and setting operation.
Fixes: 9bf2ea8dbc ("net/hns3: support FEC")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
At the end of the reset, the state of queues need to be restored
according to the states saved in the driver. If the start and stop
operations of the queues are concurrent at this time, it may cause the
final status to be uncertain.
This patch requires queues to acquire the hw lock before starting and
stopping. If the device is being restored due to reset at this time, it
will block until the reset is completed.
Fixes: fa29fe45a7 ("net/hns3: support queue start and stop")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
During the task queue pairs reset, the getimeofday is used to obtain the
timestamp to determine whether the command execution times out. But
gettimeofday is not monotonous, it can be modified by system
administrators, so the timing may not be accurate or even cause the loop
to wait consistently.
And actually, in this scenario, it is not necessary to obtain the
timestamp.
This patch removes the operation of obtaining the timestamp from the task
queue pairs reset function.
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: Min Hu (Connor) <humin29@huawei.com>
Currently, the packet type calculated by
vlan/ovlan/l3id/l4id/ol3id/ol4id fields have the following problems:
1) Identify error when exist VLAN strip which will lead to the data
buffer has non VLAN header but mbuf's ptype have L2_ETHER_VLAN flag.
2) Some packet identifies error, eg: hardware report it's RARP or
unknown packet, but ptype will marked with L2_ETHER .
So driver will calculate packet type only by l3id/l4id/ol3id/ol4id
fields.
Fixes: 0e98d5e6d9 ("net/hns3: fix packet type report in Rx")
Fixes: bba6366983 ("net/hns3: support Rx/Tx and related operations")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, if RAS interrupt and FLR occurred at the same time, FLR will
be detected and corresponding schedule state will be set during RAS
interrupt processing. However, the schedule state value will be
overridden in subsequent RAS processing, resulting in FLR processing
failure. This patch solves this problem.
Fixes: 2790c64647 ("net/hns3: support device reset")
Cc: stable@dpdk.org
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
This patch adds rollback processing when updating imissed
stats failed in PF init.
Fixes: 3e9f3042d7 ("net/hns3: add imissed packet stats")
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, there are four control variables (rx_simple_allowed,
rx_vec_allowed, tx_simple_allowed and tx_vec_allowed) which are used
to impact the selection of Rx/Tx burst function.
The purpose of the design is to provide a way to control the selection
of Rx/Tx burst function by modifying it's values, but these variables
have no entry to modify unless make intrusive modifications.
Now we already support runtime config to select Rx/Tx function, these
variables could be removed.
Fixes: a124f9e959 ("net/hns3: add runtime config to select IO burst function")
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
This patch adds debug info for Rx/Tx burst function which was choosing.
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, PF driver will report lsc when it detects the link status
change, it's not a generic implementation.
We refactor PF lsc event report by following scheme:
1. PF driver marks RTE_PCI_DRV_INTR_LSC in rte_pci_driver by default.
2. In the init stage, PF driver will detect whether firmware supports
lsc interrupt or not, driver will clear RTE_ETH_DEV_INTR_LSC flag if
firmware doesn't support lsc interrupt.
3. PF driver will report lsc event only when dev_conf.intr_conf.lsc is
set.
Note: If the firmware supports lsc interrupt, we also keep periodic
polling to deal with the interrupt loss.
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, VF driver periodically obtains link status from PF kernel
driver, and reports lsc event when detects link status change. Because
the period is 1 second, it's probably too late to report especially
in such as bonding scenario.
To solve this problem we use the following scheme:
1. PF kernel driver support immediate push link status to all VFs when
it detects the link status changes.
2. VF driver will detect PF kernel driver whether support push link
status in device init stage by sending request link info mailbox
message to PF, PF then tell VF the push capability by extend
HNS3_MBX_LINK_STAT_CHANGE mailbox message.
3. VF driver marks RTE_PCI_DRV_INTR_LSC in rte_pci_driver by default,
when it detects PF doesn't support push link status then it will clear
RTE_ETH_DEV_INTR_LSC flag.
So if PF kernel driver supports push link status to VF, then VF driver
will have RTE_ETH_DEV_INTR_LSC capability.
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Add one space before the left brace to solve the static warning.
Fixes: 63e05f19b8 ("net/hns3: support Rx descriptor status query")
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Delete redundant blank line in "hns3vf_check_event_cause" to
solve the static warning.
Fixes: a5475d61fa ("net/hns3: support VF")
Cc: stable@dpdk.org
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Support get device version which is equal to the firmware version
when dump register.
Fixes: 936eda25e8 ("net/hns3: support dump register")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, the VF mailbox synchronization communication is based on
three fields: head/tail/lost, when head equals tail plus lost, it
means the response is received successfully.
The head field indicates the number of requests that are successfully
sent. If the request sending fails, it should not be updated.
This patch fix the above bug by roll back updates when the sending
fails.
Fixes: 463e748964 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
User could create flow rules with specified counter by the action of
RTE_FLOW_ACTION_TYPE_COUNT, but the counter may retain the original
value when create.
This patch fix the bug by read the counter when creating the rule
because the counter is read-clear.
Fixes: fcba820d9b ("net/hns3: support flow director")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
In multi-TC scenarios, MAC pause is not supported. Otherwise, only
TC0 can trigger pause frames, and other TCs cannot trigger pause
frames. In this case, flow control does not meet the expectation.
Fixes: 62e3ccc2b9 ("net/hns3: support flow control")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, three hardware operations are involved in setting the PVID.
If any operation fails, a failure will be returned. And there may be
residual hardware configurations because no rollback is performed.
This patch adds rollback operation for setting PVID to avoid residual
hardware configuration after the PVID fails to be configured.
Fixes: 411d23b9ea ("net/hns3: support VLAN")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
When FLR occurs, the head pointer register of
the command queue will be cleared, resulting in
abnormal detection of the head pointer register
of the command queue. At present, FLR is detected
in this way, and the reset recovery process is
executed.
However, when FLR occurs, the header pointer
register of the command queue is not necessarily
abnormal. For example, when the driver runs
normally, the value of the header pointer register
of the command queue may also be 0, which will
lead to the miss detection of FLR.
Therefore, the judgment that whether the base
address register of command queue is 0 is added
to ensure that FLR not miss detection.
Fixes: 2790c64647 ("net/hns3: support device reset")
Cc: stable@dpdk.org
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
When start testpmd with two hns3 VFs(0000:bd:01.0, 0000:bd:01.7), and
then execute the following commands:
testpmd> create bonded device 1 0
testpmd> set bonding mac_addr 2 3c:12:34:56:78:9a
testpmd> add bonding slave 0 2
testpmd> add bonding slave 1 2
testpmd> set portmask 0x4
testpmd> port start 2
It will occurs the following error in a low probability:
0000:bd:01.0 hns3_get_mbx_resp(): VF could not get mbx(3,0)
head(16) tail(15) lost(1) from PF in_irq:0
0000:bd:01.0 hns3vf_set_default_mac_addr(): Failed to set mac
addr(3C:**:**:**:78:9A) for vf: -62
mac_address_slaves_update(1541) - Failed to update port Id 0
MAC address
The problem replay:
1. The 'port start 2' command will start slave ports and then set slave
mac address, the function call flow: bond_ethdev_start ->
mac_address_slaves_update.
2. There are also a monitor task which running in intr thread will check
slave ports link status and update slave ports mac address, the
function call flow: bond_ethdev_slave_link_status_change_monitor ->
bond_ethdev_lsc_event_callback -> mac_address_slaves_update.
3. Because the above step1&2 running on different threads, they may both
call drivers ops mac_addr_set which is hns3vf_set_default_mac_addr.
4. hns3vf_set_default_mac_addr will first acquire hw.lock and then send
mailbox to PF and wait PF's response message. Note: the PF's
response is an independent message which will received in hw.cmq.crq,
the receiving operation can only performed in intr thread.
5. So if the step1 operation hold the hw.lock and try get response
message, and step2 operation try acquire the hw.lock and so it can't
process the response message, this will lead to step1 fail.
The solution:
1. make all threads could process the mailbox response message, which
protected by the hw.cmq.crq.lock.
2. use the following rules to avoid deadlock:
2.1. ensure use the correct locking sequence: hw.lock >
hw.mbx_resp.lock > hw.cmq.crq.lock.
2.2. make sure don't acquire such as hw.lock & hw.mbx_resp.lock again
when process mailbox response message.
Fixes: 463e748964 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
PHY is a common concept for the copper and optical media type interface.
There are some inappropriate function names for copper ports, which
needs to be adjusted.
Fixes: 2e4859f3b3 ("net/hns3: support PF device with copper PHYs")
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
This patch updates copyright date for hns3 PMD files.
Fixes: 565829db8b ("net/hns3: add build and doc infrastructure")
Fixes: 952ebacce4 ("net/hns3: support SVE Rx")
Fixes: e31f123db0 ("net/hns3: support NEON Tx")
Fixes: c09c7847d8 ("net/hns3: support traffic management")
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
There are two APIs in ethdev layer to get link status of device, namely,
"rte_eth_link_get" and "rte_eth_link_get_nowait". When the device link
is unstable or auto-negotiation is in progress, the first API supports
the function of waiting for the NIC to link up, and the maximum waiting
time is 9 seconds based on DPDK Documentation. For the hns3 PMD driver,
the link can be established within 2 seconds.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
According to the suggestion of our legal department,
to standardize the copyright license of our code to
avoid potential copyright risks, we make a unified
modification to the "Hisilicon", which was nonstandard,
in the main modules we maintain.
We change it to "HiSilicon", which is consistent with
the terms used on the following official website:
https://www.hisilicon.com/en/terms-of-use.
Fixes: 565829db8b ("net/hns3: add build and doc infrastructure")
Fixes: 952ebacce4 ("net/hns3: support SVE Rx")
Fixes: e31f123db0 ("net/hns3: support NEON Tx")
Fixes: c09c7847d8 ("net/hns3: support traffic management")
Cc: stable@dpdk.org
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
This patch fixed cyclomatic complexity about MTU
in device configure process.
Fixes: 1f5ca0b460 ("net/hns3: support some device operations")
Cc: stable@dpdk.org
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, the queue reset process needs to be performed one by one,
which is inefficient. However, the queues reset in the same function is
almost at the same stage. To optimize the queue reset process, a new
function has been added to the firmware command HNS3_OPC_CFG_RST_TRIGGER
to reset all queues in the same function at a time. And the related
queue reset MBX message is adjusted in the same way too.
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: Min Hu (Connor) <humin29@huawei.com>
In the "hns3_dev_link_update" API, the link information of the port is
obtained first, and then 'dev_link' in dev->data is updated. When the
driver is resetting or fails to obtain link info, the current driver
still reports the previous link info to the user. This may cause that
the dev->data->dev_link may be inconsistent with the hw link status.
Therefore, the link status consistency between the hardware, driver,
and framework can be ensured in this interface regardless of whether
the driver is normal or abnormal.
Fixes: 109e4dd1bd ("net/hns3: get link state change through mailbox")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
For Kunpeng920 network engine, UDP packets with destination port 6081,
4789 or 4790 will be identified as tunnel packets. If the UDP CKSUM
offload is set in the mbuf, and the TX tunnel mask is not set, the
CKSUM of these packets will be wrong. In this case, the upper layer
user may not identify the packet as a tunnel packet, and processes it
as non-tunnel packet, and expect to offload the outer UDP CKSUM, so
they may not fill the outer L2/L3 length to mbuf. However, the HW
identifies these packet as tunnel packets and therefore offload the
inner UDP CKSUM. As a result, the inner and outer UDP CKSUM are
incorrect. And for non-tunnel UDP packets with preceding special
destination port will also exist similar checksum error.
For the new generation Kunpeng930 network engine, the above errata
have been fixed. Therefore, the concept of udp_cksum_mode is
introduced. There are two udp_cksum_mode for hns3 PMD,
HNS3_SPECIAL_PORT_HW_CKSUM_MODE means HW could solve the above
problem. And in HNS3_SPECIAL_PORT_SW_CKSUM_MODE, hns3 PMD will check
packets in the Tx prepare and perform the UDP CKSUM for such packets
to avoid a checksum error.
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: Min Hu (Connor) <humin29@huawei.com>
Currently, if the PKT_TX_TCP_SEG and PKT_TX_TCP_CKSUM offload flags set
in the same time, hns3 PMD can not process the descriptors correctly.
This patch fixes it by adding the processing of this situation.
Fixes: fb6eb9009f ("net/hns3: fix Tx checksum with fixed header length")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
The 'queue_full_cnt' stats have been encapsulated in 'dfx_stats'.
However, the modification in the SVE algorithm is omitted.
As a result, the driver fails to be compiled when the SVE
algorithm is used.
Fixes: 9b77f1fe30 ("net/hns3: encapsulate DFX stats in datapath")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
There may be a case in future that the speed obtained from firmware
is undefined (such as, 400G or other rate), and link status of device is
up. At this case, PMD driver will reports 100Mbps to the user in the
"hns3_dev_link_update" API, which is unreasonable. Besides, if the
speed from firmware is zero, driver should report zero instead of
100Mbps.
Fixes: 59fad0f321 ("net/hns3: support link update operation")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Since rte_flow is the only API for filtering operations,
the legacy driver interface filter_ctrl was too much complicated
for the simple task of getting the struct rte_flow_ops.
The filter type RTE_ETH_FILTER_GENERIC and
the filter operarion RTE_ETH_FILTER_GET are removed.
The new driver callback flow_ops_get replaces filter_ctrl.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Acked-by: Haiyue Wang <haiyue.wang@intel.com>
Acked-by: Rosen Xu <rosen.xu@intel.com>
Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
Reviewed-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
Add support for query Rx descriptor status in hns3 driver. Check the
descriptor specified and provide the status information of the
corresponding descriptor.
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Add support for query Tx descriptor status in hns3 driver. Check the
descriptor specified and provide the status information of the
corresponding descriptor.
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
This patch added function level imissed stats for PF and VF. In
Kunpeng920, imissed is supported, only including RPU drop stats in PF.
In kunpeng930, imissed is supported,including RPU drop stats and SSU
drop stats in PF.
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
The current RAS code stores the reported RAS statistics in xstats.
This part of statistics is of little use in practice, and because
of the change of RAS scheme on Kunpeng930, the driver can not
obtain the RAS information any more, so this patch delete these
redundant RAS statistics.
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Adjust the format of hns3 RAS related structures to resolve
the static check warnings.
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Kunpeng930 support outer UDP cksum, this patch add support for it.
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, the driver support multiple IO burst function and auto
selection of the most appropriate function based on offload
configuration.
Most applications such as l2fwd/l3fwd don't provide the means to
change offload configuration, so it will use the auto selection's io
burst function.
This patch support runtime config to select io burst function, which
add two config: rx_func_hint and tx_func_hint, both could assign
vec/sve/simple/common.
The driver will use the following rules to select io burst func:
a. if hint equal vec and meet the vec Rx/Tx usage condition then use the
neon function.
b. if hint equal sve and meet the sve Rx/Tx usage condition then use the
sve function.
c. if hint equal simple and meet the simple Rx/Tx usage condition then
use the simple function.
d. if hint equal common then use the common function.
e. if hint not set then:
e.1. if meet the vec Rx/Tx usage condition then use the neon function.
e.2. if meet the simple Rx/Tx usage condition then use the simple
function.
e.3. else use the common function.
Note: the sve Rx/Tx usage condition based on the vec Rx/Tx usage
condition and runtime environment (which must support SVE).
In the previous versions, driver will preferred use the sve function
when meet the sve Rx/Tx usage condition, but in this case driver could
get better performance if use the neon function.
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, the hns3 statistics may be inaccurate due to the
following two problems:
1. Queue-level statistics are read from the firmware, and only one Rx or
Tx can be read at a time. This results in a large time interval
between reading multiple queues statistics in a stress scenario, such
as 1280 queues used by a PF or 256 functions used at the same time.
Especially when the 256 functions are used at the same time, the
interval between every two firmware commands in a function can be
huge, because the scheduling mechanism of the firmware is similar to
RR.
2. The current statistics are read by type. The HW statistics are read
first, and then the software statistics are read. Due to preceding
reasons, HW reading may be time-consuming, which cause a
synchronization problem between SW and HW statistics of the same
queue.
In this patch, queue-level statistics are directly read from the bar
instead of the firmware, and all the statistics of a queue include HW
and SW are read at a time to reduce inconsistency.
Fixes: 8839c5e202 ("net/hns3: support device stats")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
TNL is the abbreviation of tunnel, which means port
here. MAC TNL interrupt indicates the MAC status
report of the network port, which will be generated
when the MAC status changes.
This patch enables MAC TNL interrupt reporting, and
queries and prints the corresponding MAC status when
the interrupt is received, then clear the MAC interrupt
status. Because this interrupt uses the same interrupt
as RAS, the interrupt log is adjusted.
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
The mbufs of rx queue will be allocated in "hns3_do_start" function.
But these mbufs are not released when "hns3_dev_start" executes
failed.
Fixes: c4ae39b2cf ("net/hns3: fix Rx interrupt after reset")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
All input parameters in the "hns3_dev_xstats_get_by_id" API are used,
so the rte_unused flag of some variables should be deleted.
Fixes: 3213d584b6 ("net/hns3: fix xstats with id and names")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
After MTU changed, the buffer used to store packets in HW should be
reallocated. And buffer size is allocated based on the maximum frame
size in the PF struct. However, the value of maximum frame size is
not updated in time when MTU is changed. This would lead to a packet
loss for not enough buffer.
This patch update the maximum frame size before reallocating the HW
buffer. And a rollback operation is added to avoid the side effects
of buffer reallocation failures.
Fixes: 1f5ca0b460 ("net/hns3: support some device operations")
Fixes: d51867db65 ("net/hns3: add initialization")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Currently, the driver get packet type by parse the
L3_ID/L4_ID/OL3_ID/OL4_ID from Rx descriptor and then lookup multiple
tables, it's time consuming.
Now Kunpeng930 support advanced RXD layout, which:
1. Combine OL3_ID/OL4_ID to 8bit PTYPE filed, so the driver get packet
type by lookup only one table. Note: L3_ID/L4_ID become reserved
fields.
2. The 1588 timestamp located at Rx descriptor instead of query from
firmware.
3. The L3E/L4E/OL3E/OL4E will be zero when L3L4P is zero, so driver
could optimize the good checksum calculations (when L3E/L4E is zero
then mark PKT_RX_IP_CKSUM_GOOD/PKT_RX_L4_CKSUM_GOOD).
Considering compatibility, the firmware will report capability of
RXD advanced layout, the driver will identify and enable it by default.
This patch only provides basic function: identify and enable the RXD
advanced layout, and lookup ptype table if supported.
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
The normal operation of devices with copper phys depends on the
initialization and configuration of the PHY chip. The task of
driving the PHY chip is implemented in some firmware versions.
If firmware supports the phy driver, it will report a capability
flag to driver in probing process. The driver determines whether
to support PF device with copper phys based on the capability bit.
If supported, the driver set a flag indicating that the firmware
takes over the PHY, and then the firmware initializes the PHY.
This patch supports the query of link status and link info, and
existing basic features for PF device with copper phys.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
The configuration operation for PHY is implemented by firmware. And
a capability flag will be report to driver, which means the firmware
supports the PHY driver. However, the current implementation only
supports obtaining the capability bit, but some basic functions of
copper ports in driver, such as, the query of link status and link
info, are not supported.
Therefore, it is necessary for driver to set the copper capability
bit to zero when the firmware supports the configuration of the PHY.
Fixes: 4387523581 ("net/hns3: get device capability from firmware")
Fixes: 95e5032586 ("net/hns3: support copper media type")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@huawei.com>
When rate of port changes, the rate limit of the port needs to
be updated. So it is necessary to encapsulate an interface that
configures the rate limit based on the rate.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
This patch implement Rx imissed stats by querying cmdq.
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
In current HNS3 PMD, Rx/Tx bytes from packet stats are not
implemented.
This patch implemented Rx/Tx bytes using soft counters.
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
This patch add support tx_done_cleanup ops, which could support for
the API rte_eth_tx_done_cleanup to free consumed mbufs on Tx ring.
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
This patch makes more registers dumped in the dump_reg API to help
locate the fault.
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
This patch add support for dumping module EEPROM.
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Replace copies of size(arr)/size(arr[0]) with RTE_DIM().
Eventually all of these macro definitions should be removed.
Signed-off-by: Andrew Boyer <aboyer@pensando.io>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
When jumbo frame is enabled, the MTU size needs to be modified
based on 'max_rx_pkt_len'. Driver needs to check the validity
of 'max_rx_pkt_len'. And it should be in the range of
HNS3_DEFAULT_FRAME_LEN and HNS3_MAX_FRAME_LEN. Otherwise, it may
cause that the MTU size is inconsistent with jumbo frame offload.
Fixes: 19a3ca4c99 ("net/hns3: add start/stop and configure operations")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Currently, during the VF reset, the VF will send a MBX to inform
PF to reset it and the disable command bit will be set whether
the MBX is successful. Generally, multiple reset attempts are made
after a failure. However, because the command is disabled, all
subsequent reset will all fail.
This patch disable the command only after the MBX message is
successfully.
Fixes: 2790c64647 ("net/hns3: support device reset")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
