| 045e35aa | 10-Oct-2024 |
James Hershaw <james.hershaw@corigine.com> |
app/testpmd: support switching LED on/off
Add command to change the state of a controllable LED on an ethdev port
to on/off. This is for the purpose of identifying which physical port is
associated
app/testpmd: support switching LED on/off
Add command to change the state of a controllable LED on an ethdev port
to on/off. This is for the purpose of identifying which physical port is
associated with an ethdev.
Usage:
testpmd> set port <port-id> led <on/off>
Signed-off-by: James Hershaw <james.hershaw@corigine.com>
Reviewed-by: Chaoyong He <chaoyong.he@corigine.com>
Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>
show more ...
|
| 99231e48 | 15-Feb-2024 |
Gregory Etelson <getelson@nvidia.com> |
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 ...
|
| 9733f099 | 13-Feb-2024 |
Ori Kam <orika@nvidia.com> |
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 ...
|
| eb704df7 | 31-Jan-2024 |
Bing Zhao <bingz@nvidia.com> |
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 ...
|