In order to use the hash list defined in net in other drivers, the
hash list is moved to common utilities.
In addition, the log definition was moved from the common utilities to
a dedicated new log file in common in order to prevent a conflict.
Signed-off-by: Shiri Kuzin <shirik@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
Currently, the flow meter policy does not support multiple actions
per color; also the allowed action types per color are very limited.
In addition, the policy cannot be pre-defined.
Due to the growing in flow actions offload abilities there is a potential
for the user to use variety of actions per color differently.
This new meter policy API comes to allow this potential in the most ethdev
common way using rte_flow action definition.
A list of rte_flow actions will be provided by the user per color
in order to create a meter policy.
In addition, the API forces to pre-define the policy before
the meters creation in order to allow sharing of single policy
with multiple meters efficiently.
meter_policy_id is added into struct rte_mtr_params.
So that it can get the policy during the meters creation.
Allow coloring the packet using a new rte_flow_action_color
as could be done by the old policy API.
Add two common policy template as macros in the head file.
The next API function were added:
- rte_mtr_meter_policy_add
- rte_mtr_meter_policy_delete
- rte_mtr_meter_policy_update
- rte_mtr_meter_policy_validate
The next struct was changed:
- rte_mtr_params
- rte_mtr_capabilities
The next API was deleted:
- rte_mtr_policer_actions_update
To support this API the following app were changed:
app/test-flow-perf: clean meter policer
app/testpmd: clean meter policer
To support this API the following drivers were changed:
net/softnic: support meter policy API
1. Cleans meter rte_mtr_policer_action.
2. Supports policy API to get color action as policer action did.
The color action will be mapped into rte_table_action_policer.
net/mlx5: clean meter creation management
Cleans and breaks part of the current meter management
in order to allow better design with policy API.
Signed-off-by: Li Zhang <lizh@nvidia.com>
Signed-off-by: Haifei Luo <haifeil@nvidia.com>
Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
Acked-by: Ray Kinsella <mdr@ashroe.eu>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Jasvinder Singh <jasvinder.singh@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
The driver devices support creation of multiple flow tables.
Jump action can be used in order to move the packet steering
to different flow table.
Table 0 is always the root table for packet steering.
Jumping between tables may cause endless loops in steering mechanism,
that's why each table has level attribute,
the driver sub-system may not allow jumping to table with
equal or lower level than the current table.
Currently, in the driver, the table ID and level are always identical.
Allow multiple flow table creation with the same level attribute.
This patch adds the table id in flow table data entry, while
allocates the flow table, if the table level is same but the
different table id, the new table will be allocated with new
table object id. It supports 4M multiple flow tables on the
same level.
Signed-off-by: Li Zhang <lizh@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
Synchronize ASO meter queue accesses from
different threads using a spinlock.
Signed-off-by: Li Zhang <lizh@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
When ASO action is available, use it as the meter action
Signed-off-by: Shun Hao <shunh@nvidia.com>
Signed-off-by: Li Zhang <lizh@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
This patch adds the ASO queue management for flow meter,
includes send WQE and CQE handle functions.
Signed-off-by: Li Zhang <lizh@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
Initialize the flow meter ASO SQ WQEs with
all the constant data that should not be updated
per enqueue operation.
Signed-off-by: Li Zhang <lizh@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
ASO (Advanced Steering Operation) meter feature may require
to locate the flow context tag action after the ASO action.
When color register is shared by meter_id/flow_id, it's like:
Bits[0-7] A meter color value set by the HW.
Bits[8-31] A flow id and meter id set by SW.
Currently the tag action for meter writes all the bits
of the meter register, so it will potentially overwrite
meter color when ASO meter action is before the tag action.
Set only 24-MSB-bits of meter register in the meter tag action.
Signed-off-by: Shun Hao <shunh@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
Meter statistics are each policer action each counter.
Totally 4 counters per each meter.
It causes cache missed
and lead to data forwarding performance low.
To optimize it, support pass counter for green
and drop counter for red.
Totally two counters per each meter.
Also use the global drop statistics for
all meter drop action.
Limitations as below:
1. It does not support yellow counter and return 0.
2. All the meter colors with drop action will be
counted only by the global drop statistics.
3. Red color must be with drop action.
Signed-off-by: Li Zhang <lizh@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
Currently, packets after meter will be steered to a global policer
table,
which includes green/red color rules for every meter, so as to have
counter statistics of each color in every meter.
There's a bug that all the rules in global policer table are matching
only color criteria, so all packets will be counted to one meter only,
and other meter statistics are always zero.
This patch does these:
1. The rules in policer table matches both meter index and color, so
packet after meter could be counted to the correct meter counter.
2. The meter index and flow index are now sharing the available
register bits dynamically. Meter index starts from lsb, and flow
index starts from msb.
Fixes: 46a5e6bc6a ("net/mlx5: prepare meter flow tables")
Cc: stable@dpdk.org
Signed-off-by: Shun Hao <shunh@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
This commit adds table entry walk for the three level table.
Signed-off-by: Suanming Mou <suanmingm@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
Due to hardware limitations the VLAN push/pop and decap actions following
the sample action are supported in the FDB Tx steering domain only, the
flows with incorrect action order for other domains are rejected by
rdma-core.
To provide the action order requested in flow API this patch checks for
the VLAN or decap precedence to the sample action and moves the VLAN or
decap actions into the next flow in the new table and adds the jump
action in the prefix sample flow.
This patch also adds the validation for these combination actions.
Fixes: 255b8f86eb ("net/mlx5: fix E-Switch egress mirror flow validation")
Cc: stable@dpdk.org
Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Modify API mlx5_flow_dev_dump to support the feature.
Modify mlx5_socket since one extra arg flow_ptr is added.
The data structure sent to DPDK application from the utility triggering
the flow dumps should be packed and endianness must be specified.
The native host endianness can be used, all exchange happens within
the same host (we use sendmsg aux data and share the file handle,
remote approach is not applicable, no inter-host communication happens).
The message structure to dump one/all flow(s):
struct mlx5_flow_dump_req {
uint32_t port_id;
uint64_t flow_ptr;
} __rte_packed;
If flow_ptr is 0, all flows for the specified port will be dumped.
Signed-off-by: Haifei Luo <haifeil@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Right now, rte_flow_shared_action_* APIs are used for some shared
actions, like RSS, count. The shared action should be created before
using it inside a flow. These shared actions sometimes are not
really shared but just some indirect actions decoupled from a flow.
The new functions rte_flow_action_handle_* are added to replace
the current shared functions rte_flow_shared_action_*.
There are two types of flow actions:
1. the direct (normal) actions that could be created and stored
within a flow rule. Such action is tied to its flow rule and
cannot be reused.
2. the indirect action, in the past, named shared_action. It is
created from a direct actioni, like count or rss, and then used
in the flow rules with an object handle. The PMD will take care
of the retrieve from indirect action to the direct action
when it is referenced.
The indirect action is accessed (update / query) w/o any flow rule,
just via the action object handle. For example, when querying or
resetting a counter, it could be done out of any flow using this
counter, but only the handle of the counter action object is
required.
The indirect action object could be shared by different flows or
used by a single flow, depending on the direct action type and
the real-life requirements.
The handle of an indirect action object is opaque and defined in
each driver and possibly different per direct action type.
The old name "shared" is improper in a sense and should be replaced.
Since the APIs are changed from "rte_flow_shared_action*" to the new
"rte_flow_action_handle*", the testpmd application code and command
line interfaces also need to be updated to do the adaption.
The testpmd application user guide is also updated. All the "shared
action" related parts are replaced with "indirect action" to have a
correct explanation.
The parameter of "update" interface is also changed. A general
pointer will replace the rte_flow_action struct pointer due to the
facts:
1. Some action may not support fields updating. In the example of a
counter, the only "update" supported should be the reset. So
passing a rte_flow_action struct pointer is meaningless and
there is even no such corresponding action struct. What's more,
if more than one operations should be supported, for some other
action, such pointer parameter may not meet the need.
2. Some action may need conditional or partial update, the current
parameter will not provide the ability to indicate which part(s)
to update.
For different types of indirect action objects, the pointer could
either be the same of rte_flow_action* struct - in order not to
break the current driver implementation, or some wrapper
structures with bits as masks to indicate which part to be
updated, depending on real needs of the corresponding direct
action. For different direct actions, the structures of indirect
action objects updating will be different.
All the underlayer PMD callbacks will be moved to these new APIs.
The RTE_FLOW_ACTION_TYPE_SHARED is kept for now in order not to
break the ABI. All the implementations are changed by using
RTE_FLOW_ACTION_TYPE_INDIRECT.
Since the APIs are changed from "rte_flow_shared_action*" to the new
"rte_flow_action_handle*" and the "update" interface's 3rd input
parameter is changed to generic pointer, the mlx5 PMD that uses these
APIs needs to do the adaption to the new APIs as well.
Signed-off-by: Bing Zhao <bingz@nvidia.com>
Acked-by: Andrey Vesnovaty <andreyv@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
This patch separates Tx burst function implementations to different
source files, thus allowing them to compile in parallel.
Signed-off-by: Michael Baum <michaelba@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
This patch separates Tx function implementations to different source
file as an optional preparation step for Tx cleanup.
Signed-off-by: Michael Baum <michaelba@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
This patch moves Tx burst and its inline functions declarations to
header file to allow its use from several separate source files and as a
possible preparation for Tx cleanup.
Signed-off-by: Michael Baum <michaelba@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
This patch separates Tx function declarations to different header file
in preparation for removing their implementation from the source file
and as an optional preparation for Tx cleanup.
Signed-off-by: Michael Baum <michaelba@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
This patch separates Rx function implementations to different source
file as an optional preparation step for further consolidation of Rx
burst functions.
Signed-off-by: Michael Baum <michaelba@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
The mlx5_rxtx.c file contains a lot of Tx burst functions, each of those
is performance-optimized for the specific set of requested offloads.
These ones are generated on the basis of the template function and it
takes significant time to compile, just due to a large number of giant
functions generated in the same file and this compilation is not being
done in parallel with using multithreading.
Therefore we can split the mlx5_rxtx.c file into several separate files
to allow different functions to be compiled simultaneously.
In this patch, we separate Rx function declarations to different header
file in preparation for removing them from the source file and as an
optional preparation step for further consolidation of Rx burst
functions.
Signed-off-by: Michael Baum <michaelba@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Previous implementations support dump all the flows. Add new arg
rte_flow in rte_flow_dev_dump to dump one flow.
Signed-off-by: Haifei Luo <haifeil@nvidia.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Acked-by: Ori Kam <orika@nvidia.com>
The mlx5 PMD allocated the resources of the sample actions, and then
moved these ones to the destination actions array. The original indices
were not cleared and the resources were referenced twice in the
flow object - as the fate actions and in the destination actions array.
This causes the failure on flow destroy because PMD tried to release the
same objects twice.
The patch clears the original indices, add the missed checking for zero
and eliminates multiple object releasing.
Fixes: 00c10c2211 ("net/mlx5: update translate function for mirroring")
Cc: stable@dpdk.org
Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
Reviewed-by: Suanming Mou <suanmingm@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
When RSS expand, if there is no expansion happened but completion
happened because user only input next protocol field instead of item
i.e, ether type == 0x8100 instead of VLAN, an extra flow is created with
missing item in order to filter traffic strictly.
However, after [1] and [2] the rte_flow_item_eth itself is enough to
filter out VLAN traffic, the VLAN item is not needed.
[1]: commit 09315fc838 ("ethdev: add VLAN attributes to ethernet and VLAN items")
[2]: commit 86b59a1af6 ("net/mlx5: support VLAN matching fields")
This redundant flow will cause failure in some scenarios on group 0 due
to they are the same FTE.
Fixes: fc2dd8dd49 ("ethdev: fix expand RSS flows")
Cc: stable@dpdk.org
Signed-off-by: Xiaoyu Min <jackmin@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
Extend the range of immediate value used in the MODIFY_FIELD action
from 32 to 64 bits to conform to the rte_flow_action_modify_data spec.
Apply appropriate big endian conversion to the immediate value
according to a destination field bit width.
Fixes: 641dbe4fb0 ("net/mlx5: support modify field flow action")
Cc: stable@dpdk.org
Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Converting modify_field action masks to the big endian format is wrong
for small (less than 4 bytes) fields. Use the BE conversions appropriate
for a field size, not rte_cpu_to_be_32 for everything.
Fixes: 144127ba56 ("net/mlx5: adjust modify field action endianness")
Cc: stable@dpdk.org
Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Mellanox hardware can only modify any packet field in 32-bit chunks,
which means 4 such chunks are needed to modify an IPv6 address.
The modification order of these chunks starts from the most significant
bits for the IPv6 address. That leads to confusing results when trying
to modify either source or destination address via the MODIFY_FIELD
action. Fix the order of 32-bit chunks for IPv6 addresses modification
by starting from the least significant bits.
Fixes: 641dbe4fb0 ("net/mlx5: support modify field flow action")
Cc: stable@dpdk.org
Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
In Windows DevX returns the rate of the current link speed
in bit/s, this rate was converted to Mibit/s instead of the Mbit/s
rate expected by DPDK resulting in wrong link speed reporting.
Fixes: 6fbd73709e ("net/mlx5: support link update on Windows")
Cc: stable@dpdk.org
Signed-off-by: Tal Shnaiderman <talshn@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
The MODIFY_FIELD action requires the extended metadata support
in order to manipulate on METADATA register as well as on MARK register.
Check if it is supported and reject the MODIFY_FIELD action if it is not
just like it was done before for the MARK register modifications.
Fixes: 0588d64ffd ("net/mlx5: check extended metadata for mark modification")
Cc: stable@dpdk.org
Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Users of <rte_ip.h> relied on it to provide IP-related defines,
like IPPROTO_* constants, but still had to include POSIX headers
for inet_pton() and other standard IP-related facilities.
Extend <rte_ip.h> so that it is a single header to gain access
to IP-related facilities on any OS. Use it to replace POSIX includes
in components enabled on Windows. Move missing constants from Windows
networking shim to OS shim header and include it where needed.
Remove Windows networking shim that is no longer needed.
Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Ranjit Menon <ranjit.menon@intel.com>
Add support for NVGRE encap as a sample action
and validate it.
Signed-off-by: Salem Sol <salems@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Add support for VXLAN encap as a sample action
and validate it.
Signed-off-by: Salem Sol <salems@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
The validity verification of input parameters should be performed at
API layer, not in the PMD.
Fixes: 3a18c44b45 ("ethdev: add access to EEPROM")
Fixes: 40ff8b305a ("net/e1000: add module EEPROM callbacks for e1000")
Fixes: f2088e785c ("net/i40e: fix dereference before check when getting EEPROM")
Fixes: b74d0cd43e ("net/ixgbe: add module EEPROM callbacks for ixgbe")
Fixes: 8a6a09f853 ("net/mlx5: support reading module EEPROM data")
Fixes: 58f6f93c34 ("net/octeontx2: add module EEPROM dump")
Cc: stable@dpdk.org
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
There are multiple branches in rdma-core library backing
the rte flows:
- Verbs
- Direct Verbs (DV)
- Direct Rules (DR)
The Verbs API always requires the specifying the queue even
if there is the drop action in the flow, though the kernel
optimizes out the actual queue usage for the flows containing
the drop action. The PMD handles the dedicated Rx queue to
provide Verbs API compatibility.
The DV/DR API does not require explicit specifying the queue
at the flow creation, but PMD still specified the dedicated
drop queue as action. It performed the packet forwarding to
the dummy queue (that was not polled at all) causing the
steering pipeline resources usage and degrading the overall
packet processing rate. For example, with inserted flow to
drop all the ingress packets the statistics reported only
15Mpps of 64B packets were received over 100Gbps line.
Since the Direct Rule API for E-Switch was introduced the
rdma-core supports the dedicated drop action, that is recognized
both for DV and DR and can be used for the entire device in
unified fashion, regardless of steering domain. The similar drop
action was introduced for E-Switch, the usage of this one can be
extended for other steering domains, not for E-Switch's one only.
This patch:
- renames esw_drop_action to dr_drop_action to emphasize
the global nature of the variable (not only E-Switch domain)
- specifies this global drop action instead of dedicated
drop queue for the DR/DV flows
Fixes: 34fa7c0268 ("net/mlx5: add drop action to Direct Verbs E-Switch")
Fixes: 65b3cd0dc3 ("net/mlx5: create global drop action")
Cc: stable@dpdk.org
Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
The current define for MLX5_DRIVER_NAME refers specially for the PCI
driver.
The define itself does not mention PCI and this is confusing.
Rename from MLX5_DRIVER_NAME to MLX5_PCI_DRIVER_NAME.
Signed-off-by: Asaf Penso <asafp@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Some mlx5 PMDs define the log prefix as "mlx5_pmd" while others as
"pmd_mlx5".
The patch aligns all pmds to use the "mlx5_pmd" format.
Signed-off-by: Asaf Penso <asafp@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Shared RSS action create all supported RSS hash combination
in advance and lookup the right hash TIR when flow is actually
applied by comparing hash field value.
Unfortunately some hash combination is missed, for example,
UDP/TCP dest port only, L3-src-only, etc.
This patch add the missing hash combination.
In order to reduce the usage of pre-created TIRs and because
for one L3+L4 combination only one IBV hash type is possible,
for example, either IBV_RX_HASH_SRC_PORT_UDP or IBV_RX_HASH_DST_PORT_UDP
or both of them could be set so they can share same slot in
mlx5_rss_hash_fields, means only one TIR will be created.
Fixes: d2046c09aa ("net/mlx5: support shared action for RSS")
Cc: stable@dpdk.org
Signed-off-by: Xiaoyu Min <jackmin@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
The shared RSS action use the _tunnel_ information which is derived
from flow items to decide whether need to do inner RSS or not.
However, inner RSS should be decided by RSS level (>1) in configuration
and then to create TIR with 'IBV_RX_HASH_INNER' hash bit set.
Also, for one shared RSS action there is only one set of TIRs -
outer or inner could be so the unnecessary set of TIRs are removed
in order to reduce resource.
Fixes: d2046c09aa ("net/mlx5: support shared action for RSS")
Cc: stable@dpdk.org
Signed-off-by: Xiaoyu Min <jackmin@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
The flag ETH_LINK_SPEED_AUTONEG is 0,
so it cannot be used in a capability bitmap.
Having 0 in speed capability means all speeds are accepted.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
Modification of the 802.1Q Tag Identifier, VXLAN Network
Identifier or GENEVE Network Identifier is not supported.
Reject attempt to modify these fields via the MODIFY_FIELD
action and document this mlx5 driver limitation.
Fixes: 641dbe4fb0 ("net/mlx5: support modify field flow action")
Cc: stable@dpdk.org
Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
There is a limitation about copying one header field to another for
the Flow group 0. Such copy action is not allowed there. But setting
a header field with an immediate value is perfectly fine.
Allow the MODIFY_FIELD action on group 0 in case the source field
is an immediate value or a pointer to it.
Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
The MODIFY_FIELD action requires the extended metadata support
in order to manipulate on MARK register. Check if it is supported
and reject the MODIFY_FIELD action if it is not.
Fixes: 641dbe4fb0 ("net/mlx5: support modify field flow action")
Cc: stable@dpdk.org
Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Masks that used to modify a packet field must be in a big
endian format. Convert then to BE to ensure proper modification.
Fixes: 641dbe4fb0 ("net/mlx5: support modify field flow action")
Cc: stable@dpdk.org
Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Add a validation check to make sure that the specified width
for MODIFY_FIELD RTE action is not bigger than a field size.
Fixes: 641dbe4fb0 ("net/mlx5: support modify field flow action")
Cc: stable@dpdk.org
Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
To simplify BlueField HPF representor(vf[-1]) probe, this patch allows
probe it with "sf" syntax: "sf[-1]".
Signed-off-by: Xueming Li <xuemingl@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
In case of kernel bonding device, counter was read from first bonding PF
member.
This patch reads all member PFs and sums to get bond xstats.
Signed-off-by: Xueming Li <xuemingl@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
With kernel bonding, there was an error when setting VF MAC address
through representor. The Netlink API requires ifindex of owner PF, not
bonding device ifindex.
Uses owner PF ifindex to modify VF default MAC in case of bonding
device.
Fixes: c21e5facf7 ("net/mlx5: use bond index for netdev operations")
Cc: stable@dpdk.org
Signed-off-by: Xueming Li <xuemingl@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Since kernel bonding netdev doesn't provide statistics counter that
reflects all member ports, PMD has to manually summarize counters from
each member ports.
As a preparation, this patch collects bonding member port information
and saves to shared context data.
Signed-off-by: Xueming Li <xuemingl@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
To probe representors from different kernel bonding PFs, had to specify
2 separate devargs like this:
-a 03:00.0,representor=pf0vf[0-3] -a 03:00.0,representor=pf1vf[0-3]
This patch supports range or list of PF section in devargs, so the
alternative short devargs of above is:
-a 03:00.0,representor=pf[0-1]vf[0-3]
Signed-off-by: Xueming Li <xuemingl@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
