ethdev: use IPv6 address structure in flows

Update rte_flow_tunnel, rte_flow_action_set_ipv6,
rte_flow_item_icmp6_nd_na and rte_flow_item_icmp6_nd_ns to use
rte_ipv6_addr structures instead of uint8

ethdev: use IPv6 address structure in flows

Update rte_flow_tunnel, rte_flow_action_set_ipv6,
rte_flow_item_icmp6_nd_na and rte_flow_item_icmp6_nd_ns to use
rte_ipv6_addr structures instead of uint8_t[16] arrays.

Signed-off-by: Robin Jarry <rjarry@redhat.com>

show more ...

net: use IPv6 address structure for packet headers

The rte_ipv6_hdr uses ad-hoc uint8_t[16] arrays to represent addresses.
Replace these arrays with the newly added rte_ipv6_addr structure. Adapt
al

net: use IPv6 address structure for packet headers

The rte_ipv6_hdr uses ad-hoc uint8_t[16] arrays to represent addresses.
Replace these arrays with the newly added rte_ipv6_addr structure. Adapt
all code accordingly.

Signed-off-by: Robin Jarry <rjarry@redhat.com>

show more ...

ethdev: convert string initialization

gcc 15 experimental [1], with -Wextra flag, gives warning in variable
initialization as string [2].

The warning has a point when initialized variable is intend

ethdev: convert string initialization

gcc 15 experimental [1], with -Wextra flag, gives warning in variable
initialization as string [2].

The warning has a point when initialized variable is intended to use as
string, since assignment is missing the required null terminator for
this case. But warning is useless for our usecase.

In this patch only updated a few instance to show the issue, there are
many instances to fix, if we prefer to go this way.
Other option is to disable warning but it can be useful for actual
string usecases, so I prefer to keep it.

Converted string initialization to array initialization.

[1]
gcc (GCC) 15.0.0 20241003 (experimental)

[2]
../lib/ethdev/rte_flow.h:906:36:
error: initializer-string for array of ‘unsigned char’ is too long
[-Werror=unterminated-string-initialization]
906 | .hdr.dst_addr.addr_bytes = "\xff\xff\xff\xff\xff\xff",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~

../lib/ethdev/rte_flow.h:907:36:
error: initializer-string for array of ‘unsigned char’ is too long
[-Werror=unterminated-string-initialization]
907 | .hdr.src_addr.addr_bytes = "\xff\xff\xff\xff\xff\xff",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~

../lib/ethdev/rte_flow.h:1009:25:
error: initializer-string for array of ‘unsigned char’ is too long
[-Werror=unterminated-string-initialization]
1009 | "\xff\xff\xff\xff\xff\xff\xff\xff"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

../lib/ethdev/rte_flow.h:1012:25:
error: initializer-string for array of ‘unsigned char’ is too long
[-Werror=unterminated-string-initialization]
1012 | "\xff\xff\xff\xff\xff\xff\xff\xff"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

../lib/ethdev/rte_flow.h:1135:20:
error: initializer-string for array of ‘unsigned char’ is too long
[-Werror=unterminated-string-initialization]
1135 | .hdr.vni = "\xff\xff\xff",
| ^~~~~~~~~~~~~~

Signed-off-by: Ferruh Yigit <ferruh.yigit@amd.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Dariusz Sosnowski <dsosnowski@nvidia.com>

show more ...

ethdev: add jump to table index action

Introduce the RTE_FLOW_ACTION_TYPE_JUMP_TO_TABLE_INDEX action.
It redirects packets to a particular index in a flow table.

testpmd example:
flow queue 0 creat

ethdev: add jump to table index action

Introduce the RTE_FLOW_ACTION_TYPE_JUMP_TO_TABLE_INDEX action.
It redirects packets to a particular index in a flow table.

testpmd example:
flow queue 0 create 0 template_table 0 pattern_template 0
actions_template 0 postpone no pattern eth / end
actions jump_to_table_index table 0x166f9ce00 index 5 / end

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

show more ...

ethdev: add flow rule by index with pattern

Add a new API to enqueue flow rule creation by index with pattern.
The new template table rules insertion type,
index-based insertion with pattern, requir

ethdev: add flow rule by index with pattern

Add a new API to enqueue flow rule creation by index with pattern.
The new template table rules insertion type,
index-based insertion with pattern, requires a new flow rule creation
function with both rule index and pattern provided.
Packets will match on the provided pattern at the provided index.

In testpmd, allow to specify both the rule index and the pattern
in the flow rule creation command line parameters.
Both are needed for rte_flow_async_create_by_index_with_pattern().

flow queue 0 create 0 template_table 2 rule_index 5
pattern_template 0 actions_template 0 postpone no pattern eth / end
actions count / queue index 1 / end

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

show more ...

ethdev: add flow rule insertion mode by index with pattern

There are two flow table rules insertion type today:
pattern-based insertion when packets match on the pattern and
index-based insertion wh

ethdev: add flow rule insertion mode by index with pattern

There are two flow table rules insertion type today:
pattern-based insertion when packets match on the pattern and
index-based insertion when packets always hit at the index.
We need another mode that allows to match on the pattern at
the index: insertion by index with pattern.

testpmd example:
flow template_table 0 create table_id 2 group 13 priority 0
insertion_type index_with_pattern ingress rules_number 64
pattern_template 2 actions_template 2

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

show more ...

ethdev: support duplicating only item mask

Extend rte_flow_conv() to support working only on item's mask.
This allows drivers to get only the mask's size when working on pattern
templates and duplic

ethdev: support duplicating only item mask

Extend rte_flow_conv() to support working only on item's mask.
This allows drivers to get only the mask's size when working on pattern
templates and duplicate items having only the mask in a generic way.

Signed-off-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>

show more ...

net: extend VXLAN header to support more extensions

VXLAN and VXLAN-GPE were supported with similar header structures.
In order to add VXLAN-GBP, which is another extension to VXLAN, both
extensions

net: extend VXLAN header to support more extensions

VXLAN and VXLAN-GPE were supported with similar header structures.
In order to add VXLAN-GBP, which is another extension to VXLAN, both
extensions are merged in the original VXLAN header structure for an easier
usage. More VXLAN extensions may be added in the future in the same single
structure.

VXLAN and VXLAN-GBP use the same UDP port (4789), while VXLAN-GPE uses a
different port (4790).
The three protocols have the same header length and overall a similar
header structure as below.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|R|R|I|R|R|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: VXLAN Header

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|Ver|I|P|B|O| Reserved |Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: VXLAN-GPE Header

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|R|R|R|I|R|R|R|R|D|R|R|A|R|R|R| Group Policy ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: VXLAN-GBP Extension

Both GPE and GBP are extending VXLAN by using some reserved bits.
It means the packets can be processed with the same pattern and most of
the code can be reused.

The old field names are kept with the use of anonymous unions.
The Group Policy ID (GBP) and the Next Protocol (GPE) fields are
overlapping so they are in a union as well.

Another improvement is defining and documenting each bit.

Instead of adding flow items, a single VXLAN flow item is more flexible
as it uses the same header anyway.
GBP can be matches with the G bit.
GPE can be matched with the UDP port number.

VXLAN-GPE flow item and specific header are marked as deprecated.
A removal of the deprecated structures and macros may be proposed later.

Signed-off-by: Gavin Li <gavinl@nvidia.com>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>

show more ...

ethdev: add VXLAN last reserved field

Add "uint8_t last_rsvd" as union with origin rsvd1.
Add RTE_FLOW_FIELD_VXLAN_LAST_RSVD into rte flow packet
field.

The new union is used by testpmd matching it

ethdev: add VXLAN last reserved field

Add "uint8_t last_rsvd" as union with origin rsvd1.
Add RTE_FLOW_FIELD_VXLAN_LAST_RSVD into rte flow packet
field.

The new union is used by testpmd matching item VXLAN
"last_rsvd" and modify target RTE_FLOW_FIELD_VXLAN_LAST_RSVD.

Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
Acked-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>

show more ...

ethdev: allow modifying IPv6 FL and TC fields

Add new "rte_flow_field_id" enumeration values to describe both IPv6
traffic class and IPv6 flow label fields.

The TC value is "RTE_FLOW_FIELD_IPV6_TRA

ethdev: allow modifying IPv6 FL and TC fields

Add new "rte_flow_field_id" enumeration values to describe both IPv6
traffic class and IPv6 flow label fields.

The TC value is "RTE_FLOW_FIELD_IPV6_TRAFFIC_CLASS" in flow API and
"ipv6_traffic_class" in testpmd command.
The FL value is "RTE_FLOW_FIELD_IPV6_FLOW_LABEL" in flow API and
"ipv6_flow_label" in testpmd command.

Signed-off-by: Michael Baum <michaelba@nvidia.com>
Acked-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>

show more ...

ethdev: allow modifying IPsec fields

The following IPsec related field definitions added:

- RTE_FLOW_FIELD_ESP_SPI - SPI value in IPsec header
- RTE_FLOW_FIELD_ESP_SEQ_NUM - sequence number in he

ethdev: allow modifying IPsec fields

The following IPsec related field definitions added:

- RTE_FLOW_FIELD_ESP_SPI - SPI value in IPsec header
- RTE_FLOW_FIELD_ESP_SEQ_NUM - sequence number in header
- RTE_FLOW_FIELD_ESP_PROTO - next protocol value in trailer

Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Acked-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>

show more ...

ethdev: allow modifying IPv4 next protocol field

Add IPv4 next protocol modify field definition.

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

ethdev: allow modifying IPv4 next protocol field

Add IPv4 next protocol modify field definition.

Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>

show more ...

ethdev: add template table resize

Template table creation API sets table flows capacity.
If application needs more flows then the table was designed for,
the following procedures must be completed:

ethdev: add template table resize

Template table creation API sets table flows capacity.
If application needs more flows then the table was designed for,
the following procedures must be completed:
1. Create a new template table with larger flows capacity.
2. Re-create existing flows in the new table and delete flows from
the original table.
3. Destroy original table.

Application cannot always execute that procedure:
* Port may not have sufficient resources to allocate a new table
while maintaining original table.
* Application may not have existing flows "recipes" to re-create
flows in a new table.

The patch defines a new API that allows application to resize
existing template table:

* Resizable template table must be created with the
RTE_FLOW_TABLE_SPECIALIZE_RESIZABLE_TABLE bit set.

* Application resizes existing table with the
`rte_flow_template_table_resize()` function call.
The table resize procedure updates the table maximal flow number
only. Other table attributes are not affected by the table resize.
** The table resize procedure must not interrupt
existing table flows operations in hardware.
** The table resize procedure must not alter flow handles held by
application.

* After `rte_flow_template_table_resize()` returned, application must
update table flow rules by calling
`rte_flow_async_update_resized()`.
The call reconfigures internal flow resources for the new table
configuration.
The flow update must not interrupt hardware flow operations.

* After table flows were updated, application must call
`rte_flow_template_table_resize_complete()`.
The function releases PMD resources related to the original
table.
Application can start new table resize after
`rte_flow_template_table_resize_complete()` returned.

Testpmd commands:

* Create resizable template table
flow template_table <port-id> create table_id <tbl-id> resizable \
[transfer|ingress|egres] group <group-id> \
rules_number <initial table capacity> \
pattern_template <pt1> [ pattern_template <pt2> [ ... ]] \
actions_template <at1> [ actions_template <at2> [ ... ]]

* Resize table:
flow template_table <tbl-id> resize table_resize_id <tbl-id> \
table_resize_rules_num <new table capacity>

* Queue a flow update:
flow queue <port-id> update_resized <tbl-id> rule <flow-id>

* Complete table resize:
flow template_table <port-id> resize_complete table <tbl-id>

Signed-off-by: Gregory Etelson <getelson@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>

show more ...

ethdev: add encapsulation hash calculation

During encapsulation of a packet, it is possible to change some
outer headers to improve flow distribution.
For example, from VXLAN RFC:
"It is recommended

ethdev: add encapsulation hash calculation

During encapsulation of a packet, it is possible to change some
outer headers to improve flow distribution.
For example, from VXLAN RFC:
"It is recommended that the UDP source port number
be calculated using a hash of fields from the inner packet --
one example being a hash of the inner Ethernet frame's headers.
This is to enable a level of entropy for the ECMP/load-balancing"

The tunnel protocol defines which outer field should hold this hash,
but it doesn't define the hash calculation algorithm.

An application that uses flow offloads gets the first few packets
(exception path) and then decides to offload the flow.
As a result, there are two different paths that a packet from a given
flow may take. SW for the first few packets or HW for the rest.
When the packet goes through the SW, the SW encapsulates the packet
and must use the same hash calculation as the HW will do for
the rest of the packets in this flow.

The new function rte_flow_calc_encap_hash can query the hash value
from the driver for a given packet as if the packet was passed
through the HW.

Testpmd command:
flow hash {port} encap {target field}
pattern {item} [/ {item} [...] ] / end

Testpmd example for VXLAN encapsulation:
flow hash 0 encap hash_field_sport
pattern ipv4 dst is 7.7.7.7 src is 8.8.8.8 /
udp dst is 5678 src is 1234 / end

Signed-off-by: Ori Kam <orika@nvidia.com>
Acked-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>

show more ...

ethdev: add flow item for comparison

The new item type is added for the case user wants to match traffic
based on packet field compare result with other fields or immediate
value.

e.g. take advanta

ethdev: add flow item for comparison

The new item type is added for the case user wants to match traffic
based on packet field compare result with other fields or immediate
value.

e.g. take advantage the compare item user will be able to accumulate
a IPv4/TCP packet's TCP data_offset and IPv4 IHL field to a tag
register, then compare the tag register with IPv4 header total length
to understand the packet has payload or not.

The supported operations can be as below:
- RTE_FLOW_ITEM_COMPARE_EQ (equal)
- RTE_FLOW_ITEM_COMPARE_NE (not equal)
- RTE_FLOW_ITEM_COMPARE_LT (less than)
- RTE_FLOW_ITEM_COMPARE_LE (less than or equal)
- RTE_FLOW_ITEM_COMPARE_GT (great than)
- RTE_FLOW_ITEM_COMPARE_GE (great than or equal)

A sample for create the comparison flow:
flow pattern_template 0 create ingress pattern_template_id 1 template \
compare op mask le a_type mask tag a_tag_index mask 1 b_type \
mask tag b_tag_index mask 2 width mask 0xffffffff / end
flow actions_template 0 create ingress actions_template_id 1 template \
count / drop / end mask count / drop / end
flow template_table 0 create table_id 1 group 2 priority 1 ingress \
rules_number 1 pattern_template 1 actions_template 1
flow queue 0 create 0 template_table 1 pattern_template 0 \
actions_template 0 postpone no pattern compare op is le \
a_type is tag a_tag_index is 1 b_type is tag b_tag_index is 2 \
width is 32 / end actions count / drop / end

Signed-off-by: Suanming Mou <suanmingm@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>

show more ...

ethdev: move flow field data structure

As flow field relevant data structures will be used by both actions and
items, this commit moves the relevant data structures up to item parts.

Signed-off-by:

ethdev: move flow field data structure

As flow field relevant data structures will be used by both actions and
items, this commit moves the relevant data structures up to item parts.

Signed-off-by: Suanming Mou <suanmingm@nvidia.com>
Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>

show more ...

ethdev: rename flow field data structure

Current rte_flow_action_modify_data struct describes the pkt
field perfectly and is used only in action.

It is planned to be used for item as well. This com

ethdev: rename flow field data structure

Current rte_flow_action_modify_data struct describes the pkt
field perfectly and is used only in action.

It is planned to be used for item as well. This commit renames
it to "rte_flow_field_data" making it compatible to be used by item.

Signed-off-by: Suanming Mou <suanmingm@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>

show more ...

ethdev: add NAT64 flow action

In order to support the communication between IPv4 and IPv6 nodes in
the network, different technologies are used, like dual-stacks,
tunneling and NAT64. In some IPv4-o

ethdev: add NAT64 flow action

In order to support the communication between IPv4 and IPv6 nodes in
the network, different technologies are used, like dual-stacks,
tunneling and NAT64. In some IPv4-only clients, it is hard to deploy
new software and(or) hardware to support IPv6 protocol.

NAT64 is a choice and it will also reduce the unnecessary overhead of
the traffic in the network. The NAT64 gateways take the
responsibility of the packet headers translation between the IPv6
clouds and IPv4-only clouds.

The commit introduce the NAT64 flow action to offload the software
involvement to the hardware.

This action should support the offloading of the IP headers'
translation. The following fields should be reset correctly in the
translation.
- Version
- Traffic Class / TOS
- Flow Label (0 in v4)
- Payload Length / Total length
- Next Header
- Hop Limit / TTL

The PMD needs to support the basic conversion of the fields above,
and the well-known prefix will be used when translating IPv4 address
to IPv6 address. Another modify fields can be used after the NAT64 to
support other modes with different prefix and offset.

The ICMP* and transport layers protocol is out of the scope of NAT64
rte_flow action.

Testpmd usage example with flow template API:
...
flow actions_template 0 create ingress actions_template_id 1 \
template count / nat64 / jump / end mask count / nat64 / \
jump / end
flow template_table 0 create group 1 priority 0 ingress table_id \
0x1 rules_number 8 pattern_template 0 actions_template 1
flow queue 0 create 2 template_table 0x1 pattern_template 0 \
actions_template 0 postpone no pattern eth / end actions count / \
nat64 type 1 / jump group 2 / end
...

Reference links:
- https://datatracker.ietf.org/doc/html/rfc6146
- https://datatracker.ietf.org/doc/html/rfc6052
- https://datatracker.ietf.org/doc/html/rfc6145

Signed-off-by: Bing Zhao <bingz@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>

show more ...

ethdev: add flow item for random matching

Add support for a new item type "RTE_FLOW_ITEM_TYPE_RANDOM".
This item enables to match on some random value as a part of flow rule.

Example in testpmd:

ethdev: add flow item for random matching

Add support for a new item type "RTE_FLOW_ITEM_TYPE_RANDOM".
This item enables to match on some random value as a part of flow rule.

Example in testpmd:

pattern random spec value 0x1 mask value 0x3 / eth / end

Flow rule with above pattern matching 25% of the traffic, it hits only
when random value suffix is "01" and miss the others ("00", "10", "11").

Signed-off-by: Michael Baum <michaelba@nvidia.com>
Acked-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>

show more ...

ethdev: fix NVGRE encap flow action description

Fix incorrect definition of 'NVGRE_ENCAP', and
modified the error comments of 'rte_flow_action_nvgre_encap'.

Fixes: c2beb1d469d2 ("ethdev: add missin

ethdev: fix NVGRE encap flow action description

Fix incorrect definition of 'NVGRE_ENCAP', and
modified the error comments of 'rte_flow_action_nvgre_encap'.

Fixes: c2beb1d469d2 ("ethdev: add missing items/actions to flow object converter")
Fixes: 3850cf0c8c37 ("ethdev: add tunnel encap/decap actions")
Cc: stable@dpdk.org

Signed-off-by: Joey Xing <joey.xing@jaguarmicro.com>
Signed-off-by: Sunyang Wu <sunyang.wu@jaguarmicro.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>

show more ...

lib: replace logging helpers

This is a preparation step before the next change.

Many libraries have their own logging helpers that do not add a newline
in their format string.
Some previous changes

lib: replace logging helpers

This is a preparation step before the next change.

Many libraries have their own logging helpers that do not add a newline
in their format string.
Some previous changes fixed places where some of those helpers are
called without a trailing newline.
Using RTE_LOG_LINE in the existing helpers will ensure we don't
introduce new issues in the future.

The problem is that if we simply convert to the RTE_LOG_LINE helper,
a future fix may introduce a regression since the logging helper
change won't be backported.

To address this concern, rename existing helpers: backporting a call to
them will trigger some conflict or build issue in LTS branches.

Note:
- bpf and vhost that still has some debug multilines messages, a direct
call to RTE_LOG/RTE_LOG_DP is used: this will make it easier to notice
such special cases,
- about previously publicly exposed logging helpers, when such helper is
not publicly used (iow in public inline API), it is removed from the
public API (this is the case for the member library),

Signed-off-by: David Marchand <david.marchand@redhat.com>
Reviewed-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>

show more ...

ethdev: set and query RSS hash algorithm

Currently, rte_eth_rss_conf supports configuring and querying
RSS hash functions, rss key and it's length, but not RSS hash
algorithm.

The structure ``rte_e

ethdev: set and query RSS hash algorithm

Currently, rte_eth_rss_conf supports configuring and querying
RSS hash functions, rss key and it's length, but not RSS hash
algorithm.

The structure ``rte_eth_dev_info`` is extended by adding a new
field "rss_algo_capa". Drivers are responsible for reporting this
capa and configurations of RSS hash algorithm can be verified based
on the capability. The default value of "rss_algo_capa" is
RTE_ETH_HASH_ALGO_CAPA_MASK(DEFAULT) if drivers do not report it.

The structure ``rte_eth_rss_conf`` is extended by adding a new
field "algorithm". This represents the RSS algorithms to apply.
If the value of "algorithm" used for configuration is a gibberish
value, drivers should report the error.

To check whether the drivers report valid "algorithm", it is set
to default value before querying in rte_eth_dev_rss_hash_conf_get().

Signed-off-by: Jie Hai <haijie1@huawei.com>
Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
Acked-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@amd.com>

show more ...

ethdev: clarify RSS related fields usage

In rte_eth_dev_rss_hash_conf_get(), the "rss_key_len" should be
greater than or equal to the "hash_key_size" which get from
rte_eth_dev_info_get() API. And t

ethdev: clarify RSS related fields usage

In rte_eth_dev_rss_hash_conf_get(), the "rss_key_len" should be
greater than or equal to the "hash_key_size" which get from
rte_eth_dev_info_get() API. And the "rss_key" should contain at
least "hash_key_size" bytes. If these requirements are not met,
the query unreliable.

In rte_eth_dev_rss_hash_update() or rte_eth_dev_configure(), the
"rss_key_len" indicates the length of the "rss_key" in bytes of
the array pointed by "rss_key", it should be equal to the
"hash_key_size" if "rss_key" is not NULL.

This patch overwrites the comments of fields of "rte_eth_rss_conf"
and "RTE_ETH_HASH_FUNCTION_DEFAULT", checks "rss_key_len" in
ethdev level, and documents these changes.

Signed-off-by: Jie Hai <haijie1@huawei.com>
Acked-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@amd.com>

show more ...

ethdev: fix flow share indirect flag

Fix value of RTE_FLOW_PORT_FLAG_SHARE_INDIRECT.

Fixes: f5b2846d89d7 ("ethdev: share indirect action between ports")
Cc: stable@dpdk.org

Signed-off-by: Gregory

ethdev: fix flow share indirect flag

Fix value of RTE_FLOW_PORT_FLAG_SHARE_INDIRECT.

Fixes: f5b2846d89d7 ("ethdev: share indirect action between ports")
Cc: stable@dpdk.org

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

show more ...

net/mlx5: extend send to kernel action support

The send to kernel action was supported in NIC and FDB tables,
Currently, the send to kernel action is created in NIC RX only.

With some TC rules (exa

net/mlx5: extend send to kernel action support

The send to kernel action was supported in NIC and FDB tables,
Currently, the send to kernel action is created in NIC RX only.

With some TC rules (example: roce packets, redirects into rep ports)
and DPDK rules for the rest of the traffic. Then it needs the
specific rule to re-route the packets into the kernel through the FDB
table.

This patch adds the FDB and NIC-TX tables support for sending to the kernel
action.

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

show more ...