The virtio port link status will always be UP, even the port is stopped:
testpmd> port stop 0
Stopping ports...
Checking link statuses...
Port 0 Link Up - speed 10000 Mbps - full-duplex
Done
The link status is queried by link_update callback when LSC is disabled.
Which in turn queries the "status" field. However, the "status" is
read-only. I couldn't think of some proper ways to change the status
without doing device reset.
Instead of doing (the heavy) reset at stop, this patch introduced a flag,
which is set to 1 and 0 on start and stop, respectively. When it's set to
0, the link status is set to DOWN unconditionally.
Fixes: a85786dc816f ("virtio: fix states handling during initialization")
Cc: stable@dpdk.org
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
A "return" is missing on error, which could lead to a "use after free"
issue (about var "conn").
Coverity issue: 143476
Fixes: 65388b43f592 ("vhost: fix fd leaks for vhost-user server mode")
Reported-by: John McNamara <john.mcnamara@intel.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
We only enabled LSC when using vhost-user as the backend, but it is
reported even when using vhost-kernel as the backend.
Fix it by only reportting LSC support when using vhost-user as the
backend.
Fixes: 35c4f8554833 ("net/virtio-user: support to report net status")
Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
The feature negotiation in virtio-user is proven to be broken,
which results in device initialization failure.
Originally, we get features from vhost backend, and remove those
that are not supported. But when new feature is added, for example,
VIRTIO_NET_F_MTU, we fail to remove this new feature. Then, this
new feature will be negotiated, as both frontend and backend claim
to support this feature.
To fix it, we add a macro to record supported features, as a filter
to remove newly added features.
Fixes: 37a7eb2ae816 ("net/virtio-user: add device emulation layer")
Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
Acked-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Move the call to stop the device inside the close routine because close
needs to stop the device if it isn't stopped.
Free the allocated queue buffers in close instead of doing so in remove.
Original code had these clean ups in remove which was causing memory
leak.
Signed-off-by: Sagar Abhang <sabhang@brocade.com>
Acked-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
According to spec, we should write virtqueue index into the notify
address, rather than 1. Besides, some HW backend may rely on the data
written to identify which queue need to serve.
Fixes: 6ba1f63b5ab0 ("virtio: support specification 1.0")
Cc: stable@dpdk.org
Signed-off-by: Xiao Wang <xiao.w.wang@intel.com>
Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
With the Enhanced multi packet send addition, the defaults were made
in order to get the maximum out of the box performance.
Features like tso, don't use the enhanced send, however the defaults
are still valid. This cause Tx queue creation to fail.
Fixes: 3f13f8c23a7c ("net/mlx5: support hardware TSO")
Fixes: 6ce84bd88919 ("net/mlx5: add enhanced multi-packet send for ConnectX-5")
Signed-off-by: Shahaf Shuler <shahafs@mellanox.com>
Signed-off-by: Raslan Darawsheh <rasland@mellanox.com>
Acked-by: Yongseok Koh <yskoh@mellanox.com>
Acked-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
Currently the argument process is done without indication which
parameter was forced by the application and which one is on it
default value.
This becomes problematic when different features requires different
defaults. For example, Enhanced multi packet send and TSO.
This commit modifies the argument process, enabling to differ
which parameter was forced by the application.
Signed-off-by: Shahaf Shuler <shahafs@mellanox.com>
Acked-by: Yongseok Koh <yskoh@mellanox.com>
Acked-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
Add case to handle 25G link speed and thereby support
LiquidIO II CN23XX 225SV (2x25G) adapter.
Signed-off-by: Shijith Thotton <shijith.thotton@caviumnetworks.com>
Add check to avoid invalid VF queue number is used in
tunnel filter.
Signed-off-by: Beilei Xing <beilei.xing@intel.com>
Acked-by: Bernard Iremonger <bernard.iremonger@intel.com>
RSS hash is computed by hardware if corresponding Rx filter (for
example, default Rx filters) has RSS flag set which is set if
the number of RSS channels is greater than zero.
Fixes: 4ec1fc3ba881 ("net/sfc: add basic stubs for RSS support on driver attach")
Cc: stable@dpdk.org
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@solarflare.com>
Enabled RSS enables RSS hash computation and provision in pseudo header.
It still makes sense for applications even if only one Rx queue is used.
Fixes: 4ec1fc3ba881 ("net/sfc: add basic stubs for RSS support on driver attach")
Fixes: 088e17210a7a ("net/sfc: query RSS key and hash types config")
Fixes: 82faef507608 ("net/sfc: set RSS key and hash types config")
Fixes: af0d9317970c ("net/sfc: query RSS redirection table")
Fixes: 32bcfb0a50b1 ("net/sfc: update RSS redirection table")
Fixes: f5258439ee5d ("net/sfc: avoid failure on port start if Rx mode is rejected")
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@solarflare.com>
Fixes: 4ec1fc3ba881 ("net/sfc: add basic stubs for RSS support on driver attach")
Cc: stable@dpdk.org
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@solarflare.com>
Coverity issue: 1419717
Fixes: a9825ccf5bb8 ("net/sfc: support flow API filters")
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@solarflare.com>
Current implementation is error-prone if the max inline size
(txq->max_inilne) is decoupled from txq->inline_en and becomes zero. If it
becomes zero, HW can crash due to WQ overflow.
Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
Acked-by: Shahaf Shuler <shahafs@mellanox.com>
Acked-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
When deleting the default MAC VLAN filter, it's
expected that it may fail.
So downgrade the error print from warning to
debug.
Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
Change level of log message from ERR to DEBUG and reword it,
in the i40e_dev_consistent_tunnel_filter_set() function.
Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
When insmod "igb_uio" with "intr_mode=legacy and test link
status interrupt. Since INTx interrupt is not supported by
X710/XL710/XXV710, it will cause Input/Output error when
reading file descriptor.
Signed-off-by: Qiming Yang <qiming.yang@intel.com>
Acked-by Jingjing Wu <jingjing.wu@intel.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
This patch corrects the description on Physical and Virtual Function
Infrastructure of Intel NICs. The RSS part description should belong
to ixgbe but not i40e.
This patch also add more notes to describe the queue number on Intel
X710/XL710 NICs.
Fixes: b9fcaeec5fc0 ("doc: add ixgbe VF RSS guide")
Cc: stable@dpdk.org
Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
In rx vector mode, QinQ is not supported.
When hw_vlan_extend is set for QinQ ensure that
rx vector mode is not selected.
Fixes: 8e109464c022 ("i40e: allow vector Rx and Tx usage")
Cc: stable@dpdk.org
Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Add information on validating and creating QinQ flow rules to
the flow rules management section of the Testpmd User Guide.
Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
With the mbuf rework, we now have 8 contiguous bytes to be
rearmed in the mbuf at 8B naturally aligned address.
Use single 8B write to avoid multiple 2B writes in Rx path.
Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Signed-off-by: Maciej Czekaj <maciej.czekaj@caviumnetworks.com>
When receiving the unsupported AQ messages, it's taken as
an error. It's not appropriate and triggers too much
unnecessary print.
Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
Fixes issue where mlx4 driver stops receiving packets when mbuf
allocation fails in mlx4_rx_burst().
This issue appears to be caused because the code doesn't recycle the
existing mbuf to the sges array when mbuf allocation fails as is done
in the code right above it which handles (wc.status != IBV_WC_SUCCESS).
Copying the code from the above case fixes the issue.
Fixes: acac55f16412 ("mlx4: use MOFED 3.0 fast verbs interface for Rx operations")
Cc: stable@dpdk.org
Signed-off-by: Charles Myers <charles.myers@spirent.com>
Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
Currently, 'rte_eth_dev_configure' fails on attempt to setup
max_rx_pkt_len > 2048 if no slaves was added to bonded device.
For example:
rte_eth_dev_attach("eth_bond0,slave=05:00.0,mode=l34", &id)
conf.rxmode.jumbo_frame = 1;
conf.rxmode.max_rx_pkt_len = 9000;
rte_eth_dev_configure(id, 1, 1, &conf)
Result:
EAL: Initializing pmd_bond for eth_bond0
EAL: Create bonded device eth_bond0 on port 4 in mode 2 on socket 0.
rte_eth_dev_configure: ethdev port_id=4 \
max_rx_pkt_len 9018 > max valid value 2048
It's expected that slaves will be added to bonded device inside
'rte_eth_dev_configure' and proper 'max_rx_pktlen' configured
for all of them.
Failure happens because of hardcoded low value of 'max_rx_pktlen'.
Increasing of this value to ETHER_MAX_JUMBO_FRAME_LEN will allow
above scenario (attach + configure).
It is important because it is the way OVS wants to work with
all DPDK devices (including virtual).
Changing the default hardcoded value makes no harm because
all the slaves' related code uses only 'candidate_max_rx_pktlen'
variable.
Fixes: 6cfc6a4f0d61 ("net/bonding: inherit maximum Rx packet length")
CC: stable@dpdk.org
Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
Reviewed-by: Eric Kinzie <ehkinzie@gmail.com>
Acked-by: Declan Doherty <declan.doherty@intel.com>
Some applications like OVS knows nothing about the
device type and wants to use same API to work with
all of them. But bond_pmd, unlike other pmds, requires
additional step (removing of all the slaves) before
closing the device.
In fact that bond_pmd automatically adds all the
devices from kvargs to bonding on configuration it
also should remove all of them on close.
This change is intended to have the same API for physical
and virtual devices. It allows us to handle virtual
devices in OVS in a common way.
Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
Acked-by: Declan Doherty <declan.doherty@intel.com>
DPDK community has several emails discussion on this topic,
these mails link is bellow:
http://dpdk.org/ml/archives/dev/2017-March/060379.html,
http://dpdk.org/ml/archives/dev/2017-March/060295.html,
items like VLAN can already have several valid "types"
(0x88a8, 0x8100, 0x9100), and who knows what will come up
in the future.
And ixgbe_flow just ignores the types when do filter configuration.
So it may be reasonable to delete the related tpid check process.
Also add some more comment log on stack explanation.
Fixes: 11777435c72 ("net/ixgbe: parse flow director filter")
Cc: stable@dpdk.org
Signed-off-by: Wei Zhao <wei.zhao1@intel.com>
Since the queue release API does not allow failures (return value is void)
and the flow API does not allow a queue to be released as long as a flow
rule depends on it, the only rational decision to avoid undefined behavior
is to panic in this situation.
Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
Flow queues array offset is not properly computed causing all sorts of
issues. Address it by making the rte_flow structure less complex.
Fixes: 360663e1df46 ("net/mlx5: prepare support for RSS action rule")
Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
VF link status rely on PF's notification, so when PF link status
be updated, it should notify VF to update link status also.
Current implementation only cover part of the situation when PF's link
status is updated, call i40e_notify_all_vfs_link_status in
i4e_dev_link_update will cover all situationa.
Fixes: bb6722fb5c0e ("net/i40e: fix VF bonded device link down")
Cc: stable@dpdk.org
Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
The patch adds 4 APIs to support configurable
PTYPE mapping for i40e device.
rte_pmd_i40e_ptype_mapping_get.
rte_pmd_i40e_ptype_mapping_replace.
rte_pmd_i40e_ptype_mapping_reset.
rte_pmd_i40e_ptype_mapping_update.
The mapping from hardware defined packet type to software defined packet
type can be updated/reset/read out with these APIs.
Also a software ptype with the most significent bit set will be regarded
as a user defined ptype (RTE_PMD_I40E_PTYPE_USER_DEFINE_MASK) so
application can use it to defined its own PTYPE naming system.
Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
Acked-by: Jianbo Liu <jianbo.liu@linaro.org>
Acked-by: Chao Zhu <chaozhu@linux.vnet.ibm.com>
The mapping from hardware defined packet type to software defined
packet type is static for i40e device, the patch let each ethdev to
to have their own copy of mapping table, this give the possibility
that different ethdev can be set different PTYPE mapping rule which
is the requirement to support following hardware's dynamic PTYPE
feature.
Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
Acked-by: Jianbo Liu <jianbo.liu@linaro.org>
Acked-by: Chao Zhu <chaozhu@linux.vnet.ibm.com>
Fix generic filter return info is not readable
when repeat to create a rule.
Fixes: 72c135a89f8 ("net/ixgbe: create consistent filter")
Cc: stable@dpdk.org
Signed-off-by: Wei Zhao <wei.zhao1@intel.com>
According to HW implementation, the bandwidth of QoS
means the L2 bandwidth, not count the bytes added by
physical layer.
Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
Refer the section which explains driver compilation and running of
testpmd in Linux, instead of describing it in driver documentation.
Signed-off-by: Shijith Thotton <shijith.thotton@caviumnetworks.com>
Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Refer the section which explains driver compilation and running of
testpmd in Linux, instead of describing it in driver documentation.
Signed-off-by: Shijith Thotton <shijith.thotton@caviumnetworks.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
Refer the section which explains driver compilation and running of
testpmd in Linux, instead of describing it in driver documentation.
Signed-off-by: Shijith Thotton <shijith.thotton@caviumnetworks.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
Refer the section which explains driver compilation and running of
testpmd in Linux, instead of describing it in driver documentation.
Signed-off-by: Shijith Thotton <shijith.thotton@caviumnetworks.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
Refer the section which explains driver compilation and running of
testpmd in Linux, instead of describing it in driver documentation.
Signed-off-by: Shijith Thotton <shijith.thotton@caviumnetworks.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
Refer the section which explains driver compilation and running of
testpmd in Linux, instead of describing it in driver documentation.
Signed-off-by: Shijith Thotton <shijith.thotton@caviumnetworks.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
Refer the section which explains driver compilation and running of
testpmd in Linux, instead of describing it in driver documentation.
Signed-off-by: Shijith Thotton <shijith.thotton@caviumnetworks.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
Refer the section which explains driver compilation and running of
testpmd in Linux, instead of describing it in driver documentation.
Signed-off-by: Shijith Thotton <shijith.thotton@caviumnetworks.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
Refer the section which explains driver compilation and running of
testpmd in Linux, instead of describing it in driver documentation.
Signed-off-by: Shijith Thotton <shijith.thotton@caviumnetworks.com>
