Re: [dpdk-dev] [PATCH v4 1/3] ethdev: introduce conntrack flow action and item

[Ori Kam <orika@nvidia.com>]

> -----Original Message-----
> From: Bing Zhao <bingz@nvidia.com>
> Sent: Monday, April 19, 2021 8:17 PM
> Subject: [PATCH v4 1/3] ethdev: introduce conntrack flow action and item
> 
> This commit introduces the conntrack action and item.
> 
> Usually the HW offloading is stateless. For some stateful offloading
> like a TCP connection, HW module will help provide the ability of a
> full offloading w/o SW participation after the connection was
> established.
> 
> The basic usage is that in the first flow rule the application should
> add the conntrack action and jump to the next flow table. In the
> following flow rule(s) of the next table, the application should use
> the conntrack item to match on the result.
> 
> A TCP connection has two directions traffic. To set a conntrack
> action context correctly, the information of packets from both
> directions are required.
> 
> The conntrack action should be created on one ethdev port and supply
> the peer ethdev port as a parameter to the action. After context
> created, it could only be used between these two ethdev ports
> (dual-port mode) or a single port. The application should modify the
> action via the API "rte_action_handle_update" only when before using
> it to create a flow rule with conntrack for the opposite direction.
> This will help the driver to recognize the direction of the flow to
> be created, especially in the single-port mode, in which case the
> traffic from both directions will go through the same ethdev port
> if the application works as an "forwarding engine" but not an end
> point. There is no need to call the update interface if the
> subsequent flow rules have nothing to be changed.
> 
> Query will be supported via "rte_action_handle_query" interface,
> about the current packets information and connection status. The
> fields query capabilities depends on the HW.
> 
> For the packets received during the conntrack setup, it is suggested
> to re-inject the packets in order to make sure the conntrack module
> works correctly without missing any packet. Only the valid packets
> should pass the conntrack, packets with invalid TCP information,
> like out of window, or with invalid header, like malformed, should
> not pass.
> 
> Naming and definition:
> https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/
>         netfilter/nf_conntrack_tcp.h
> https://elixir.bootlin.com/linux/latest/source/net/netfilter/
>         nf_conntrack_proto_tcp.c
> 
> Other reference:
> https://www.usenix.org/legacy/events/sec01/invitedtalks/rooij.pdf
> 
> Signed-off-by: Bing Zhao <bingz@nvidia.com>
> ---

Acked-by: Ori Kam <orika@nvidia.com>
Thanks,
Ori