Add basic init and uninit function.
Map device IDs and subsystem IDs to single ID for easy operation.
Then initialize the shared code.
Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
Adding bare minimum PMD library and doc build infrastructure
and claim the maintainership for ngbe PMD.
Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
In its current state, the API can overflow the user-passed buffer if a new
representor range appears between function calls.
In order to solve this problem, augment the representor info structure with
the numbers of allocated and initialized ranges. This way the users of this
structure can be sure they will not overrun the buffer.
Fixes: 85e1588ca7 ("ethdev: add API to get representor info")
Cc: stable@dpdk.org
Signed-off-by: Viacheslav Galaktionov <viacheslav.galaktionov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Reviewed-by: Xueming Li <xuemingl@nvidia.com>
Fix build failures seen on Fedora Core 34 (GCC 11)
because of uninitialized variables.
In function ‘ulp_mapper_index_tbl_process’:
drivers/net/bnxt/tf_ulp/ulp_mapper.c:2252:43: error:
‘*(unsigned int *)((char *)&glb_res + offsetof(struct bnxt_ulp_glb_resource_info, resource_func))’
may be used uninitialized in this function
2252 | struct bnxt_ulp_glb_resource_info glb_res;
| ^~~~~~~
drivers/net/bnxt/tf_ulp/ulp_mapper.c:2252:43: error:
‘glb_res.resource_type’ may be used uninitialized in this function
In function ‘dpool_defrag’:
drivers/net/bnxt/tf_core/dpool.c:95:18: error:
‘index’ may be used uninitialized in this function
95 | uint32_t index;
| ^~~~~
Fixes: 05b405d581 ("net/bnxt: add dpool allocator for EM allocation")
Signed-off-by: Kishore Padmanabha <kishore.padmanabha@broadcom.com>
Signed-off-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
If the target machine has SVE feature (e.g. '-march=armv8.2-a+sve'),
and compiler is gcc-8.3, it will fail, the error is arm_sve.h:
no such file or directory.
The solution:
a. If RTE_HAS_SVE_ACLE defined (it means the minimum instruction set
support SVE ACLE) then compiles it.
b. Else if the compiler support SVE ACLE then compiles it.
c. Otherwise don't compile it.
Fixes: 8c25b02b08 ("net/hns3: fix enabling SVE Rx/Tx")
Fixes: 952ebacce4 ("net/hns3: support SVE Rx")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Acked-by: Ruifeng Wang <ruifeng.wang@arm.com>
Previously, the semantics of power monitor were such that we were
checking current value against the expected value, and if they matched,
then the sleep was aborted. This is somewhat inflexible, because it only
allowed us to check for a specific value in a specific way.
This commit replaces the comparison with a user callback mechanism, so
that any PMD (or other code) using `rte_power_monitor()` can define
their own comparison semantics and decision making on how to detect the
need to abort the entering of power optimized state.
Existing implementations are adjusted to follow the new semantics.
Suggested-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Tested-by: David Hunt <david.hunt@intel.com>
Acked-by: Timothy McDaniel <timothy.mcdaniel@intel.com>
NEON vector path of the PMD needs aarch64 support. But it was
enabled for aarch32 build as well because aarch32 build had
cpu_family set to aarch64. So build for aarch32 will fail due
to unsupported intrinsics.
Fix aarch32 build by updating meson file to exclude NEON vector
implementation for aarch32.
Fixes: 749799482a ("net/virtio: add to meson build")
Cc: stable@dpdk.org
Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
NEON vector path of the PMD needs aarch64 support. But it was
enabled for aarch32 build as well because aarch32 build had
cpu_family set to aarch64. So build for aarch32 will fail due
to unsupported intrinsics.
Fix aarch32 build by updating meson file to exclude NEON vector
implementation for aarch32.
Fixes: 3983583414 ("net/bnxt: support NEON")
Cc: stable@dpdk.org
Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
Reviewed-by: Lance Richardson <lance.richardson@broadcom.com>
The sfc PMD was enabled for aarch32 which is 32-bit mode but has
cpu_family set to aarch64.
As sfc support only 64-bit system, it should be disabled for aarch32.
Updated meson file to disable sfc for aarch32 build.
Fixes: 141d287067 ("net/sfc: support aarch64 architecture")
Cc: stable@dpdk.org
Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
Remove conflicting declaration of this symbol.
Fixes: d0d6549860 ("net/octeontx: support event Rx adapter")
Cc: stable@dpdk.org
Signed-off-by: David Marchand <david.marchand@redhat.com>
The original code use a heap pointer after it is freed.
This patch fix it.
Fixes: a14de8b498 ("net/ixgbe: destroy consistent filter")
Cc: stable@dpdk.org
Signed-off-by: Dapeng Yu <dapengx.yu@intel.com>
Reviewed-by: Haiyue Wang <haiyue.wang@intel.com>
For Arm platforms, reading descs can get re-ordered, then the
status of DD bits will be discontinuous, so add the logic to
only process continuous descs by checking DD bits.
Fixes: 4861cde461 ("i40e: new poll mode driver")
Cc: stable@dpdk.org
Signed-off-by: Joyce Kong <joyce.kong@arm.com>
Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
In original implementation, error returned when creating VXLAN flow
director with SCTP or TCP as layer 4 protocol of inner segment.
There are several root causes for the error:
1. ice_fdir_input_set_hdrs() set ICE_FLOW_SEG_HDR_UDP into protocol
header flag of inner segment of VXLAN FDIR rule, even if it shall be
ICE_FLOW_SEG_HDR_TCP or ICE_FLOW_SEG_HDR_SCTP
2. ice_fdir_input_set_hdrs() set ICE_FLOW_SEG_HDR_VXLAN into protocol
header flag of segments of VXLAN FDIR rule, it not necessary, and can
be set automatically by ice_flow_set_fld() later
3. flow type: ICE_FLTR_PTYPE_NONF_IPV4_UDP_VXLAN hides the flow type of
inner segment of VXLAN FDIR rule, then further causes function:
ice_fdir_get_gen_prgm_pkt() cannot write correct protocol id into inner
segment of training packet.
This patch fixes those defects described above.
Fixes: 855d23a07b ("net/ice: support VXLAN VNI field in flow director")
Cc: stable@dpdk.org
Signed-off-by: Dapeng Yu <dapengx.yu@intel.com>
Acked-by: Qi Zhang <qi.z.zhang@intel.com>
In original implementation, error returned when creating VXLAN flow
director with SCTP or TCP as layer 4 protocol of inner segment.
There are several root causes for the error:
1. ice_fdir_udp4_vxlan_pkt[] is not adapted to the TCP and SCTP protocol.
Its length cannot hold TCP header, only UDP protocol was supported in
original implementation
2. VXLAN VNI offset: 45 is inconsistent with IETF RFC 7348
This patch fixes those defects described above.
Fixes: 608cd0a5e2 ("net/ice/base: support VXLAN VNI field in flow director")
Cc: stable@dpdk.org
Signed-off-by: Dapeng Yu <dapengx.yu@intel.com>
Acked-by: Qi Zhang <qi.z.zhang@intel.com>
When VF reset happens, the QoS bandwidth configuration will be lost. If
the reset is not caused by DCB change, it is supposed to replay the
bandwidth configuration to VF by DCF. In this patch, when a vsi update
PF event is received from PF after VF reset, and it is confirmed that
DCB is not changed, bandwidth configuration will be replayed.
Signed-off-by: Ting Xu <ting.xu@intel.com>
Acked-by: Qi Zhang <qi.z.zhang@intel.com>
This patch fixed some unreasonable error check. Move all checks into one
helper function before configuring. Skip the check for DCF (VF0).
Fixes: 3a6bfc37ea ("net/ice: support QoS config VF bandwidth in DCF")
Cc: stable@dpdk.org
Signed-off-by: Ting Xu <ting.xu@intel.com>
Acked-by: Qi Zhang <qi.z.zhang@intel.com>
This patch simplify the pattern of flow rules of FDIR for IP fragment.
Flow rule can be created by the following command:
1. flow create 0 ingress pattern eth /
ipv4 fragment_offset spec 0x2000 fragment_offset mask 0x2000 /
end <actions>
2. flow create 0 ingress pattern eth / ipv6 /
ipv6_frag_ext fragment_offset spec 0x0001 fragment_offset mask 0x0001 /
end <actions>
Signed-off-by: Wenjun Wu <wenjun1.wu@intel.com>
Acked-by: Qi Zhang <qi.z.zhang@intel.com>
This patch simplify the pattern of flow rules of FDIR for IP fragment.
Flow rule can be created by the following command:
1. flow create 0 ingress pattern eth /
ipv4 fragment_offset spec 0x2000 fragment_offset mask 0x2000 /
end <actions>
2. flow create 0 ingress pattern eth / ipv6 /
ipv6_frag_ext fragment_offset spec 0x0001 fragment_offset mask 0x0001 /
end <actions>
Signed-off-by: Wenjun Wu <wenjun1.wu@intel.com>
Acked-by: Qi Zhang <qi.z.zhang@intel.com>
Caught by our QE.
When the firmware is missing, memzones were not released.
$ dpdk-testpmd -c 0x1f -a 0:0:0.0 -- -i
...
testpmd> dump_memzone
...
Zone 6: name:<RTE_METRICS>, len:0x15040, virt:0x1661b24c0, socket_id:0,
flags:0
physical segments used:
addr: 0x140000000 iova: 0x140000000 len: 0x40000000 pagesz: 0x40000000
testpmd> port attach 0000:5e:00.0
Attaching a new port...
EAL: Using IOMMU type 1 (Type 1)
EAL: Probe PCI driver: net_ice (8086:159b) device: 0000:5e:00.0 (socket 0)
ice_load_pkg(): failed to open file: /lib/firmware/intel/ice/ddp/ice.pkg
ice_dev_init(): Failed to load the DDP package,Use safe-mode-support=1 to
enter Safe Mode
EAL: Releasing PCI mapped resource for 0000:5e:00.0
EAL: Calling pci_unmap_resource for 0000:5e:00.0 at 0x2200000000
EAL: Calling pci_unmap_resource for 0000:5e:00.0 at 0x2202000000
EAL: Driver cannot attach the device (0000:5e:00.0)
EAL: Failed to attach device on primary process
testpmd: Failed to attach port 0000:5e:00.0
testpmd> dump_memzone
...
Zone 139: name:<ice_dma_17168374657430093156>, len:0x1000,
virt:0x1660ed800, socket_id:0, flags:0 physical segments used:
addr: 0x140000000 iova: 0x140000000 len: 0x40000000 pagesz: 0x40000000
With 20 tries attaching a net/ice port, we would end up with:
EAL: Probe PCI driver: net_ice (8086:159b) device: 0000:5e:00.0 (socket 0)
EAL: memzone_reserve_aligned_thread_unsafe(): Number of requested memzone
segments exceeds RTE_MAX_MEMZONE
ice_dev_init(): Failed to initialize HW
Fixes: a4c8c48fe3 ("net/ice: load OS default package")
Cc: stable@dpdk.org
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Haiyue Wang <haiyue.wang@intel.com>
The compilation flag HAVE_MLX5DV_DR_DEVX_PORT depends on presence
of mlx5dv_query_devx_port routine in rdma-core library.
The mlx5dv_query_devx_port routine exists only in OFED versions
of rdma-core library and is being planned to be removed and replaced
with Upstream compatible mlx5dv_query_port.
As mlx5dv_query_devx_port is being removed all the dependencies on
the HAVE_MLX5DV_DR_DEVX_PORT compilation flag are reconsidered.
The new compilation flag HAVE_MLX5DV_DR_CREATE_DEST_IB_PORT is for
backward compatibility with older OFED versions.
Fixes: 6cfe84fbe7 ("net/mlx5: fix port action for LAG")
Cc: stable@dpdk.org
Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
In order to get E-Switch vport identifiers the mlx5 PMD relies
on two approaches:
[a] use port query API if it is provided by rdma-core library
[b] otherwise, deduce vport ids from the related VF index
The latter is not reliable and may not work with newer kernel
drivers and in some configurations (LAG), causing E-Switch
malfunction. Hence, engaging the port query API is highly
desirable.
Depending on rdma-core version the port query API is:
- very old OFED versions have no query API (approach [b])
- rdma-core OFED < 5.5 provides mlx5dv_query_devx_port,
HAVE_MLX5DV_DR_DEVX_PORT flag is defined (approach [a])
- rdma-core OFED >= 5.5 has mlx5dv_query_port, flag
HAVE_MLX5DV_DR_DEVX_PORT_V35 is defined (approach [a])
- future OFED versions might remove mlx5dv_query_devx_port
and HAVE_MLX5DV_DR_DEVX_PORT will not be defined
- Upstream rdma-core < v35 has no port query API (approach [b])
- Upstream rdma-core >= v35 has mlx5dv_query_port, flag
HAVE_MLX5DV_DR_DEVX_PORT_V35 is defined (approach [a])
In order to support the new mlx5dv_query_port routine, the
conditional compilation flag HAVE_MLX5DV_DR_DEVX_PORT_V35
is introduced by this patch. The flag HAVE_MLX5DV_DR_DEVX_PORT
is kept for compatibility with previous rdma-core versions.
Despite this patch is not a bugfix (it follows the introduced API
variation in underlying library), it resolves the compatibility
issue and is highly desired to be ported to DPDK LTS.
Cc: stable@dpdk.org
Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
In order to allow\disallow configuring rules with identical
patterns, the new device argument 'allow_duplicate_pattern'
is introduced.
If allow, these rules be inserted successfully and only the
first rule take affect.
If disallow, the first rule will be inserted and other rules
be rejected.
The default is to allow.
Set it to 0 if disallow, for example:
-a <PCI_BDF>,allow_duplicate_pattern=0
Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
This adds the validation when creating a policy with meter action.
Currently meter action is only allowed for green color in policy, and
8 meters are supported at maximum in one meter hierarchy.
Signed-off-by: Shun Hao <shunh@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
When creating hierarchy meter, its color rules will increase next
meter's reference count, so when destroy the hierarchy meter, also
need to dereference the next meter's count.
During flushing all meters of a port, need to destroy all hierarchy
meters and their policies first, to dereference the last meter in
hierarchy. Then all meters have no reference and can be destroyed.
Signed-off-by: Shun Hao <shunh@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
When using meter hierarchy with multiple meters, every meter may have
drop counter, so a packet being set red color by one meter should be
counted to that specific meter only.
To support this, add tag action in the color rule so packet going to
next new meter can have its meter id, so as to be counted to the
correct drop counter in drop table.
Signed-off-by: Shun Hao <shunh@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
This makes the meter policy support meter action. So multiple meters
can be chained as a meter hierarchy.
Only termination meter is allowed as the last meter in a hierarchy,
and there're two cases:
1. The last meter has non-RSS policy, can directly create sub-policy
and color rules during each meter's policy creation.
2. The last meter has RSS policy, don't create sub-policy/rules when
creating meter policy. Only when a RTE flow is using the meter hierarchy,
will iterate all meters of the hierarchy and create needed sub-
policies and color rules for them.
Signed-off-by: Shun Hao <shunh@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
If user wants to do MPLS inner RSS and only provides pattern
till MPLS without inner items [1], RSS expansion will expand flows
into 13 sub-flows[2] which is too many and it impacts flow insert
rate, stack usage becomes large as well.
This expansion into 13 sub-flows seems not worthy of and it can
be significantly reduced (i.e, 7 sub-flows [3]) by user providing
at least one inner L2/L3 item [4].
[1]:
pattern eth / ipv4 / udp / mpls / end actions rss type tcp udp ip
end level 2 / end
[2]:
eth / ipv4 / udp / mpls
eth / ipv4 / udp / mpls / ipv4
eth / ipv4 / udp / mpls / ipv4 / udp
eth / ipv4 / udp / mpls / ipv4 / tcp
eth / ipv4 / udp / mpls / ipv6
eth / ipv4 / udp / mpls / ipv6 / udp
eth / ipv4 / udp / mpls / ipv6 / tcp
eth / ipv4 / udp / mpls / eth / ipv4
eth / ipv4 / udp / mpls / eth / ipv4 / udp
eth / ipv4 / udp / mpls / eth / ipv4 / tcp
eth / ipv4 / udp / mpls / eth / ipv6
eth / ipv4 / udp / mpls / eth / ipv6 / udp
eth / ipv4 / udp / mpls / eth / ipv6 / tcp
[3]:
eth / ipv4 / udp / mpls / eth
eth / ipv4 / udp / mpls / eth / ipv4 / udp
eth / ipv4 / udp / mpls / eth / ipv4 / tcp
eth / ipv4 / udp / mpls / eth / ipv6
eth / ipv4 / udp / mpls / eth / ipv6 / udp
eth / ipv4 / udp / mpls / eth / ipv6 / tcp
[4]:
pattern eth / ipv4 / udp / mpls / eth / end actions rss type tcp udp ip
level 2 / end
Signed-off-by: Xiaoyu Min <jackmin@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
MPLSoUDP and MPLSoGRE are supported by PMD from
rte flow point of view.
RSS expansion doesn't support above but, instead, supports
normal MPLS over L2, which actually will be rejected by PMD.
This patch removes RSS expansion support of the MPLS over L2
and adds support of MPLSoUDP and MPLSoGRE.
In addition to above, support for eth over MPLS expansion is
added too.
Fixes: a4a5cd21d2 ("net/mlx5: add flow MPLS item")
Cc: stable@dpdk.org
Signed-off-by: Xiaoyu Min <jackmin@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
HW doesn't support match MPLS over IP traffic.
Remove related code.
Fixes: d1abe664dd ("net/mlx5: add MPLS to Direct Verbs flow engine")
Cc: stable@dpdk.org
Signed-off-by: Xiaoyu Min <jackmin@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
Offsets are not taken into account during MAC addresses
manipulation for the MODIFY_FIELD action. That leads to
a wrong split between 0-15 and 16-47 bits and corrupted
data being copied to/from MAC addresses. Use both source
and destination offsets to calcucate the proper modify
header action specification.
Fixes: fdd0c046f4 ("net/mlx5: fix modify field action order for MAC")
Cc: stable@dpdk.org
Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
MLX5 PMD supports L3 and L4 integrity bits.
L4 checksum-ok bit was not translated correctly.
The patch updates the l4_csum_ok integrity bit translation.
Fixes: 79f8952783 ("net/mlx5: support integrity flow item")
Cc: stable@dpdk.org
Signed-off-by: Gregory Etelson <getelson@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Currently PMD needs previous layer information in order to set
corresponding match field for MPLSoGRE or MPLSoUDP.
GRE_KEY item is missing as supported previous layer when translate
item MPLS, which causes flow[1] cannot match MPLS over GRE traffic.
According to RFC4023, MPLS over GRE tunnel with optional key
field needs to be supported too.
By adding missing GRE_KEY as supported previous layer fix problem.
[1]:
flow create 0 ingress pattern eth / ipv6 / gre k_bit is 1 / gre_key /
mpls label is 966138 / end actions queue index 1 / mark id 0xa / end
Fixes: a7a0365565 ("net/mlx5: match GRE key and present bits")
Cc: stable@dpdk.org
Signed-off-by: Xiaoyu Min <jackmin@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
Flow rule pattern may be implicitly expanded by the PMD if the rule
has RSS flow action. The expansion adds network headers to the
original pattern. The new pattern lists all network levels that
participate in the rule RSS action.
The patch validates that buffer for expanded pattern has enough bytes
for new flow items.
Fixes: c7870bfe09 ("ethdev: move RSS expansion code to mlx5 driver")
Cc: stable@dpdk.org
Signed-off-by: Gregory Etelson <getelson@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Currently the flow dump provides few information about actions
- just the pointers. Add implementations to display details for
counter, modify_hdr and encap_decap actions.
For counter, the regular flow operation query is engaged and
the counter content information is provided, including hits
and bytes values.For modify_hdr, encap_and decap actions,
the information stored in the ipool objects is dumped.
There are the formats of information presented in the dump:
Counter: rec_type,id,hits,bytes
Modify_hdr: rec_type,id,actions_number,actions
Encap_decap: rec_type,id,buf
Signed-off-by: Haifei Luo <haifeil@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
For mlx5 DMA unmap, write lock should be used for rebuilding memory
region cache table rather than read lock.
Fixes: 989e999d93 ("net/mlx5: support PCI device DMA map and unmap")
Cc: stable@dpdk.org
Signed-off-by: Feifei Wang <feifei.wang2@arm.com>
Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Currently when creating meter policy, a src port_id match item will
always be added in switch domain. So if one meter is used by another
port, it will not work correctly.
This issue is solved:
1. If policy fate action is port_id, add the src port_id match item,
and the meter cannot be shared by another port.
2. If policy fate action isn't port_id, don't add the src port_id
match, meter can be shared by another port.
This fix enables one meter being shared by different ports. User can
create a meter flow using a port_id match item to make this meter
shared by other port.
Fixes: afb4aa4f12 ("net/mlx5: support meter policy operations")
Cc: stable@dpdk.org
Signed-off-by: Shun Hao <shunh@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
When preparing prefix flow using ASO meter, if it's tx flow, need
to make meter action the first one.
Currently the check of flow direction in switch domain is incorrect
that it checks the flow dev port only.
This adds the fix for the check that if there's port_id match item
in flow, use that port_id as src port to determine flow direction.
Fixes: c99b4f8bc2 ("net/mlx5: support ASO meter action")
Cc: stable@dpdk.org
Signed-off-by: Shun Hao <shunh@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
The meter policy handlers are managed by user IDs and the driver used l3
table in order to map the user ID to the internal driver handler of the
policy.
The l3 table was wrongly saved in the shared device structure which
manages all the switch domain ports what made the user IDs shared
between different ethdev ports.
Move the policy l3 table to be per port by saving it in the port private
structure.
Fixes: afb4aa4f12 ("net/mlx5: support meter policy operations")
Cc: stable@dpdk.org
Signed-off-by: Shun Hao <shunh@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
Currently a list is used to save all meter profile ids, which is
not efficient when looking up profile from huge amount of profiles.
This changes to use an l3 table instead to save meter profile ids,
so as to improve the lookup performance.
Signed-off-by: Shun Hao <shunh@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
The inline data length for TSO ethernet segment should be
calculated from the TSO header instead of the inline size
configured by txq_inline_min devarg or reported by the NIC.
It is imposed by the nature of TSO offload - inline header
is being duplicated to every output TCP packet.
Fixes: cacb44a099 ("net/mlx5: add no-inline Tx flag")
Cc: stable@dpdk.org
Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
The representor definition was introduced in the latest code.
For non-representor port, like PF port, use the 0xffff instead of -1.
This patch updates the representor id checking during splitting sample
flow.
Fixes: cb95feefdd ("net/mlx5: support sub-function representor")
Cc: stable@dpdk.org
Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
Acked-by: Xueming Li <xuemingl@nvidia.com>
All the mlx5 drivers using MRs for data-path must unregister the mapped
memory when it is freed by the dpdk process.
Currently, only the net/eth driver unregisters MRs in free event.
Move the net callback handler from net driver to common.
Cc: stable@dpdk.org
Signed-off-by: Michael Baum <michaelba@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
The introduced MODIFY_FIELD action was used to manipulate
the packet header field through copy or set operations.
These modify header actions should be counted as one action
in low level, the current code used wrong actions flags
checking for modify field action.
This patch update the action flags checking into the correct
MODIFY_HDR_ACTIONS set.
Fixes: 641dbe4fb0 ("net/mlx5: support modify field flow action")
Cc: stable@dpdk.org
Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
