ethdev: bring in async indirect actions operations

Queue-based flow rules management mechanism is suitable
not only for flow rules creation/destruction, but also
for speeding up other types of Flow

ethdev: bring in async indirect actions operations

Queue-based flow rules management mechanism is suitable
not only for flow rules creation/destruction, but also
for speeding up other types of Flow API management.
Indirect action object operations may be executed
asynchronously as well. Provide async versions for all
indirect action operations, namely:
rte_flow_async_action_handle_create,
rte_flow_async_action_handle_destroy and
rte_flow_async_action_handle_update.

Signed-off-by: Alexander Kozyrev <[email protected]>
Acked-by: Ori Kam <[email protected]>
Acked-by: Andrew Rybchenko <[email protected]>

show more ...

ethdev: bring in async queue-based flow rules operations

A new, faster, queue-based flow rules management mechanism is needed for
applications offloading rules inside the datapath. This asynchronous

ethdev: bring in async queue-based flow rules operations

A new, faster, queue-based flow rules management mechanism is needed for
applications offloading rules inside the datapath. This asynchronous
and lockless mechanism frees the CPU for further packet processing and
reduces the performance impact of the flow rules creation/destruction
on the datapath. Note that queues are not thread-safe and the queue
should be accessed from the same thread for all queue operations.
It is the responsibility of the app to sync the queue functions in case
of multi-threaded access to the same queue.

The rte_flow_async_create() function enqueues a flow creation to the
requested queue. It benefits from already configured resources and sets
unique values on top of item and action templates. A flow rule is enqueued
on the specified flow queue and offloaded asynchronously to the hardware.
The function returns immediately to spare CPU for further packet
processing. The application must invoke the rte_flow_pull() function
to complete the flow rule operation offloading, to clear the queue, and to
receive the operation status. The rte_flow_async_destroy() function
enqueues a flow destruction to the requested queue.

Signed-off-by: Alexander Kozyrev <[email protected]>
Acked-by: Ori Kam <[email protected]>
Acked-by: Andrew Rybchenko <[email protected]>

show more ...

ethdev: add flow item/action templates

Treating every single flow rule as a completely independent and separate
entity negatively impacts the flow rules insertion rate. Oftentimes in an
application,

ethdev: add flow item/action templates

Treating every single flow rule as a completely independent and separate
entity negatively impacts the flow rules insertion rate. Oftentimes in an
application, many flow rules share a common structure (the same item mask
and/or action list) so they can be grouped and classified together.
This knowledge may be used as a source of optimization by a PMD/HW.

The pattern template defines common matching fields (the item mask) without
values. The actions template holds a list of action types that will be used
together in the same rule. The specific values for items and actions will
be given only during the rule creation.

A table combines pattern and actions templates along with shared flow rule
attributes (group ID, priority and traffic direction). This way a PMD/HW
can prepare all the resources needed for efficient flow rules creation in
the datapath. To avoid any hiccups due to memory reallocation, the maximum
number of flow rules is defined at the table creation time.

The flow rule creation is done by selecting a table, a pattern template
and an actions template (which are bound to the table), and setting unique
values for the items and actions.

Signed-off-by: Alexander Kozyrev <[email protected]>
Acked-by: Ori Kam <[email protected]>
Acked-by: Andrew Rybchenko <[email protected]>

show more ...

ethdev: introduce flow engine configuration

The flow rules creation/destruction at a large scale incurs a performance
penalty and may negatively impact the packet processing when used
as part of the

ethdev: introduce flow engine configuration

The flow rules creation/destruction at a large scale incurs a performance
penalty and may negatively impact the packet processing when used
as part of the datapath logic. This is mainly because software/hardware
resources are allocated and prepared during the flow rule creation.

In order to optimize the insertion rate, PMD may use some hints provided
by the application at the initialization phase. The rte_flow_configure()
function allows to pre-allocate all the needed resources beforehand.
These resources can be used at a later stage without costly allocations.
Every PMD may use only the subset of hints and ignore unused ones or
fail in case the requested configuration is not supported.

The rte_flow_info_get() is available to retrieve the information about
supported pre-configurable resources. Both these functions must be called
before any other usage of the flow API engine.

Signed-off-by: Alexander Kozyrev <[email protected]>
Acked-by: Ori Kam <[email protected]>
Reviewed-by: Andrew Rybchenko <[email protected]>

show more ...

ethdev: support GRE optional fields

Add flow pattern items and header format for matching optional fields
(checksum/key/sequence) in GRE header. And the flags in gre item should
be correspondingly s

ethdev: support GRE optional fields

Add flow pattern items and header format for matching optional fields
(checksum/key/sequence) in GRE header. And the flags in gre item should
be correspondingly set with the new added items.

Signed-off-by: Sean Zhang <[email protected]>
Acked-by: Ori Kam <[email protected]>

show more ...

ethdev: announce migration to generic flow modify action

The generic RTE_FLOW_ACTION_TYPE_MODIFY_FIELD action was
introduced by [1]. This action provides an unified way
to perform various arithmetic

ethdev: announce migration to generic flow modify action

The generic RTE_FLOW_ACTION_TYPE_MODIFY_FIELD action was
introduced by [1]. This action provides an unified way
to perform various arithmetic and transfer operations over
packet network header fields and packet metadata.

[1] 73b68f4c54a0 ("ethdev: introduce generic modify flow action")

On other side there are a bunch of multiple legacy actions,
that can be superseded by the generic MODIFY_FIELD action:

RTE_FLOW_ACTION_TYPE_OF_SET_MPLS_TTL
RTE_FLOW_ACTION_TYPE_OF_DEC_MPLS_TTL
RTE_FLOW_ACTION_TYPE_OF_SET_NW_TTL
RTE_FLOW_ACTION_TYPE_OF_DEC_NW_TTL sfc
RTE_FLOW_ACTION_TYPE_OF_COPY_TTL_OUT
RTE_FLOW_ACTION_TYPE_OF_COPY_TTL_IN
RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC bnxt, cxgbe, mlx5
RTE_FLOW_ACTION_TYPE_SET_IPV4_DST bnxt, cxgbe, mlx5
RTE_FLOW_ACTION_TYPE_SET_IPV6_SRC cxgbe, mlx5
RTE_FLOW_ACTION_TYPE_SET_IPV6_DST cxgbe, mlx5
RTE_FLOW_ACTION_TYPE_SET_TP_SRC cxgbe, mlx5
RTE_FLOW_ACTION_TYPE_SET_TP_DST cxgbe, mlx5
RTE_FLOW_ACTION_TYPE_DEC_TTL mlx5, sfc
RTE_FLOW_ACTION_TYPE_SET_TTL mlx5
RTE_FLOW_ACTION_TYPE_SET_MAC_SRC cxgbe, mlx5
RTE_FLOW_ACTION_TYPE_SET_MAC_DST cxgbe, mlx5
RTE_FLOW_ACTION_TYPE_INC_TCP_SEQ mlx5
RTE_FLOW_ACTION_TYPE_DEC_TCP_SEQ mlx5
RTE_FLOW_ACTION_TYPE_INC_TCP_ACK mlx5
RTE_FLOW_ACTION_TYPE_DEC_TCP_ACK mlx5
RTE_FLOW_ACTION_TYPE_SET_IPV4_DSCP mlx5
RTE_FLOW_ACTION_TYPE_SET_IPV6_DSCP mlx5
RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID bnxt, cnxk, cxgbe, enic,
mlx5, octeontx2, sfc
RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP bnxt, cnxk, cxgbe, enic,
mlx5, octeontx2, sfc
RTE_FLOW_ACTION_TYPE_SET_TAG mlx5
RTE_FLOW_ACTION_TYPE_SET_META mlx5

This note deprecates the following RTE Flow actions,
as not supported by any of PMDs:

RTE_FLOW_ACTION_TYPE_OF_SET_MPLS_TTL
RTE_FLOW_ACTION_TYPE_OF_DEC_MPLS_TTL
RTE_FLOW_ACTION_TYPE_OF_SET_NW_TTL
RTE_FLOW_ACTION_TYPE_OF_COPY_TTL_OUT
RTE_FLOW_ACTION_TYPE_OF_COPY_TTL_IN

The following actions are supposed to be deprecated in 22.07
and replaced by generic field modify action:

RTE_FLOW_ACTION_TYPE_OF_DEC_NW_TTL
RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC
RTE_FLOW_ACTION_TYPE_SET_IPV4_DST
RTE_FLOW_ACTION_TYPE_SET_IPV6_SRC
RTE_FLOW_ACTION_TYPE_SET_IPV6_DST
RTE_FLOW_ACTION_TYPE_SET_TP_SRC
RTE_FLOW_ACTION_TYPE_SET_TP_DST
RTE_FLOW_ACTION_TYPE_DEC_TTL
RTE_FLOW_ACTION_TYPE_SET_TTL
RTE_FLOW_ACTION_TYPE_SET_MAC_SRC
RTE_FLOW_ACTION_TYPE_SET_MAC_DST
RTE_FLOW_ACTION_TYPE_INC_TCP_SEQ
RTE_FLOW_ACTION_TYPE_DEC_TCP_SEQ
RTE_FLOW_ACTION_TYPE_INC_TCP_ACK
RTE_FLOW_ACTION_TYPE_DEC_TCP_ACK
RTE_FLOW_ACTION_TYPE_SET_IPV4_DSCP
RTE_FLOW_ACTION_TYPE_SET_IPV6_DSCP
RTE_FLOW_ACTION_TYPE_SET_TAG
RTE_FLOW_ACTION_TYPE_SET_META

The VLAN set actions are interrelated to VLAN header insertion/removal
and supported by multiple PMDs and widely used by applications and
not supposed to be deprecated due to potential large impact on
drivers and applications.

Signed-off-by: Viacheslav Ovsiienko <[email protected]>
Acked-by: Ferruh Yigit <[email protected]>
Acked-by: Thomas Monjalon <[email protected]>
Acked-by: Olivier Matz <[email protected]>

show more ...

ethdev: fix typos

Fixes: 9039c8125730 ("ethdev: change promiscuous callbacks to return status")
Fixes: 12e6e3e78fe0 ("ethdev: add API to dump device internal flow info")
Fixes: 44bf3c796be3 ("ethdev

ethdev: fix typos

Fixes: 9039c8125730 ("ethdev: change promiscuous callbacks to return status")
Fixes: 12e6e3e78fe0 ("ethdev: add API to dump device internal flow info")
Fixes: 44bf3c796be3 ("ethdev: support flow aging")
Cc: [email protected]

Signed-off-by: Ferruh Yigit <[email protected]>
Acked-by: Ori Kam <[email protected]>

show more ...

ethdev: add capability to keep flow rules on restart

Previously, it was not specified what happens to the flow rules
when the device is stopped, possibly reconfigured, then started.
If flow rules we

ethdev: add capability to keep flow rules on restart

Previously, it was not specified what happens to the flow rules
when the device is stopped, possibly reconfigured, then started.
If flow rules were kept, it could be convenient for application
developers, because they wouldn't need to save and restore them.
However, due to the number of flows and possible creation rate it is
impractical to save all flow rules in DPDK layer. This means that flow
rules persistence really depends on whether PMD and HW can implement it
efficiently. It can also be limited by the rule item and action types,
and its attributes transfer bit (a combination of an item/action type
and a value of the transfer bit is called a rule feature).

Add a device capability bit for PMDs that can keep at least some
of the flow rules across restart. Without this capability behavior
is still unspecified and it is declared that the application must
flush the rules before stopping the device.
Allow the application to test for persistence of rules using
a particular feature by attempting to create a flow rule
using that feature when the device is stopped
and checking for the specific error.
This is logical because if the PMD can to create the flow rule
when the device is not started and use it after the start happens,
it is natural that it can move its internal flow rule object
to the same state when the device is stopped and restore the state
when the device is started.

Rule persistence across a reconfigurations is not required,
because tracking all the rules and configuration-dependent resources
they use may be infeasible. In case a PMD cannot keep the rules
across reconfiguration, it is allowed just to report an error.
Application must then flush the rules before attempting it.

Signed-off-by: Dmitry Kozlyuk <[email protected]>
Acked-by: Ori Kam <[email protected]>
Acked-by: Andrew Rybchenko <[email protected]>

show more ...

mbuf: add namespace to offload flags

Fix the mbuf offload flags namespace by adding an RTE_ prefix to the
name. The old flags remain usable, but a deprecation warning is issued
at compilation.

Sign

mbuf: add namespace to offload flags

Fix the mbuf offload flags namespace by adding an RTE_ prefix to the
name. The old flags remain usable, but a deprecation warning is issued
at compilation.

Signed-off-by: Olivier Matz <[email protected]>
Acked-by: Andrew Rybchenko <[email protected]>
Acked-by: Ajit Khaparde <[email protected]>
Acked-by: Somnath Kotur <[email protected]>

show more ...

ethdev: add namespace

Add 'RTE_ETH' namespace to all enums & macros in a backward compatible
way. The macros for backward compatibility can be removed in next LTS.
Also updated some struct names to

ethdev: add namespace

Add 'RTE_ETH' namespace to all enums & macros in a backward compatible
way. The macros for backward compatibility can be removed in next LTS.
Also updated some struct names to have 'rte_eth' prefix.

All internal components switched to using new names.

Syntax fixed on lines that this patch touches.

Signed-off-by: Ferruh Yigit <[email protected]>
Acked-by: Tyler Retzlaff <[email protected]>
Acked-by: Andrew Rybchenko <[email protected]>
Acked-by: Ajit Khaparde <[email protected]>
Acked-by: Jerin Jacob <[email protected]>
Acked-by: Wisam Jaddo <[email protected]>
Acked-by: Rosen Xu <[email protected]>
Acked-by: Chenbo Xia <[email protected]>
Acked-by: Hemant Agrawal <[email protected]>
Acked-by: Somnath Kotur <[email protected]>

show more ...

ethdev: support L2TPv2 and PPP procotol

Added flow pattern items and header formats of L2TPv2 and PPP.

Signed-off-by: Wenjun Wu <[email protected]>
Signed-off-by: Jie Wang <[email protected]>

ethdev: support L2TPv2 and PPP procotol

Added flow pattern items and header formats of L2TPv2 and PPP.

Signed-off-by: Wenjun Wu <[email protected]>
Signed-off-by: Jie Wang <[email protected]>
Acked-by: Ori Kam <[email protected]>
Acked-by: Andrew Rybchenko <[email protected]>
Reviewed-by: Ferruh Yigit <[email protected]>

show more ...

ethdev: fix ID spelling in comments and log messages

Signed-off-by: Andrew Rybchenko <[email protected]>
Acked-by: Ori Kam <[email protected]>
Reviewed-by: Ferruh Yigit <ferruh.yigit@inte

ethdev: fix ID spelling in comments and log messages

Signed-off-by: Andrew Rybchenko <[email protected]>
Acked-by: Ori Kam <[email protected]>
Reviewed-by: Ferruh Yigit <[email protected]>

show more ...

ethdev: fix VLAN spelling including VLAN ID case

Signed-off-by: Andrew Rybchenko <[email protected]>
Acked-by: Ori Kam <[email protected]>
Reviewed-by: Ferruh Yigit <[email protected]

ethdev: fix VLAN spelling including VLAN ID case

Signed-off-by: Andrew Rybchenko <[email protected]>
Acked-by: Ori Kam <[email protected]>
Reviewed-by: Ferruh Yigit <[email protected]>

show more ...

ethdev: avoid documentation in next lines

Documentation in the next separate line is confusing. If documentation
requires own line it should be before, not after.

Move documentation to the previous

ethdev: avoid documentation in next lines

Documentation in the next separate line is confusing. If documentation
requires own line it should be before, not after.

Move documentation to the previous line if documentation on the same
line makes it too long.

Fix a number of incorrect markups on the way.

When a lines is touched by the patch anyway, do other cosmetics
changes to avoid changes in next patches.

Signed-off-by: Andrew Rybchenko <[email protected]>
Acked-by: Ori Kam <[email protected]>
Reviewed-by: Ferruh Yigit <[email protected]>

show more ...

ethdev: replace bit shifts with macros

The macros RTE_BIT32 and RTE_BIT64 are used to replace bit shifts.
The macro UINT64C is also used to replace remaining occurrences of ULL.

The bit shifts of E

ethdev: replace bit shifts with macros

The macros RTE_BIT32 and RTE_BIT64 are used to replace bit shifts.
The macro UINT64C is also used to replace remaining occurrences of ULL.

The bit shifts of ETH_RSS_LEVEL_* are kept for aesthetic reason.

The API of rte_mtr and rte_tm is using enums for 64-bit variables.
As they are enums, unsigned bit cannot be used.

Signed-off-by: Thomas Monjalon <[email protected]>
Reviewed-by: Andrew Rybchenko <[email protected]>

show more ...

ethdev: introduce configurable flexible item

1. Introduction and Retrospective

Nowadays the networks are evolving fast and wide, the network
structures are getting more and more complicated, the ne

ethdev: introduce configurable flexible item

1. Introduction and Retrospective

Nowadays the networks are evolving fast and wide, the network
structures are getting more and more complicated, the new
application areas are emerging. To address these challenges
the new network protocols are continuously being developed,
considered by technical communities, adopted by industry and,
eventually implemented in hardware and software. The DPDK
framework follows the common trends and if we bother
to glance at the RTE Flow API header we see the multiple
new items were introduced during the last years since
the initial release.

The new protocol adoption and implementation process is
not straightforward and takes time, the new protocol passes
development, consideration, adoption, and implementation
phases. The industry tries to mitigate and address the
forthcoming network protocols, for example, many hardware
vendors are implementing flexible and configurable network
protocol parsers. As DPDK developers, could we anticipate
the near future in the same fashion and introduce the similar
flexibility in RTE Flow API?

Let's check what we already have merged in our project, and
we see the nice raw item (rte_flow_item_raw). At the first
glance, it looks superior and we can try to implement a flow
matching on the header of some relatively new tunnel protocol,
say on the GENEVE header with variable length options. And,
under further consideration, we run into the raw item
limitations:

- only fixed size network header can be represented
- the entire network header pattern of fixed format
(header field offsets are fixed) must be provided
- the search for patterns is not robust (the wrong matches
might be triggered), and actually is not supported
by existing PMDs
- no explicitly specified relations with preceding
and following items
- no tunnel hint support

As the result, implementing the support for tunnel protocols
like aforementioned GENEVE with variable extra protocol option
with flow raw item becomes very complicated and would require
multiple flows and multiple raw items chained in the same
flow (by the way, there is no support found for chained raw
items in implemented drivers).

This RFC introduces the dedicated flex item (rte_flow_item_flex)
to handle matches with existing and new network protocol headers
in a unified fashion.

2. Flex Item Life Cycle

Let's assume there are the requirements to support the new
network protocol with RTE Flows. What is given within protocol
specification:

- header format
- header length, (can be variable, depending on options)
- potential presence of extra options following or included
in the header the header
- the relations with preceding protocols. For example,
the GENEVE follows UDP, eCPRI can follow either UDP
or L2 header
- the relations with following protocols. For example,
the next layer after tunnel header can be L2 or L3
- whether the new protocol is a tunnel and the header
is a splitting point between outer and inner layers

The supposed way to operate with flex item:

- application defines the header structures according to
protocol specification

- application calls rte_flow_flex_item_create() with desired
configuration according to the protocol specification, it
creates the flex item object over specified ethernet device
and prepares PMD and underlying hardware to handle flex
item. On item creation call PMD backing the specified
ethernet device returns the opaque handle identifying
the object has been created

- application uses the rte_flow_item_flex with obtained handle
in the flows, the values/masks to match with fields in the
header are specified in the flex item per flow as for regular
items (except that pattern buffer combines all fields)

- flows with flex items match with packets in a regular fashion,
the values and masks for the new protocol header match are
taken from the flex items in the flows

- application destroys flows with flex items

- application calls rte_flow_flex_item_release() as part of
ethernet device API and destroys the flex item object in
PMD and releases the engaged hardware resources

3. Flex Item Structure

The flex item structure is intended to be used as part of the flow
pattern like regular RTE flow items and provides the mask and
value to match with fields of the protocol item was configured
for.

struct rte_flow_item_flex {
void *handle;
uint32_t length;
const uint8_t* pattern;
};

The handle is some opaque object maintained on per device basis
by underlying driver.

The protocol header fields are considered as bit fields, all
offsets and widths are expressed in bits. The pattern is the
buffer containing the bit concatenation of all the fields
presented at item configuration time, in the same order and
same amount. If byte boundary alignment is needed an application
can use a dummy type field, this is just some kind of gap filler.

The length field specifies the pattern buffer length in bytes
and is needed to allow rte_flow_copy() operations. The approach
of multiple pattern pointers and lengths (per field) was
considered and found clumsy - it seems to be much suitable for
the application to maintain the single structure within the
single pattern buffer.

4. Flex Item Configuration

The flex item configuration consists of the following parts:

- header field descriptors:
- next header
- next protocol
- sample to match
- input link descriptors
- output link descriptors

The field descriptors tell the driver and hardware what data should
be extracted from the packet and then control the packet handling
in the flow engine. Besides this, sample fields can be presented
to match with patterns in the flows. Each field is a bit pattern.
It has width, offset from the header beginning, mode of offset
calculation, and offset related parameters.

The next header field is special, no data are actually taken
from the packet, but its offset is used as a pointer to the next
header in the packet, in other words the next header offset
specifies the size of the header being parsed by flex item.

There is one more special field - next protocol, it specifies
where the next protocol identifier is contained and packet data
sampled from this field will be used to determine the next
protocol header type to continue packet parsing. The next
protocol field is like eth_type field in MAC2, or proto field
in IPv4/v6 headers.

The sample fields are used to represent the data be sampled
from the packet and then matched with established flows.

There are several methods supposed to calculate field offset
in runtime depending on configuration and packet content:

- FIELD_MODE_FIXED - fixed offset. The bit offset from
header beginning is permanent and defined by field_base
configuration parameter.

- FIELD_MODE_OFFSET - the field bit offset is extracted
from other header field (indirect offset field). The
resulting field offset to match is calculated from as:

field_base + (*offset_base & offset_mask) << offset_shift

This mode is useful to sample some extra options following
the main header with field containing main header length.
Also, this mode can be used to calculate offset to the
next protocol header, for example - IPv4 header contains
the 4-bit field with IPv4 header length expressed in dwords.
One more example - this mode would allow us to skip GENEVE
header variable length options.

- FIELD_MODE_BITMASK - the field bit offset is extracted
from other header field (indirect offset field), the latter
is considered as bitmask containing some number of one bits,
the resulting field offset to match is calculated as:

field_base + bitcount(*offset_base & offset_mask) << offset_shift

This mode would be useful to skip the GTP header and its
extra options with specified flags.

- FIELD_MODE_DUMMY - dummy field, optionally used for byte
boundary alignment in pattern. Pattern mask and data are
ignored in the match. All configuration parameters besides
field size and offset are ignored.

Note: "*" - means the indirect field offset is calculated
and actual data are extracted from the packet by this
offset (like data are fetched by pointer *p from memory).

The offset mode list can be extended by vendors according to
hardware supported options.

The input link configuration section tells the driver after
what protocols and at what conditions the flex item can follow.
Input link specified the preceding header pattern, for example
for GENEVE it can be UDP item specifying match on destination
port with value 6081. The flex item can follow multiple header
types and multiple input links should be specified. At flow
creation time the item with one of the input link types should
precede the flex item and driver will select the correct flex
item settings, depending on the actual flow pattern.

The output link configuration section tells the driver how
to continue packet parsing after the flex item protocol.
If multiple protocols can follow the flex item header the
flex item should contain the field with the next protocol
identifier and the parsing will be continued depending
on the data contained in this field in the actual packet.

The flex item fields can participate in RSS hash calculation,
the dedicated flag is present in the field description to specify
what fields should be provided for hashing.

5. Flex Item Chaining

If there are multiple protocols supposed to be supported with
flex items in chained fashion - two or more flex items within
the same flow and these ones might be neighbors in the pattern,
it means the flex items are mutual referencing. In this case,
the item that occurred first should be created with empty
output link list or with the list including existing items,
and then the second flex item should be created referencing
the first flex item as input arc, drivers should adjust
the item configuration.

Also, the hardware resources used by flex items to handle
the packet can be limited. If there are multiple flex items
that are supposed to be used within the same flow it would
be nice to provide some hint for the driver that these two
or more flex items are intended for simultaneous usage.
The fields of items should be assigned with hint indices
and these indices from two or more flex items supposed
to be provided within the same flow should be the same
as well. In other words, the field hint index specifies
the group of fields that can be matched simultaneously
within a single flow. If hint indices are specified,
the driver will try to engage not overlapping hardware
resources and provide independent handling of the field
groups with unique indices. If the hint index is zero
the driver assigns resources on its own.

6. Example of New Protocol Handling

Let's suppose we have the requirements to handle the new tunnel
protocol that follows UDP header with destination port 0xFADE
and is followed by MAC header. Let the new protocol header format
be like this:

struct new_protocol_header {
rte_be32 header_length; /* length in dwords, including options */
rte_be32 specific0; /* some protocol data, no intention */
rte_be32 specific1; /* to match in flows on these fields */
rte_be32 crucial; /* data of interest, match is needed */
rte_be32 options[0]; /* optional protocol data, variable length */
};

The supposed flex item configuration:

struct rte_flow_item_flex_field field0 = {
.field_mode = FIELD_MODE_DUMMY, /* Affects match pattern only */
.field_size = 96, /* three dwords from the beginning */
};
struct rte_flow_item_flex_field field1 = {
.field_mode = FIELD_MODE_FIXED,
.field_size = 32, /* Field size is one dword */
.field_base = 96, /* Skip three dwords from the beginning */
};
struct rte_flow_item_udp spec0 = {
.hdr = {
.dst_port = RTE_BE16(0xFADE),
}
};
struct rte_flow_item_udp mask0 = {
.hdr = {
.dst_port = RTE_BE16(0xFFFF),
}
};
struct rte_flow_item_flex_link link0 = {
.item = {
.type = RTE_FLOW_ITEM_TYPE_UDP,
.spec = &spec0,
.mask = &mask0,
};

struct rte_flow_item_flex_conf conf = {
.next_header = {
.tunnel = FLEX_TUNNEL_MODE_SINGLE,
.field_mode = FIELD_MODE_OFFSET,
.field_base = 0,
.offset_base = 0,
.offset_mask = 0xFFFFFFFF,
.offset_shift = 2 /* Expressed in dwords, shift left by 2 */
},
.sample = {
&field0,
&field1,
},
.nb_samples = 2,
.input_link[0] = &link0,
.nb_inputs = 1
};

Let's suppose we have created the flex item successfully, and PMD
returned the handle 0x123456789A. We can use the following item
pattern to match the crucial field in the packet with value 0x00112233:

struct new_protocol_header spec_pattern =
{
.crucial = RTE_BE32(0x00112233),
};
struct new_protocol_header mask_pattern =
{
.crucial = RTE_BE32(0xFFFFFFFF),
};
struct rte_flow_item_flex spec_flex = {
.handle = 0x123456789A
.length = sizeiof(struct new_protocol_header),
.pattern = &spec_pattern,
};
struct rte_flow_item_flex mask_flex = {
.length = sizeof(struct new_protocol_header),
.pattern = &mask_pattern,
};
struct rte_flow_item item_to_match = {
.type = RTE_FLOW_ITEM_TYPE_FLEX,
.spec = &spec_flex,
.mask = &mask_flex,
};

Signed-off-by: Viacheslav Ovsiienko <[email protected]>
Acked-by: Ori Kam <[email protected]>

show more ...

ethdev: add experimental comment for modify field action

EXPERIMENTAL tag was missed in rte_flow_action_modify_data
structure description.

Fixes: 73b68f4c54a0 ("ethdev: introduce generic modify flo

ethdev: add experimental comment for modify field action

EXPERIMENTAL tag was missed in rte_flow_action_modify_data
structure description.

Fixes: 73b68f4c54a0 ("ethdev: introduce generic modify flow action")
Cc: [email protected]

Signed-off-by: Viacheslav Ovsiienko <[email protected]>
Acked-by: Ori Kam <[email protected]>
Acked-by: Andrew Rybchenko <[email protected]>

show more ...

ethdev: update modify field flow action

The generic modify field flow action introduced in [1] has
some issues related to the immediate source operand:

- immediate source can be presented either

ethdev: update modify field flow action

The generic modify field flow action introduced in [1] has
some issues related to the immediate source operand:

- immediate source can be presented either as an unsigned
64-bit integer or pointer to data pattern in memory.
There was no explicit pointer field defined in the union.

- the byte ordering for 64-bit integer was not specified.
Many fields have shorter lengths and byte ordering
is crucial.

- how the bit offset is applied to the immediate source
field was not defined and documented.

- 64-bit integer size is not enough to provide IPv6
addresses.

In order to cover the issues and exclude any ambiguities
the following is done:

- introduce the explicit pointer field
in rte_flow_action_modify_data structure

- replace the 64-bit unsigned integer with 16-byte array

- update the modify field flow action documentation

Appropriate deprecation notice has been removed.

[1] commit 73b68f4c54a0 ("ethdev: introduce generic modify flow action")

Signed-off-by: Viacheslav Ovsiienko <[email protected]>
Acked-by: Ori Kam <[email protected]>
Acked-by: Andrew Rybchenko <[email protected]>

show more ...

ethdev: query proxy port to manage transfer flows

Not all DPDK ports in a given switching domain may have the
privilege to manage "transfer" flows. Add an API to find a
port with sufficient privileg

ethdev: query proxy port to manage transfer flows

Not all DPDK ports in a given switching domain may have the
privilege to manage "transfer" flows. Add an API to find a
port with sufficient privileges by any port in the domain.

Signed-off-by: Ivan Malov <[email protected]>
Reviewed-by: Andrew Rybchenko <[email protected]>
Acked-by: Ori Kam <[email protected]>

show more ...

ethdev: deprecate direction attributes in transfer flows

Attributes "ingress" and "egress" can only apply unambiguosly
to non-"transfer" flows. In "transfer" flows, the standpoint
is effectively shi

ethdev: deprecate direction attributes in transfer flows

Attributes "ingress" and "egress" can only apply unambiguosly
to non-"transfer" flows. In "transfer" flows, the standpoint
is effectively shifted to the embedded switch. There can be
many different endpoints connected to the switch, so the
use of "ingress" / "egress" does not shed light on which
endpoints precisely can be considered as traffic sources.

Add relevant deprecation notices and suggest the use of precise
traffic source items (PORT_REPRESENTOR and REPRESENTED_PORT).

Signed-off-by: Ivan Malov <[email protected]>
Acked-by: Ori Kam <[email protected]>
Acked-by: Andrew Rybchenko <[email protected]>
Acked-by: Viacheslav Ovsiienko <[email protected]>

show more ...

ethdev: deprecate hard-to-use or ambiguous items and actions

PF, VF and PHY_PORT require that applications have extra
knowledge of the underlying NIC and thus are hard to use.
Also, the correspondin

ethdev: deprecate hard-to-use or ambiguous items and actions

PF, VF and PHY_PORT require that applications have extra
knowledge of the underlying NIC and thus are hard to use.
Also, the corresponding items depend on the direction
attribute (ingress / egress), which complicates their
use in applications and interpretation in PMDs.

The concept of PORT_ID is ambiguous as it doesn't say whether
the port in question is an ethdev or the represented entity.

Items and actions PORT_REPRESENTOR, REPRESENTED_PORT
should be used instead.

Signed-off-by: Ivan Malov <[email protected]>
Acked-by: Ori Kam <[email protected]>
Acked-by: Andrew Rybchenko <[email protected]>

show more ...

ethdev: add represented port action to flow API

For use in "transfer" flows. Supposed to send matching traffic to the
entity represented by the given ethdev, at embedded switch level.
Such an entity

ethdev: add represented port action to flow API

For use in "transfer" flows. Supposed to send matching traffic to the
entity represented by the given ethdev, at embedded switch level.
Such an entity can be a network (via a network port), a guest
machine (via a VF) or another ethdev in the same application.

Signed-off-by: Ivan Malov <[email protected]>
Acked-by: Ori Kam <[email protected]>
Acked-by: Andrew Rybchenko <[email protected]>

show more ...

ethdev: add port representor action to flow API

For use in "transfer" flows. Supposed to send matching traffic to
the given ethdev (to the application), at embedded switch level.

Signed-off-by: Iva

ethdev: add port representor action to flow API

For use in "transfer" flows. Supposed to send matching traffic to
the given ethdev (to the application), at embedded switch level.

Signed-off-by: Ivan Malov <[email protected]>
Acked-by: Ori Kam <[email protected]>
Acked-by: Andrew Rybchenko <[email protected]>

show more ...

ethdev: add represented port item to flow API

For use in "transfer" flows. Supposed to match traffic entering the
embedded switch from the entity represented by the given ethdev.
Such an entity can

ethdev: add represented port item to flow API

For use in "transfer" flows. Supposed to match traffic entering the
embedded switch from the entity represented by the given ethdev.
Such an entity can be a network (via a network port), a guest
machine (via a VF) or another ethdev in the same application.

Must not be combined with direction attributes.

Signed-off-by: Ivan Malov <[email protected]>
Acked-by: Ori Kam <[email protected]>
Acked-by: Andrew Rybchenko <[email protected]>

show more ...

ethdev: add port representor item to flow API

For use in "transfer" flows. Supposed to match traffic
entering the embedded switch from the given ethdev.

Must not be combined with direction attribut

ethdev: add port representor item to flow API

For use in "transfer" flows. Supposed to match traffic
entering the embedded switch from the given ethdev.

Must not be combined with direction attributes.

Signed-off-by: Ivan Malov <[email protected]>
Acked-by: Ori Kam <[email protected]>
Acked-by: Andrew Rybchenko <[email protected]>

show more ...