PMD driver should change the max_lro_pkt_size parameter into lro_wqe_num
that used for hardware, and when packets are coalesced by hardware,
PKT_RX_LRO flag should be set in the RX mbuf.
Fixes: 9d4878ef0897 ("net/hinic: support LRO offload")
Cc: stable@dpdk.org
Signed-off-by: Xiaoyun Wang <cloud.wangxiaoyun@huawei.com>
Currently, when performing the following test case:
1. Run testpmd application based on hns3 PF device.
2. Inject reset(global/IMP reset) repeatedly.
After the reset, the network port can't link up.
In the RESET_STAGE_DEV_INIT stage of the reset process, the driver will
reinitialize the hardware. If global/IMP reset occurs at this time
again, the operation of reinitialize the hardware will fail because that
firmware don't respond to the configuration commands issued by driver.
In current driver, when failed to reinitialize the hardware, rollback
operation is done, such as clearing the relevant configuration of the
command queue registers.
If firmware detects that the function's command queue register is not
configured correctly, it will not complete the reset related hardware
configuration for this function, resulting in that driver can't detect
that the hardware reset has been completed. And then the reset process
of the driver exit abnormally, the hardware can not work normally after
reset.
This patch fixes it by avoid clearing the command queue related
registers when failed to reinitialize the hardware in the
RESET_STAGE_DEV_INIT stage of the reset process.
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>
Signed-off-by: Chunsong Feng <fengchunsong@huawei.com>
The VLAN pvid ranges from 0 to 4095. The hns3 PMD driver does not
support this situation that the VLAN pvid is larger than Maximum VLAN
ID(4095).
Fixes: 411d23b9eafb ("net/hns3: support VLAN")
Cc: stable@dpdk.org
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Currently, we encounter segmentation fault when performing the following
test case:
1. Run testpmd application, config the flow filter rules then flush them
repeatedly.
2. Inject FLR concurrently every 5 second.
The calltrace info:
This GDB was configured as "aarch64-linux-gnu".
Reading symbols from ./testpmd...(no debugging symbols found)...done.
[New LWP 322]
[New LWP 325]
[New LWP 324]
[New LWP 326]
[New LWP 323]
[New LWP 327]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/
libthread_db.so.1".
Core was generated by `/home/root/app/testpmd -w 0000:00:01.0 -w
0000:00:02.0 -w 0000:00:03.0 -l 0-3 -'.
Program terminated with signal SIGSEGV, Segmentation fault.
libc.so.6
[Current thread is 1 (Thread 0xffff8bb35110 (LWP 322))]
(gdb) bt
#0 0x0000ffff8b936a90 in strlen () from /lib/aarch64-linux-gnu/
libc.so.6
#1 0x0000ffff8b905ccc in vfprintf () from /lib/aarch64-linux-gnu/
libc.so.6
#2 0x0000ffff8b993d04 in __printf_chk () from /lib/aarch64-linux-gnu/
libc.so.6
#3 0x0000000000754828 in port_flow_flush ()
#4 0x0000000000870f3c in cmdline_parse ()
The root cause as follows：
In the '.flush' ops implementation function named hns3_flow_flush, By
the way the '.flush' ops is defined in the struct rte_flow_ops, if
failed to call hns3_clear_rss_filter, the out parameter error is not
set, and then the member variable name message in the struct error is
invalid(filled with 0x44444444 in port_flow_flush function of the
testpmd application), it leads to segmentation fault when format the
message.
We fixes it by filling error parameter when failure in calling static
function named hns3_clear_rss_filter in the the '.flush' ops
implementation function named hns3_flow_flush.
Fixes: c37ca66f2b27 ("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>
Currently, the hns3 PMD driver can interact with firmware through
command to complete hardware configuration. The driver calls internal
interface function named hns3_cmd_send to issues command to the
firmware, and check the execution result of the command through desc_ret
returned by firmware to driver.
As the design of error code, when device is resetting hns3_cmd_send will
only return -EBUSY or -EIO. But we found that if desc_ret is in
[12,65535], for example the item doesn't exist when issuing the command
to query some table item, hns3_cmd_send also return -EIO. This
phenomenon will affect the processing logic for the return value.
The root cause as below:
When desc_ret is in [12,65535], in the static function named
hns3_cmd_convert_err_code called by hns3_cmd_send, matches the default
case and return -EIO. And then hns3_cmd_send return -EIO.
This patch fixes it with the following modification.
1. Change the return value of the default case in the static function
named hns3_cmd_convert_err_code from -EIO to -EREMOTEIO.
2. Modify the comment add errcode description of the internal interface
function named hns3_cmd_send.
Fixes: 737f30e1c3ab ("net/hns3: support command interface with firmware")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Currently there is a certain probability of the unexpected ol_flag of
the Rx packets's rte_mbuf when receiving packets.
The root cause as below:
1. The member variable named ol_flag of the structure named rte_mbuf is
not properly initialized to zero in the '.rx_pkt_burst' ops
implementation function named hns3_recv_pkts.
2. When multi-segment rte_mbufs are needed for long packet in Rx
operation, the driver should assign value to the ol_flag of the first
segment, not to the ol_flag of the last segment.
This patch fixes it with the following modification in the
'.rx_pkt_burst' ops implementation function named hns3_recv_pkts.
1. Where the first write operation in the '.rx_pkt_burst' ops
implementation function, assign PKT_RX_RSS_HASH to ol_flags directly
using '=' operation instead of '|=' operation.
2. In the static function named hns3_rx_set_cksum_flag, the last
rte_mbuf's ol_flags should be assigned when processing multi-segment.
We fix it by passing first_seg variable to the function instead of
rxm(the last segment's address).
Fixes: bba636698316 ("net/hns3: support Rx/Tx and related operations")
Fixes: ad7cf94823e8 ("net/hns3: fix offload flag for RSS hash")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
This patch modifies the name of some macro and local variable to avoid
devil number and increase code readability in the internal interface
function named hns3_set_port_vlan_filter.
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
This patch removes unnecessary MAC address validity check operation in
the .mac_addr_set ops implementation function named
hns3_set_default_mac_addr and hns3vf_set_default_mac_addr, because it
has been guaranteed that input parameter named mac_addr is valid address
in the rte layer of DPDK framework.
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
The new macro __rte_cold, for compiler hinting,
is now used where appropriate for consistency.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Reviewed-by: David Christensen <drc@linux.vnet.ibm.com>
There is a common macro __rte_unused, avoiding warnings,
which is now used where appropriate for consistency.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
There is a macro __rte_noinline, preventing function to be inlined,
which is now used where appropriate for consistency.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
There is a macro __rte_always_inline, forcing functions to be inlined,
which is now used where appropriate for consistency.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
There is a common macro __rte_packed for packing structs,
which is now used where appropriate for consistency.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
There is a common macro __rte_aligned for alignment,
which is now used where appropriate for consistency.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Reviewed-by: David Christensen <drc@linux.vnet.ibm.com>
The macros RTE_MARKER and __rte_cache_aligned can be used
for consistency for describing MEMIF_CACHELINE_ALIGN_MARK.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
There is a macro RTE_FINI for destructors,
which is now used where appropriate for consistency.
The destructor function mlx5_pmd_socket_uninit does not need
to be declared separately in mlx5.h.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Remove setting ALLOW_EXPERIMENTAL_API individually for each Makefile and
meson.build. Instead, enable ALLOW_EXPERIMENTAL_API flag across app, lib
and drivers.
This changes reduces the clutter across the project while still
maintaining the functionality of ALLOW_EXPERIMENTAL_API i.e. warning
external applications about experimental API usage.
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
Signed-off-by: David Marchand <david.marchand@redhat.com>
The EAL API (with doxygen documentation) is moved from
common/include/ to include/, which makes more clear that
it is the global API for all environments and architectures.
Note that the arch-specific and OS-specific include files are not
in this global include directory, but include/generic/ should
cover the doxygen documentation for them.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: David Marchand <david.marchand@redhat.com>
The directories ppc_64 are renamed as ppc in
- config/
- lib/librte_eal/common/arch/
- lib/librte_eal/common/include/arch/
The EAL directories are not really renamed, but symbolically linked,
because they will be moved with their new name in the next commits.
If ppc_32 needs to be supported, it can be in the same directory.
The arch directories arm and x86 are already covering both 32 and 64-bit
sub-architectures.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Reviewed-by: David Christensen <drc@linux.vnet.ibm.com>
Acked-by: David Marchand <david.marchand@redhat.com>
This is a helper function in case components would like to do more work
than just logging a message based on log level, like for example
collecting some stats if the log type is DEBUG etc..
A few existing relevant usage converted to this new API.
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Hyong Youb Kim <hyonkim@cisco.com>
Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
Reviewed-by: Andrzej Ostruszka <aostruszka@marvell.com>
Acked-by: David Marchand <david.marchand@redhat.com>
There is a non-optimal check if doorbell is needed present in the
mlx5_tx_handle_completion() function. Advancing a copy of the txq
consumer index and checking this copy with initial value causes
unnecessary memory loads and hurts the performance. It is better to
have a simple small boolean variable for this purpose. That allows
to eliminate all the excessive memory operations with the txq consumer
index and restore the performance of the tx completions.
Fixes: 1fd9af05e44e ("net/mlx5: update Tx error handling routine")
Cc: stable@dpdk.org
Signed-off-by: Alexander Kozyrev <akozyrev@mellanox.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
Previous fix added, at the end of functions
flow_dv_translate_item_ipv4() and flow_dv_translate_item_ipv6(), the
setting of cvlan_tag mask.
In the case of unspecified item (item->spec == null) these functions
return, and the new code section is not reached.
This patch moves the setting of cvlan_tag mask to be done before the
check of item->spec, to make sure it is always executed.
Fixes: 797329d6c4a1 ("net/mlx5: fix match on ethertype and CVLAN tag")
Cc: stable@dpdk.org
Signed-off-by: Dekel Peled <dekelp@mellanox.com>
Acked-by: Matan Azrad <matan@mellanox.com>
This patch makes IO memory allocation with socketid,
the txq or rxq descriptor and IO resource can be allocated with
socketid that passed by queue setup ops, which can improve
performance for cross-numa scene.
Cc: stable@dpdk.org
Signed-off-by: Xiaoyun Wang <cloud.wangxiaoyun@huawei.com>
Adding API for axgbe_rxq_info_get, axgbe_txq_info_get
Signed-off-by: Amaranath Somalapuram <asomalap@amd.com>
Acked-by: Ravi Kumar <ravi1.kumar@amd.com>
Adding API for priority_flow_ctrl_set.
Priority flow control to set water high and low,
pause_time and priority.
Signed-off-by: Amaranath Somalapuram <asomalap@amd.com>
Acked-by: Ravi Kumar <ravi1.kumar@amd.com>
Adding api for flow_ctrl_get and flow_ctrl_set.
By default axgbe driver flow control is disabled.
Adding dpdk flow control to set water high and low.
Signed-off-by: Amaranath Somalapuram <asomalap@amd.com>
Acked-by: Ravi Kumar <ravi1.kumar@amd.com>
There is no reason to prevent the user from using zero metadata,
it indeed means no metadata, but sometimes the user may need to
report to datapath that there is no metadata anymore, which is
valid case.
Fixes: fcc8d2f716fd ("net/mlx5: extend flow metadata support")
Cc: stable@dpdk.org
Signed-off-by: Wisam Jaddo <wisamm@mellanox.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
The reason why PF cannot receive data normally is that vf performed
the clear_rar operation through dev close without adding a mac address.
This will cause the association between the index and rx address set
by VMDq to be cancelled,thus affecting the data reception of PF. The
correction method is to add a check action, and do not perform the
set_rar operation without adding a mac address to prevent affecting the
reception of data.
Fixes: 3c4270187518 ("net/ixgbe: support VF MAC address add/remove")
Cc: stable@dpdk.org
Signed-off-by: Guinan Sun <guinanx.sun@intel.com>
Acked-by: Xiaolong Ye <xiaolong.ye@intel.com>
Apart from the 4-tuple (IP src/dst addresses and TCP/UDP src/dst
port addresses), there are only 40-bits available to match other
fields in packet headers. Not all combinations of packet header
fields can fit in the 40-bit tuple.
Currently, the combination of packet header fields to match are
configured via filterMode for LETCAM filters and filterMask for
HASH filters in firmware config files (t5/t6-config.txt). So, add
devargs to allow User to dynamically select the filterMode and
filterMask combination during runtime, without having to modify the
firmware config files and reflashing them onto the adapter. A table
of supported combinations is maintained by the driver to internally
translate the User specified devargs combination to hardware's internal
format before writing the requested combination to hardware
Signed-off-by: Karra Satwik <kaara.satwik@chelsio.com>
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Add new firmware API FW_PARAM_DEV_FILTER_MODE_MASK to fetch
the filtermode and filtermask values configured in hardware,
which are used to validate the match combinations in the filter
spec before offloading the filter rules to hardware. For older
firmware that doesn't support the new API, fallback to older way
of directly reading from indirect registers
Signed-off-by: Karra Satwik <kaara.satwik@chelsio.com>
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Add support to rewrite Source MAC addresses. The new Source
MAC address is written into a free entry in the SMT table
and the corresponding SMT index is used by hardware to
rewrite the Source MAC address of the packets hitting the
flow.
Signed-off-by: Karra Satwik <kaara.satwik@chelsio.com>
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Source MAC Table (SMT) is used for storing Source MAC
addresses to be written in packets transmitted on the
wire. Hence, the SMT table can be used for overwriting
Source MAC addresses in packets, hitting corresponding
filter rules inserted by the rte_flow API.
Query firmware for SMT start and size information available
to the underlying PF. Allocate and maintain the corresponding
driver's copy of the hardware SMT table, with appropriate
refcount mechanism. If SMT information is not available, then
use the entire hardware SMT table.
Signed-off-by: Karra Satwik <kaara.satwik@chelsio.com>
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Add support for overwriting destination MAC addresses.
The new MAC address is written into a free entry in the
L2T table and the corresponding L2T index is used by
hardware to overwrite the destination MAC address of the
packets hitting the flow
Signed-off-by: Karra Satwik <kaara.satwik@chelsio.com>
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Add support to match all packets received on the underlying VF.
Use new firmware API to fetch the Virtual Interface Number (VIN)
allocated to each VF by the firmware. The VIN is required to
write filter rules to match all packets on VFs, whose identifier
is beyond max 7-bit value (i.e. 127) in VIID.
If firmware doesn't support fetching the VIN information, then
fallback to manually retrieving the VIN value from the 7-bit field
in the VIID, which only supports in range of 0..127. In this case,
packets belonging to VFs, whose identifier is beyond 127 can't be
matched.
Signed-off-by: Karra Satwik <kaara.satwik@chelsio.com>
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Add support to match all packets received on the underlying PF
Note that the same 17-bit hardware tuple is shared between QinQ
and PF match. Hence, match on either QinQ or PF only can be done
at a time. Both QinQ and PF match can't be enabled at the same time.
Also, remove check to reject rules without spec because
RTE_FLOW_ITEM_TYPE_PF doesn't require a spec. Due to this check
removal, RTE_FLOW_ITEM_TYPE_PHY_PORT item needs to be updated to
handle NULL spec
Signed-off-by: Karra Satwik <kaara.satwik@chelsio.com>
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Add support to match Type of Service (TOS) field in
IPv4/IPv6 header
Signed-off-by: Karra Satwik <kaara.satwik@chelsio.com>
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Add support to match fields in 802.1ad Q-in-Q VLAN packets.
Relax check for repeated pattern items for RTE_FLOW_ITEM_TYPE_VLAN
item, since the same item is used to represent both QinQ and VLAN
packets.
When QinQ match is enabled, the ethertype field in the hardware
spec must contain the innermost VLAN header's ethertype field,
and not the Ethernet header's ethertype field. The hardware
automatically searches for ethertype 0x88A8/0x8100 in Ethernet
header, when parsing incoming packet against QinQ/VLAN pattern,
respectively.
Signed-off-by: Karra Satwik <kaara.satwik@chelsio.com>
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Make user filters a priority in EF10 datapath. When a manual
filter with a specification that is equal to an existing auto
filter is inserted, the manual filter:
- replaces auto filter if the specification is exclusive;
- is inserted along existing auto filter otherwise;
In the first case the auto filter that was replaced is saved.
This saved filter can be updated on filter reconfiguration and
is restored on the manual filter removal.
Fixes: e7cd430c864f ("net/sfc/base: import SFN7xxx family support")
Cc: stable@dpdk.org
Signed-off-by: Igor Romanov <igor.romanov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
The code is refactored to make it more clear and allow for
more convenient further changes.
Fixes: e7cd430c864f ("net/sfc/base: import SFN7xxx family support")
Cc: stable@dpdk.org
Signed-off-by: Igor Romanov <igor.romanov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
The automatic filter priority may only be used by filter implementation,
so reject the attempts to create such filters by client drivers.
Fixes: f9565517ff4f ("net/sfc/base: import filters support")
Cc: stable@dpdk.org
Signed-off-by: Igor Romanov <igor.romanov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Only implemented filter priorities are manual and auto. Remove
unused priorities since exposing unimplemented functionality
is of no benefit.
Tx filter specification default priority is changed to manual,
since required priority does not differ from it in the implementation.
Fixes: f9565517ff4f ("net/sfc/base: import filters support")
Cc: stable@dpdk.org
Signed-off-by: Igor Romanov <igor.romanov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
The priority should be explicitly set to manual for correct
usage of libefx filters.
Fixes: a9825ccf5bb8 ("net/sfc: support flow API filters")
Cc: stable@dpdk.org
Signed-off-by: Igor Romanov <igor.romanov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Returned errors of ethdev callbacks are negative. Internal
sfc functions return positive errors, so convert them to
negative value.
Fixes: 9039c8125730 ("ethdev: change promiscuous callbacks to return status")
Cc: stable@dpdk.org
Signed-off-by: Igor Romanov <igor.romanov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Any DPDK public header file which includes stdbool.h may conflict with
local definition of bool, if any, which further results in compilation
error. To avoid, used standard stdbool.h instead of defining bool
internally.
I observed this issue during a development where I included rte_uuid.h
into rte_ethdev.h. As rte_ethdev.h is included to PMD driver, it started
throwing error as given below:
CC ionic_rxtx.o
In file included from .../dpdk/build/include/rte_uuid.h:17:0,
from .../dpdk/build/include/rte_ethdev.h:161,
from .../dpdk/build/include/rte_ethdev_driver.h:18,
from .../dpdk/drivers/net/ionic/ionic_rxtx.c:34:
.../dpdk/drivers/net/ionic/ionic_osdep.h:48:17:
error: two or more data types in declaration specifiers
typedef uint8_t bool;
^
In file included from .../dpdk/drivers/net/ionic/ionic_dev.h:8:0,
from .../dpdk/drivers/net/ionic/ionic.h:13,
from .../dpdk/drivers/net/ionic/ionic_mac_api.h:8,
from .../dpdk/drivers/net/ionic/ionic_rxtx.c:45:
.../dpdk/drivers/net/ionic/ionic_osdep.h:48:1:
warning: useless type name in empty declaration
typedef uint8_t bool;
^~~~~~~
cc1: warning: unrecognized command line option
‘-Wno-address-of-packed-member’
.../dpdk/mk/internal/rte.compile-pre.mk:114:
recipe for target 'ionic_rxtx.o' failed
Fixes: 5ef518098ec6 ("net/ionic: register and initialize adapter")
Cc: stable@dpdk.org
Signed-off-by: Sunil Kumar Kori <skori@marvell.com>
Acked-by: Alfredo Cardigliano <cardigliano@ntop.org>
Currently, when promiscuous mode is enabled, it is just allowed to
accept all the unicast and broadcast packets in hns3 PF PMD driver. It
should also be able to receive multicast packets.
Fixes: 19a3ca4c99cf ("net/hns3: add start/stop and configure operations")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Currently, we only support VF device is bound to vfio_pci or igb_uio and
then driven by DPDK driver when PF is driven by kernel mode hns3 ethdev
driver, VF is not supported when PF is driven by hns3 DPDK driver.
This patch adds promiscuous and allmulticast mode support for hns3 VF
PMD driver.
1) The promiscuous/allmulticast mode can be configured successfully only
based on the trusted VF device. If based on the non trusted VF
device, configuring promiscuous/allmulticast mode will fail. The hns3
VF device can be configured as trusted device by hns3 PF kernel
ethdev driver on the host by "ip link set <eth num> vf <vf id> turst
on" command.
2) After the promiscuous mode is configured successfully, hns3 VF PMD
driver can receive the ingress and outgoing traffic. In the words,
all the ingress packets, all the packets sent from the PF and other
VFs on the same physical port.
3) Note: Because of the hardware constraints, By default vlan filter is
enabled and couldn't be turned off based on VF device, so vlan filter
is still effective even in promiscuous mode. If upper applications
don't call rte_eth_dev_vlan_filter API function to set vlan based on
VF device, hns3 VF PMD driver will can't receive the packets with
vlan tag in promiscuous mode.
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
The hns3 PF/VF devices on the same port share the hardware MTU
configuration. Currently, we send mailbox to inform hns3 PF kernel
ethdev driver to finish hardware MTU configuration in hns3 VF PMD
driver, there is no need to stop the port for hns3 VF device, and
the MTU value issued by hns3 VF PMD driver must be less than or
equal to PF's MTU.
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
