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>
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>
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>
As the hardware determines which core will process which packet,
performance is boosted by direct cache warming/stashing as well
as by providing biasing for core-to-flow affinity, which ensures
that flow-specific data structures can remain in the core’s cache.
This patch enables the one cache line data stashing for packet
annotation data and packet context
Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
This patch add support for dpni object support in MC driver.
DPNI represent a network interface object in DPAA2.
Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com>
Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
DPAA2 Hardware Mempool handlers allow enqueue/dequeue from NXP's
QBMAN hardware block.
CONFIG_RTE_MBUF_DEFAULT_MEMPOOL_OPS is set to 'dpaa2', if the pool
is enabled.
This memory pool currently supports packet mbuf type blocks only.
Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
This patch adds generic functions for allowing dq storage
for the frame queues.
As the frame queues are common resource for different drivers
this is helpful.
Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
Before DPAA2 devices can communicate using hardware queues, this patch
adds queue definitions in the FSLMC bus which the DPAA2 devices would
instantiate.
Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
The portal driver is bound to DPIO objects discovered on the fsl-mc bus and
provides services that:
- allow other drivers, such as the Ethernet driver, to enqueue and dequeue
frames for their respective objects
A system will typically allocate 1 DPIO object per CPU to allow queuing
operations to happen simultaneously across all CPUs.
Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
