Due the limitation of HW, when PMD create push VLAN action it needs to
know what exactly the value of VID/PCP.
PMD try to figure out them via:
- of_set_vlan_vid/pcp actions
- VLAN item in pattern
If none of above is provided, default value - zero is used.
However user will write rule like [1] which match on a range of VID and
without of_set_vlan_vid action and expect the VID will inherit from
original packet. This is not supported by HW currently. PMD will set VID
to default value - zero because it cannot figure out the exact value of
VID from VLAN item.
This is sort of misleading for some users.
In order to avoid this, PMD will spit out error for rule like [1] to
force user to provide explicit VID/PCP for new pushed VLAN headers.
[1]: testpmd> flow create 2 ingress transfer group 0 priority 3 pattern
eth / vlan vid spec 2859 vid prefix 4 / ipv4 / end
actcions of_push_vlan ethertype 0x88A8 /
of_set_vlan_pcp vlan_pcp 6 / port_id id 0 / end
Fixes: 9aee7a8418d4 ("net/mlx5: support push flow action on VLAN header")
Cc: stable@dpdk.org
Signed-off-by: Xiaoyu Min <jackmin@mellanox.com>
Reviewed-by: Dekel Peled <dekelp@mellanox.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
Currently when PMD create push VLAN action it need to provide VID to HW
and PMD get VID value from item VLAN in pattern if there is no
of_set_vlan_vid action following.
When user create rule like [1], which has of_set_vlan_vid action
before of_push_vlan, the intention is to modify VID on existing VLAN
header and push a new VLAN header with VID _inherit_ from the previous
of_set_vlan_vid.
Currently the above is not covered by PMD, PMD always fetch the VLAN
information from item for of_push_vlan action.
Fix it by only fetch VLAN information from item when there is no
previous of_set_vlan_vid action.
[1]: testpmd> flow create 2 ingress transfer group 1 priority 3 pattern
eth / vlan vid is 2731 / ipv4 / end actions
of_set_vlan_vid vlan_vid 3209 / of_push_vlan ethertype
0x88A8 / port_id id 1 / end
Fixes: b8c0372bc5ac ("net/mlx5: fix set VLAN ID/PCP in new header")
Cc: stable@dpdk.org
Signed-off-by: Xiaoyu Min <jackmin@mellanox.com>
Reviewed-by: Dekel Peled <dekelp@mellanox.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
1400 series adapters support multiple MARK and FLAG action types.
e.g.: mark id 10 / queue index 2 / mark id 11 / queue index 3
Remove the restriction in the Flow Manager implementation.
Signed-off-by: John Daley <johndale@cisco.com>
Reviewed-by: Hyong Youb Kim <hyonkim@cisco.com>
Support rte_flow RSS action on outer headers (level 0). RSS ranges on
the non-default port is OK.
Restrictions:
- The RETA is ignored. The hash function is simply applied across
the RSS queue range.
- The queues used in the RSS group must be sequential.
- There is a performance hit if the number of queues is not a power
of 2.
Signed-off-by: John Daley <johndale@cisco.com>
Reviewed-by: Hyong Youb Kim <hyonkim@cisco.com>
Each RTE RQ is represented on enic as a Start Of Packet (SOP) queue
and overflow queue (DATA). There were arranged SOP0/DATA0, SOP1/DATA1,..
But need to be arranged SOP0, SOP1,..., DATA0, DATA1... so that
rte_flow RSS queue ranges work.
Signed-off-by: John Daley <johndale@cisco.com>
Reviewed-by: Hyong Youb Kim <hyonkim@cisco.com>
Update the VIC Flow Manager API. The extensions will allow support for:
- Decap and strip VLAN
- Remove outer VLAN
- Set Egress port
- Set VLAN when replicating encapped packets
- RSS queue ranges on outer header
Signed-off-by: John Daley <johndale@cisco.com>
Reviewed-by: Hyong Youb Kim <hyonkim@cisco.com>
The current implementation produces wrong ordering for several cases
like these:
1. mark, decap, steer
Current: steer, mark, decap
Correct: mark, steer, decap
2. decap, steer, steer
Current: steer, steer, decap
Correct: steer, decap, steer
Simplify the logic and swap 1st steer and decap.
Also, allow just one decap action per flow.
Fixes: ea7768b5bba8 ("net/enic: add flow implementation based on Flow Manager API")
Cc: stable@dpdk.org
Signed-off-by: Hyong Youb Kim <hyonkim@cisco.com>
Signed-off-by: John Daley <johndale@cisco.com>
Refactor common memory btree and cache management to common driver.
Replace some input parameters of MR APIs to more common data structure
like PD, port_id, share_cache,... so that multiple PMD drivers can
use those MR APIs.
Modify mlx5 net pmd driver to use MR management APIs from common driver.
Signed-off-by: Vu Pham <vuhuong@mellanox.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
Refactor common multi-process handling codes from net PMD to common
driver. Using tuple mp_id{name, port_id} as standard input parameter
for all multi-process IPC APIs instead of using rte_eth_dev.
Modify net PMD to use multi-process APIs from common driver.
Signed-off-by: Vu Pham <vuhuong@mellanox.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
Currently, when translate jump action, the table reference will be
increased all the time. But when release the jump action, the table
resource reference will only be decreased when jump action is released.
It means for jump action which was referenced more than one time, the
increased table reference only decrease one time when jump action is
released.
Add table release when the jump action was not new created.
Fixes: 684b9a1b1f5c ("net/mlx5: support jump action")
Cc: stable@dpdk.org
Signed-off-by: Suanming Mou <suanmingm@mellanox.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
Currently, the meter suffix table is created and saved in the mlx5
shared struct. It causes the suffix table will never be released
even without any meter rules.
Move the suffix table to meter domain struct to help the suffix table
be released when all the meter rules are destroyed.
Fixes: 46a5e6bc6a85 ("net/mlx5: prepare meter flow tables")
Cc: stable@dpdk.org
Signed-off-by: Suanming Mou <suanmingm@mellanox.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
The multi-stride operations now allow to reduce a stride size
while supporting Jumbo frames. That means that it is possible
to have mbufs configured with a size smaller than the whole
packet received. It is not an issue during normal MPRQ operations
since we attach external buffers instead of copying the data
into the mbuf itself. But it is not the case in "emergency mode"
when we have to copy every packet because of no more external
mbufs are available. Assemble a multi-segment packet to overcome
this issue in case scatter mode is enabled, drop a packet if not.
Cc: stable@dpdk.org
Signed-off-by: Alexander Kozyrev <akozyrev@mellanox.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
Acked-by: Matan Azrad <matan@mellanox.com>
MPRQ feature should be updated to allow a packet to be received
into multiple strides in order to support the MTU exceeding 8KB.
Special care is needed to prevent the headroom corruption in the
multi-stride mode since the headroom space is borrowed by the PMD
from the tail of the preceding stride. Copy the whole packet into
a separate mbuf in this case or just the overlapping data if the
Rx scattering is supported by an application.
Cc: stable@dpdk.org
Signed-off-by: Alexander Kozyrev <akozyrev@mellanox.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
Acked-by: Matan Azrad <matan@mellanox.com>
Define a device parameter to configure log 2 of a stride size for MPRQ
- mprq_log_stride_size. User is able to specify a stride size in a range
allowed by an underlying hardware. The default stride size is defined as
2048 bytes to encompass most commonly used packet sizes in the Internet
(MTU 1518 and less) and will be used in case a maximum configured packet
size cannot fit into the largest possible stride size. Otherwise a
stride size is set to a large enough value to encompass a whole packet.
Cc: stable@dpdk.org
Signed-off-by: Alexander Kozyrev <akozyrev@mellanox.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
Acked-by: Matan Azrad <matan@mellanox.com>
When we use profile rule as switch rule to download, if
we download 2 different rules one by one, there will be
rejection from function ice_aq_sw_rules(), for example:
"flow create 0 priority 0 ingress pattern eth / ipv6 / ah
/ end actions queue index 3 / end"
"flow create 0 priority 0 ingress pattern eth / ipv6 / esp
/ end actions queue index 2 / end"
That is because the 2 rules has the same s_rule input set
except action queue index, so it will be rejected by
hardware. So we have to use different recipes for them.
Also, we need to add recipe_id to keep record of recipe
index, which will be used in rule remove, if not, there
will be error when search recipe in function
ice_rem_adv_rule() if we create 2 or more profile rule.
For example:
"flow create 0 priority 0 ingress pattern eth / ipv4 / udp
/ pfcp s_field is 1 / end actions queue index 4 / end"
"flow create 0 priority 0 ingress pattern eth / ipv4 / udp
/ pfcp s_field is 0 / end actions queue index 5 / end"
then,
"flow flush 0"
you will find only the first rule will be delete,
because ice_find_recp() will always return recipe
id of the first rule.
Signed-off-by: Wei Zhao <wei.zhao1@intel.com>
Acked-by: Qi Zhang <qi.z.zhang@intel.com>
Tested-by: Yuan Peng <yuan.peng@intel.com>
In order to find accurate recipe for switch filter, we
need to add mask as an element when searching for recipe.
If we create different rules with the same input set, but
using different masks, then proper recipes should use
those different mask.
Signed-off-by: Wei Zhao <wei.zhao1@intel.com>
Acked-by: Qi Zhang <qi.z.zhang@intel.com>
Tested-by: Nannan Lu <nannan.lu@intel.com>
When we add some long switch rule, we need check the
number of final recipe number, if it is large than
ICE_MAX_CHAIN_RECIPE, we should refuse this rule.
For example:
"flow create 0 ingress pattern eth / ipv6
src is CDCD:910A:2222:5498:8475:1111:3900:1536
dst is CDCD:910A:2222:5498:8475:1111:3900:2022
tc is 3 / udp dst is 45 / end actions queue index 2 / end"
This rule will consume 6 recipe, if it is not refused, it
will cause the following code over write of lkup_indx and mask.
LIST_FOR_EACH_ENTRY(entry, &rm->rg_list, ice_recp_grp_entry,
l_entry) {
last_chain_entry->fv_idx[i] = entry->chain_idx;
buf[recps].content.lkup_indx[i] = entry->chain_idx;
buf[recps].content.mask[i++] = CPU_TO_LE16(0xFFFF);
..........
}
Signed-off-by: Wei Zhao <wei.zhao1@intel.com>
Acked-by: Qi Zhang <qi.z.zhang@intel.com>
Tested-by: Nannan Lu <nannan.lu@intel.com>
Restrict pointer aliasing to optimize the code generated.
The patch showed ~3% performance uplift on Arm N1SDP platform, and no
degradation on ThunderX2. The tet case is RFC2544 zero-loss L2
forwarding running testpmd.
[1] https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/Restricted-Pointers.html
Signed-off-by: Gavin Hu <gavin.hu@arm.com>
Reviewed-by: Steve Capper <steve.capper@arm.com>
To keep ordering of mixed accesses, 'DMB OSH' is sufficient.
'DSB' inside the I40E_PCI_REG_WRITE is overkill.[1]
This patch fixes by replacing with just sufficient barriers in the
normal PMD and vPMD.
It showed 7% performance uplift on ThunderX2 and 4% on Arm N1SDP.
The test case is the RFC2544 zero-loss test running testpmd.
[1] http://inbox.dpdk.org/dev/CALBAE1M-ezVWCjqCZDBw+MMDEC4O9qf0Kpn89EMdGDajepKoZQ@mail.gmail.com
Fixes: ae0eb310f253 ("net/i40e: implement vector PMD for ARM")
Cc: stable@dpdk.org
Signed-off-by: Gavin Hu <gavin.hu@arm.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
Setup NIC to generate MSI-X interrupts.
Set the IVAR register to map interrupt causes to vectors.
Implement interrupt enable/disable functions.
Signed-off-by: Alvin Zhang <alvinx.zhang@intel.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
Disable CQ_DISABLED error interrupt in NIX_LF_ERR_INT
to fix spurious interrupts in event dev mode. Also skip
configuring RSS when RQ count is '0' because
RSS table initialization is done incorrectly due to
divide-by-zero error and it is leading to RQ_OOR error
in NIX_LF_ERR_INT.
Fixes: 83ce2880e22e ("net/octeontx2: support RSS")
Cc: stable@dpdk.org
Signed-off-by: Nithin Dabilpuram <ndabilpuram@marvell.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
In case of bnx2xvf pmd, tx packets can support vland id in 2 ways:
1. Setting the mbuf ol_flags=PKT_TX_VLAN_PKT and passing the
vlanid in mbuf->vlan_tci.
2. The tx packet itself has the vlan id included in the packet.
The first case is working as expected but the second case where
the vlan id is included in thetx packets itself was found not
working as expected. To handle that we need to properly set the
start_bd bitfield and the vlan_or_ethertype instead of setting it
to just the ethertype in case of VF.
Signed-off-by: Souvik Dey <sodey@rbbn.com>
Acked-by: Rasesh Mody <rmody@marvell.com>
Add support the set_mc_addr_list device operation in the bnx2xvf PMD.
The configured addresses are stored in the device private area, so
they can be flushed before adding new ones.
Without this v6 multicast packets were properly forwarded to the
Guest VF.
Signed-off-by: Souvik Dey <sodey@rbbn.com>
Acked-by: Rasesh Mody <rmody@marvell.com>
fgets(3)/fread(3)/fscanf(3) etc. use mmap(2)/munmap(2) which leads
to TLB shutdown interrupts to all DPDK app cores including RX cores.
This can cause packet drops. Use read(2)/write(2) instead.
Bugzilla ID: 440
Cc: stable@dpdk.org
Signed-off-by: Mohsin Shaikh <mohsinshaikh@niometrics.com>
Reviewed-by: Alexander Kozyrev <akozyrev@mellanox.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
When creating a flow, usually the creating routine is called in
serial. No parallel execution is supported right now. The same
function will be called only once for a single flow creation.
But there is a special case that the creating routine will be called
nested. If the xmeta feature is enabled and there is FLAG / MARK in
the actions list, some metadata reg copy flow needs to be created
before the original flow is applied to the hardware.
In the flow non-cached mode, resources only for flow creation will
not be saved anymore. The memory space is pre-allocated and reused
for each flow. A global index for each device is used to indicate
the memory address of the resources. If the function is called in a
nested mode, then the index will be reset and make everything get
corrupted.
To solve this, a nested index is introduced to save the position for
the original flow creation. Currently, only one level nested call
of the flow creating routine is supported.
Fixes: e7bfa3596a0a ("net/mlx5: separate the flow handle resource")
Signed-off-by: Bing Zhao <bingz@mellanox.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
The variable storages of the same name are merged together
if compiled with -fcommon. This is the default.
This default behaviour allows to declare a variable in a header file and
share the variable in every .o binaries thanks to merge at link-time.
In the case of dlopen linking of the glue library, the pointer mlx4_glue
is referencing the glue functions struct and is set after calling
dlopen.
If compiling with -fno-common (default in GCC 10), the variables must be
declared as extern to avoid multiple re-definitions.
In case the glue layer is split in glue library, the variable mlx4_glue
needs to have its own storage for the rest of the PMD.
Cc: stable@dpdk.org
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Matan Azrad <matan@mellanox.com>
Currently, when upper level application call the API function named
rte_eth_dev_set_vlan_offload to configure the hardware vlan filter
offload and call the rte_eth_promiscuous_enable API to enable
promiscuous mode based on hns3 PF device, driver can't receive the
packets with a vlan tag which has not been added by calling the API
function named rte_eth_dev_vlan_filter.
This patch fixes it by disabling the vlan filter when setting the
promiscuous mode and enabling the vlan filter again after the
promiscuous mode are disabled.
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, By default VLAN filter is enabled during initialization and
couldn't be turned off based on hns3 PF device. If upper applications
don't call rte_eth_dev_vlan_filter API function to set vlan based on
hns3 PF device, hns3 PF PMD driver will can't receive the packets with
vlan tag. It will leads to some compatibility issues, the behaviors of
using hns3 network engine and other NICs are different.
This patch disables the VLAN filter during initialization and allows the
upper level applications to enable or disable the VLAN filter.
Fixes: 411d23b9eafb ("net/hns3: support VLAN")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
When upper application calls the rte_eth_dev_rss_hash_conf_get API
function to get the RSS key parameters, the function should return the
RSS key length supported by the device. Otherwise, an error will occur
when the upper application needs to use the RSS key length supported
by this specified hardware for judgment and configure the specified
key into hardware.
For example, in the following scenario:
When users want to use their own RSS key, but the length of the key is
bigger than the one of the supported by hardware.
As a result, users need to get the RSS key length supported by hardware
according to the above API firstly, and then compare the actual obtained
RSS key length with the length of their own RSS key.
If the driver does not return the actual value, error may occur when
user calls the rte_eth_dev_rss_hash_update API function to configure
their own key into hardware.
Besides, this patch fixes the problem of stepping on memory when the RSS
key array configured by users are less than the RSS key length supported
by the driver at the same time.
Fixes: c37ca66f2b27 ("net/hns3: support RSS")
Cc: stable@dpdk.org
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Currently, when upper application calls rte_eth_dev_info_get API
function to query the Rx offload capability based on hns3 network
engine, RSS hash offload capacity is missing.
This patch fixes it by adding the related capacity in the
'.dev_infos_get' ops implementation function named hns3_dev_infos_get
and hns3vf_dev_infos_get for hns3 PF/VF PMD driver.
Fixes: c37ca66f2b27 ("net/hns3: support RSS")
Cc: stable@dpdk.org
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
This patch fixes that the flow director rules are not cleared during
initialization, which lead to remaining flow director rules after upper
application (such as testpmd) restarted.
Fixes: fcba820d9b9e ("net/hns3: support flow director")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Currently, Rx interrupt cannot work normally after reset (such as FLR,
global reset and IMP reset), when running l3fwd-power application based
on hns3 network engine.
The root cause is that the hardware configuration about Rx interrupt
does not recover after reset.
This patch fixes it with the following modification.
1. The internal static function named hns3(vf)_init_ring_with_vector is
moved from hns3_init_pf to hns3(vf)_init_hardware because
hns3(vf)_init_hardware is called both in the initialization and the
RESET_STAGE_DEV_INIT stage of the reset process.
2. The internal static function named hns3(vf)_restore_rx_interrupt is
added in hns3(vf)_restore_conf, it is used to recover hardware
configuration about interrupt vectors of rx queues in the
RESET_STAGE_DEV_INIT stage of the reset process.
3. The internal static function named hns3_dev_all_rx_queue_intr_enable
and hns3_enable_all_queues are added in hns3(vf)_dev_start(which
called in the initialization, so after calling the rte_eth_dev_start
API successfully, the driver is ready to work.
4. The function named hns3_dev_all_rx_queue_intr_enable and
hns3_enable_all_queues are also added in hns3(vf)_start_service(which
called in the RESET_STAGE_DEV_INIT stage of the reset process), so
after start_service, the driver is ready to work.
Note:
1. Because FLR will clear queue's interrupt enable bit hardware
configuration, so we add calling hns3_dev_all_rx_queue_intr_enable to
enable interrupt before enabling queues.
2. After finished the initialization, we can enable queues to work by
calling the internal function named hns3_enable_all_queues.
Fixes: 02a7b55657b2 ("net/hns3: support Rx interrupt")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Currently, when upper application calls the rte_eth_dev_mac_addr_add API
function to add a MC mac address based on hns3 PF/VF device, it will
fail.
In hns3 network engine adding UC and MC mac address with different
commands with firmware. We need to determine whether the input address
is a UC or a MC address to call different commands in the
'.mac_addr_add' and '.mac_addr_remove' ops implementation functions in
hns3 PF and VF driver as below:
hns3_add_mac_addr
hns3vf_add_uc_mac_addr
hns3_remove_mac_addr
hns3vf_remove_mac_addr
By the way, it is recommended calling the rte_eth_dev_set_mc_addr_list API
function to set the MC mac address, because using the
rte_eth_dev_mac_addr_add API function to set MC mac address may affect the
specifications of UC mac addresses.
Fixes: 7d7f9f80bbfb ("net/hns3: support MAC address related operations")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
This patch replaces the specific macro named RTE_INTR_VEC_ZERO_OFFSET
provided by DPDK framework instead of the magic number 0.
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Currently, the return value processing of some functions can be combined
and the result is that some codes can be optimized.
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Fix comment that is no more correct as the code evolved.
Fixes: 9470427c88e1 ("net/virtio: do not store PCI device pointer at shared memory")
Cc: stable@dpdk.org
Signed-off-by: Xiaolong Ye <xiaolong.ye@intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
If a vhost device is closed before eth_dev_configure is done
to the device, internal resources allocated to the device
would not be freed. This patch fixes it.
Fixes: 3d01b759d267 ("net/vhost: delay driver setup")
Cc: stable@dpdk.org
Signed-off-by: Itsuro Oda <oda@valinux.co.jp>
Reviewed-by: Xiaolong Ye <xiaolong.ye@intel.com>
With this patch, the promiscuous and multicast fields are initialized as
enabled for vhost PMD by default, this allows the devices to be used
when running applications that attempt to enable promiscuous or
multicast mode.
Similar things have done for other virtual PMDs by commit f165210321c4
("drivers/net: enable promiscuous and multicast by default")
Signed-off-by: Xiaolong Ye <xiaolong.ye@intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
