ethdev: add indirect flow list action

Indirect API creates a shared flow action with unique action handle.
Flow rules can access the shared flow action and resources related to
that action through t

ethdev: add indirect flow list action

Indirect API creates a shared flow action with unique action handle.
Flow rules can access the shared flow action and resources related to
that action through the indirect action handle.
In addition, the API allows to update existing shared flow action
configuration. After the update completes, new action configuration
is available to all flows that reference that shared action.

Indirect actions list expands the indirect action API:
• Indirect action list creates a handle for one or several
flow actions, while legacy indirect action handle references
single action only.
Input flow actions arranged in END terminated list.
• Flow rule can provide rule specific configuration parameters to
existing shared handle.
Updates of flow rule specific configuration will not change the base
action configuration.
Base action configuration was set during the action creation.

Indirect action list handle defines 2 types of resources:
• Mutable handle resource can be changed during handle lifespan.
• Immutable handle resource value is set during handle creation
and cannot be changed.

There are 2 types of mutable indirect handle contexts:
• Action mutable context is always shared between all flows
that referenced indirect actions list handle.
Action mutable context can be changed by explicit invocation
of indirect handle update function.
• Flow mutable context is private to a flow.
Flow mutable context can be updated by indirect list handle
flow rule configuration.

flow 1:
/ indirect handle H conf C1 /
| |
| |
| | flow 2:
| | / indirect handle H conf C2 /
| | | |
| | | |
| | | |
=========================================================
^ | | | |
| | V | V
| ~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~
| flow mutable flow mutable
| context 1 context 2
| ~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~
indirect | | |
action | | |
context | V V
| -----------------------------------------------------
| action mutable context
| -----------------------------------------------------
v action immutable context
=========================================================

Indirect action types - immutable, action / flow mutable, are mutually
exclusive and depend on the action definition.
For example:
• Indirect METER_MARK policy is immutable action member and profile is
action mutable action member.
• Indirect METER_MARK flow action defines init_color as flow mutable
member.
• Indirect QUOTA flow action does not define flow mutable members.

If indirect list handle was created from a list of actions
A1 / A2 ... An / END
indirect list flow action can update Ai flow mutable context in the
action configuration parameter.
Indirect list action configuration is and array [C1, C2, .., Cn]
where Ci corresponds to Ai in the action handle source.
Ci configuration element points Ai flow mutable update, or it's NULL
if Ai has no flow mutable update.
Indirect list action configuration can be NULL if the action
has no flow mutable updates.

Template API:

Action template format:

template .. indirect_list handle Htmpl conf Ctmpl ..
mask .. indirect_list handle Hmask conf Cmask ..

1 If Htmpl was masked (Hmask != 0), it will be fixed in that template.
Otherwise, indirect action value is set in a flow rule.

2 If Htmpl and Ctmpl[i] were masked (Hmask !=0 and Cmask[i] != 0),
Htmpl's Ai action flow mutable context fill be updated to
Ctmpl[i] values and will be fixed in that template.

Flow rule format:

actions .. indirect_list handle Hflow conf Cflow ..

3 If Htmpl was not masked in actions template, Hflow references an
action of the same type as Htmpl.

4 Cflow[i] updates handle's Ai flow mutable configuration if
the Ci was not masked in action template.

Signed-off-by: Gregory Etelson <getelson@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>

show more ...

ethdev: add flow item for RoCE infiniband BTH

IB(InfiniBand) is one type of networking used in high-performance
computing with high throughput and low latency. Like Ethernet,
IB defines a layered pr

ethdev: add flow item for RoCE infiniband BTH

IB(InfiniBand) is one type of networking used in high-performance
computing with high throughput and low latency. Like Ethernet,
IB defines a layered protocol (Physical, Link, Network, Transport
Layers). IB provides native support for RDMA(Remote DMA), an
extension of the DMA that allows direct access to remote host
memory without CPU intervention. IB network requires NICs and
switches to support the IB protocol.

RoCE(RDMA over Converged Ethernet) is a network protocol that
allows RDMA to run on Ethernet. RoCE encapsulates IB packets on
Ethernet and has two versions, RoCEv1 and RoCEv2. RoCEv1 is an
Ethernet link layer protocol, IB packets are encapsulated in the
Ethernet layer and use Ethernet type 0x8915. RoCEv2 is an internet
layer protocol, IB packets are encapsulated in UDP payload and
use a destination port 4791, The format of the RoCEv2 packet is
as follows:
ETH + IP + UDP(dport 4791) + IB(BTH + ExtHDR + PAYLOAD + CRC)

BTH(Base Transport Header) is the IB transport layer header, RoCEv1
and RoCEv2 both contain this header. This patch introduces a new
RTE item to match the IB BTH in RoCE packets. One use of this match
is that the user can monitor RoCEv2's CNP(Congestion Notification
Packet) by matching BTH opcode 0x81.

This patch also adds the testpmd command line to match the RoCEv2
BTH. Usage example:

testpmd> flow create 0 group 1 ingress pattern
eth / ipv4 / udp dst is 4791 / ib_bth opcode is 0x81
dst_qp is 0xd3 / end actions queue index 0 / end

Signed-off-by: Dong Zhou <dongzhou@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>

show more ...

ethdev: add flow rule actions update

Introduce the new rte_flow_actions_update() API allowing users
to update the action list in the already existing rule.
Flow rules can be updated now without the

ethdev: add flow rule actions update

Introduce the new rte_flow_actions_update() API allowing users
to update the action list in the already existing rule.
Flow rules can be updated now without the need to destroy
the rule first and create a new one instead.
A single API call ensures that no packets are lost by
guaranteeing atomicity and flow state correctness.
The rte_flow_async_actions_update() is added as well.
The matcher is not updated, only the action list is.

Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>

show more ...

ethdev: add Tx queue flow matching item

Adding support for Tx queue flow matching item.
This item is valid only for egress rules.
An example use case would be that application can
set different vlan

ethdev: add Tx queue flow matching item

Adding support for Tx queue flow matching item.
This item is valid only for egress rules.
An example use case would be that application can
set different vlan insert rules with different PCP values
based on Tx queue number.

Signed-off-by: Kiran Kumar K <kirankumark@marvell.com>
Acked-by: Ori Kam <orika@nvidia.com>

show more ...

ethdev: add flow matching of aggregated port

When multiple ports are aggregated into a single DPDK port,
(example: Linux bonding, DPDK bonding, failsafe, etc.),
we want to know which port is used fo

ethdev: add flow matching of aggregated port

When multiple ports are aggregated into a single DPDK port,
(example: Linux bonding, DPDK bonding, failsafe, etc.),
we want to know which port is used for Rx and Tx.

This patch allows to map a Rx queue with an aggregated port by using
a flow rule. The new item is called RTE_FLOW_ITEM_TYPE_AGGR_AFFINITY.

While uses the aggregated affinity as a matching item in the flow rule,
and sets the same affinity value by call
rte_eth_dev_map_aggr_tx_affinity(), then the packet can be sent from
the same port as the receiving one.
The affinity numbering starts from 1, then trying to match on
aggr_affinity 0 will result in an error.

Add the testpmd command line to match the new item:
flow create 0 ingress group 0 pattern aggr_affinity affinity is 1 /
end actions queue index 0 / end

The above command means that creates a flow on a single DPDK port and
matches the packet from the first physical port and redirects
these packets into Rx queue 0.

Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>

show more ...

ethdev: add flow quota

Quota action limits traffic according to pre-defined configuration.
Quota reflects overall traffic usage regardless bandwidth.
Quota flow action initialized with signed tokens

ethdev: add flow quota

Quota action limits traffic according to pre-defined configuration.
Quota reflects overall traffic usage regardless bandwidth.
Quota flow action initialized with signed tokens number value.
Quota flow action updates tokens number according to
these rules:
1. if quota was configured to count packet length, for each packet
of size S, tokens number reduced by S.
2. If quota was configured to count packets, each packet decrements
tokens number.
quota action sets packet metadata according to a number of remaining
tokens number:
PASS - remaining tokens number is non-negative.
BLOCK - remaining tokens number is negative.

Quota flow item matches on that data

Application updates tokens number in quota flow action
with SET or ADD calls:
SET(QUOTA, val) - arm quota with new tokens number set to val
ADD(QUOTA, val) - increase existing quota tokens number by val

Both SET and ADD return to application number of tokens stored in port
before update.

If quota state was BLOCK (negative action tokens number)
application can change it to PASS after providing enough tokens to
raise action tokens number to 0 or above.

Application must create a rule with quota action to mark flow and
match on the mark with quota item in following flow rule.

Signed-off-by: Gregory Etelson <getelson@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>

show more ...

ethdev: add atomic flow query and update

Current API allows either query or update indirect flow action.
If indirect action must be conditionally updated according to it's
present state application

ethdev: add atomic flow query and update

Current API allows either query or update indirect flow action.
If indirect action must be conditionally updated according to it's
present state application must first issue action query then
analyze returned data and if needed issue update request.
When the update will be processed, action state can change and
the update can invalidate the action.

Add `rte_flow_action_handle_query_update` function call,
and it's async version `rte_flow_async_action_handle_query_update`
to atomically query and update flow action.

Application can control query and update order, if that is supported
by port hardware, by setting `qu_mode` parameter to
RTE_FLOW_QU_QUERY_FIRST or RTE_FLOW_QU_UPDATE_FIRST.

Signed-off-by: Gregory Etelson <getelson@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>

show more ...

ethdev: share indirect action between ports

The flow API implements the concept of shared objects,
known as indirect actions (RTE_FLOW_ACTION_TYPE_INDIRECT).
An application can create the indirect a

ethdev: share indirect action between ports

The flow API implements the concept of shared objects,
known as indirect actions (RTE_FLOW_ACTION_TYPE_INDIRECT).
An application can create the indirect action of desired
type and configuration with rte_flow_action_handle_create
call and then specify the obtained action handle in multiple
flows.

The initial concept supposes the action handle has strict
attachment to the port it was created on and to be used
exclusively in the flows being installed on the port.

Nowadays the multipath network topologies are quite common,
packets belonging to the same connection might arrive and
be sent over multiple ports, and there is the raising demand
to handle these "spread" connections. To fulfil this demand
it is proposed to extend indirect action sharing across the
multiple ports. This kind of sharing would be extremely useful
for the meters and counters, allowing to manage the single
connection over the multiple ports.

This cross-port object sharing is hard to implement in
generic way merely with software on the upper layers, but
can be provided by the driver over the single hardware
instance, where multiple ports reside on the same physical
NIC and share the same hardware context.

To allow this action sharing application should specify
the "host port" during flow configuring to claim the intention
to share the indirect actions. All indirect actions reside within
"host port" context and can be shared in flows being installed
on the host port and on all the ports referencing this one.

If sharing between host and port being configured is not supported
the configuration should be rejected with error. There might be
multiple independent (mutual exclusive) sharing domains with
dedicated host and referencing ports.

To manage the shared indirect action any port from sharing domain
can be specified. To share or not the created action is up to
application, no API change is needed.

Support is added into testpmd to share an indirect action.
An action should be created on single port and the handle
can be used in the templates and flows on multiple ports,
example:

flow configure 0 queues_number 1 queues_size 64 counters_number 64
flow configure 1 queues_number 1 queues_size 64 counters_number 0 \
host_port 0 flags 1

flow indirect_action 0 create ingress action_id 0 action count / end

flow actions_template 0 create ingress actions_template_id 8
template indirect 0 / queue index 0 / end
mask count / queue index 0 / end

flow actions_template 1 create ingress actions_template_id 18
template shared_indirect 0 0 / queue index 0 / end
mask count / queue index 0 / end

Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>

show more ...

ethdev: add flow template table insertion type

Allow user to specify insertion type used in template tables.
The insertion type is responsible for choosing the appropriate key
value used to map inse

ethdev: add flow template table insertion type

Allow user to specify insertion type used in template tables.
The insertion type is responsible for choosing the appropriate key
value used to map inserted flow rules into a template table.

Flow rules can be inserted by calculating the hash value for
the pattern or inserted by index via the new create_by_index() API.
The idea of the index-based insertion is to avoid additional matches
and simply execute predefined actions after jumping to the index.

This is how the regular pattern-based table works:
1. The hash is calculated on a 5-tuple of a packet.
2. The corresponding entry in the table is checked for collisions.
3. Actions are executed once the final entry is found.
The index-based table skips any lookups for the packet:
1. The index value is taken from a specified field.
2. Actions are executed at the specified index in the table.

The insertion into an already occupied index results in an error.
The old rule must be destroyed first. An index cannot be bigger than
the size of the table, otherwise, the rule is rejected as well.

Add testpmd CLI interface for specifying a template table insertion type.
Available types are: pattern and index.
flow template_table 0 create table_id 0 insertion_type index ...
Allow specifying the rule index instead of the pattern template index:
flow queue 0 create 0 template_table 0 rule_index 5 actions_template 0 ...

Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>

show more ...

ethdev: match ICMPv6 ID and sequence

This patch adds API support for ICMPv6 ID and sequence.
1: Add two new pattern item types for ICMPv6 echo request and reply:
RTE_FLOW_ITEM_TYPE_ICMP6_ECHO_REQU

ethdev: match ICMPv6 ID and sequence

This patch adds API support for ICMPv6 ID and sequence.
1: Add two new pattern item types for ICMPv6 echo request and reply:
RTE_FLOW_ITEM_TYPE_ICMP6_ECHO_REQUEST
RTE_FLOW_ITEM_TYPE_ICMP6_ECHO_REPLY

2: Add new structures for ICMP packet definitions.
struct rte_icmp_base_hdr; # For basic header of all ICMP/ICMPv6 header
struct rte_icmp_echo_hdr; # For ICMP/ICMPv6 echo header

The existing struct rte_icmp_hdr should not be used in new code. It
should be set to be deprecated in future. The reason for that is,
icmp_ident/icmp_seq_nb are not common fields of ICMP/ICMPv6 packets.

3: Enhance testpmd flow pattern to support ICMPv6 identifier and sequence.

Example of ICMPv6 echo pattern in testpmd command:

pattern eth / ipv6 / icmp6_echo_request / end
pattern eth / ipv6 / icmp6_echo_reply / end
pattern eth / ipv6 / icmp6_echo_request ident is 20 seq is 30 / end

Signed-off-by: Leo Xu <yongquanx@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>

show more ...

ethdev: add trace points for flow

Adds trace points for rte_flow specific functions in ethdev lib.

Signed-off-by: Ankur Dwivedi <adwivedi@marvell.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by:

ethdev: add trace points for flow

Adds trace points for rte_flow specific functions in ethdev lib.

Signed-off-by: Ankur Dwivedi <adwivedi@marvell.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>

show more ...

ethdev: add flow matching of IPv6 routing extension

Add IPv6 routing extension header definition and no
TLV support for now.

At rte_flow layer, there are new items defined for matching
type/nexthdr

ethdev: add flow matching of IPv6 routing extension

Add IPv6 routing extension header definition and no
TLV support for now.

At rte_flow layer, there are new items defined for matching
type/nexthdr/segments_left field.

Add command line support for IPv6 routing extension header
matching: type/nexthdr/segment_list.

Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>

show more ...

ethdev: add queue-based API to report aged flow rules

When application use queue-based flow rule management and operate the
same flow rule on the same queue, e.g create/destroy/query, API of
queryin

ethdev: add queue-based API to report aged flow rules

When application use queue-based flow rule management and operate the
same flow rule on the same queue, e.g create/destroy/query, API of
querying aged flow rules should also have queue id parameter just like
other queue-based flow APIs.

By this way, PMD can work in more optimized way since resources are
isolated by queue and needn't synchronize.

If application do use queue-based flow management but configure port
without RTE_FLOW_PORT_FLAG_STRICT_QUEUE, which means application operate
a given flow rule on different queues, the queue id parameter will
be ignored.

Signed-off-by: Michael Baum <michaelba@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>

show more ...

ethdev: add send to kernel action

In some cases application may receive a packet that should have been
received by the kernel. In this case application uses KNI or other means
to transfer the packet

ethdev: add send to kernel action

In some cases application may receive a packet that should have been
received by the kernel. In this case application uses KNI or other means
to transfer the packet to the kernel.

With bifurcated driver we can have a rule to route packets matching
a pattern (example: IPv4 packets) to the DPDK application and the rest
of the traffic will be received by the kernel.
But if we want to receive most of the traffic in DPDK except specific
pattern (example: ICMP packets) that should be processed by the kernel,
then it's easier to re-route these packets with a single rule.

This commit introduces new rte_flow action which allows application to
re-route packets directly to the kernel without software involvement.

Add new testpmd rte_flow action 'send_to_kernel'. The application
may use this action to route the packet to the kernel while still
in the HW.

Example with testpmd command:

flow create 0 ingress priority 0 group 1 pattern eth type spec 0x0800
type mask 0xffff / end actions send_to_kernel / end

Signed-off-by: Michael Savisko <michaelsav@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>

show more ...

ethdev: forbid direction attribute in transfer flow rules

As part of DPDK 21.11 release, it was announced that the
use of attributes 'ingress' and 'egress' in 'transfer'
rules was deprecated. The tr

ethdev: forbid direction attribute in transfer flow rules

As part of DPDK 21.11 release, it was announced that the
use of attributes 'ingress' and 'egress' in 'transfer'
rules was deprecated. The transition period is over.

Starting from DPDK 22.11, the use of direction attributes
with attribute 'transfer' is not allowed. To enforce that,
a generic check is added to flow rule validate API.

Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Reviewed-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>

show more ...

ethdev: remove deprecated flow actions to copy TTL

These actions are supported by no drivers.

The patch breaks ABI.

Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Ajit K

ethdev: remove deprecated flow actions to copy TTL

These actions are supported by no drivers.

The patch breaks ABI.

Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Acked-by: Ori Kam <orika@nvidia.com>

show more ...

ethdev: remove deprecated flow action to set layer 3 TTL

The action is supported by no drivers.

The patch breaks ABI.

Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Ajit

ethdev: remove deprecated flow action to set layer 3 TTL

The action is supported by no drivers.

The patch breaks ABI.

Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Acked-by: Ori Kam <orika@nvidia.com>

show more ...

ethdev: remove deprecated flow action to decrement MPLS TTL

The action is supported by no drivers.

The patch breaks ABI.

Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: A

ethdev: remove deprecated flow action to decrement MPLS TTL

The action is supported by no drivers.

The patch breaks ABI.

Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Acked-by: Ori Kam <orika@nvidia.com>

show more ...

ethdev: remove deprecated flow action to set MPLS TTL

The action is supported by no drivers.

The patch breaks ABI.

Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Ajit Kh

ethdev: remove deprecated flow action to set MPLS TTL

The action is supported by no drivers.

The patch breaks ABI.

Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Acked-by: Ori Kam <orika@nvidia.com>

show more ...

ethdev: add meter color mark flow action

Create a new Flow API action: METER_MARK.
It Meters a packet stream and marks its packets with colors.
The marking is done on a metadata, not on a packet fie

ethdev: add meter color mark flow action

Create a new Flow API action: METER_MARK.
It Meters a packet stream and marks its packets with colors.
The marking is done on a metadata, not on a packet field.
Unlike the METER action, it performs no policing at all.
A user has the flexibility to create any policies with the help of
the METER_COLOR item later, only meter profile is mandatory here.

Add testpmd command line to match for METER_MARK action:
flow create ... actions meter_mark mtr_profile 20 / end

Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>

show more ...

ethdev: add meter color flow matching item

Provide an ability to use a Color Marker set by a Meter
as a matching item in Flow API. The Color Marker reflects
the metering result by setting the metada

ethdev: add meter color flow matching item

Provide an ability to use a Color Marker set by a Meter
as a matching item in Flow API. The Color Marker reflects
the metering result by setting the metadata for a
packet to a particular codepoint: green, yellow or red.

Add testpmd command line to match on a meter color:
flow create 0 ingress group 0 pattern meter color is green / end

Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>

show more ...

ethdev: add indirect action async query

As rte_flow_action_handle_create/destroy/update() have their own
asynchronous rte_flow_async_action_handle_create/destroy/update()
version functions to accele

ethdev: add indirect action async query

As rte_flow_action_handle_create/destroy/update() have their own
asynchronous rte_flow_async_action_handle_create/destroy/update()
version functions to accelerate the indirect action operations in
queue based flow engine. Currently, the asynchronous version query
function for indirect action was missing.

Add rte_flow_async_action_handle_query() function corresponding
to rte_flow_action_handle_query(). The new asynchronous version
function enables enqueue the query to the hardware similar as
asynchronous flow management does and returns immediately to free
the CPU for other tasks. Application can get the query results from
rte_flow_pull() when the hardware completes its work.

Signed-off-by: Suanming Mou <suanmingm@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>

show more ...

ethdev: remove deprecated flow action physical port

Such deprecation was commenced in DPDK 21.11.
Since then, no parties have objected. Remove.

The patch breaks ABI.

Signed-off-by: Ivan Malov <iva

ethdev: remove deprecated flow action physical port

Such deprecation was commenced in DPDK 21.11.
Since then, no parties have objected. Remove.

The patch breaks ABI.

Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Reviewed-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>

show more ...

ethdev: remove deprecated flow item physical port

Such deprecation was commenced in DPDK 21.11.
Since then, no parties have objected. Remove.

The patch breaks ABI.

Signed-off-by: Ivan Malov <ivan.

ethdev: remove deprecated flow item physical port

Such deprecation was commenced in DPDK 21.11.
Since then, no parties have objected. Remove.

The patch breaks ABI.

Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Reviewed-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>

show more ...

ethdev: remove deprecated flow item VF

Such deprecation was commenced in DPDK 21.11.
Since then, no parties have objected. Remove.

The patch breaks ABI.

Signed-off-by: Ivan Malov <ivan.malov@oktet

ethdev: remove deprecated flow item VF

Such deprecation was commenced in DPDK 21.11.
Since then, no parties have objected. Remove.

The patch breaks ABI.

Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Reviewed-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>

show more ...