Re: [dpdk-dev] [RFC] ethdev: add fragment attribute to IPv6 item

[Andrew Rybchenko <arybchenko@solarflare.com>]

On 5/31/20 5:43 PM, Dekel Peled wrote:
> Using the current implementation of DPDK, an application cannot
> match on fragmented/non-fragmented IPv6 packets in a simple way.
> 
> In current implementation:
> IPv6 header doesn't contain information regarding the packet
> fragmentation.
> Fragmented IPv6 packets contain a dedicated extension header, as
> detailed in RFC [1], which is not yet supported in rte_flow.
> Non-fragmented packets don't contain the fragment extension header.
> For an application to match on non-fragmented IPv6 packets, the
> current implementation doesn't provide a suitable solution.
> Matching on the Next Header field is not sufficient, since additional
> extension headers might be present in the same packet.
> To match on fragmented IPv6 packets, the same difficulty exists.
> 
> Proposed update:
> An additional value will be added to IPv6 header struct.
> This value will contain the fragmentation attribute of the packet,
> providing simple means for identification of fragmented and
> non-fragmented packets.
> 
> This update changes ABI, and is proposed for the 20.11 LTS version.
> 
> [1] http://mails.dpdk.org/archives/dev/2020-March/160255.html
> 
> Signed-off-by: Dekel Peled <dekelp@mellanox.com>
> ---
>  lib/librte_ethdev/rte_flow.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> index b0e4199..3bc8ce1 100644
> --- a/lib/librte_ethdev/rte_flow.h
> +++ b/lib/librte_ethdev/rte_flow.h
> @@ -787,6 +787,8 @@ struct rte_flow_item_ipv4 {
>   */
>  struct rte_flow_item_ipv6 {
>  	struct rte_ipv6_hdr hdr; /**< IPv6 header definition. */
> +	uint32_t is_frag:1; /**< Is IPv6 packet fragmented/non-fragmented. */
> +	uint32_t reserved:31; /**< Reserved, must be zero. */

The solution is simple, but hardly generic and adds an
example for the future extensions. I doubt that it is a
right way to go.

May be we should add 256-bit string with one bit for each
IP protocol number and apply it to extension headers only?
If bit A is set in the mask:
 - if bit A is set in spec as well, extension header with
   IP protocol (1 << A) number must present
 - if bit A is clear in spec, extension header with
   IP protocol (1 << A) number must absent
If bit is clear in the mask, corresponding extension header
may present and may absent (i.e. don't care).

The RFC indirectly touches IPv6 proto (next header) matching
logic.

If logic used in ETH+VLAN is applied on IPv6 as well, it would
make pattern specification and handling complicated. E.g.:
  eth / ipv6 / udp / end
should match UDP over IPv6 without any extension headers only.

And how to specify UPD over IPv6 regardless extension headers?
  eth / ipv6 / ipv6_ext / udp / end
with a convention that ipv6_ext is optional if spec and mask
are NULL (or mask is empty).

I'm wondering if any driver treats it this way?

I agree that the problem really comes when we'd like match
IPv6 frags or even worse not fragments.

Two patterns for fragments:
  eth / ipv6 (proto=FRAGMENT) / end
  eth / ipv6 / ipv6_ext (next_hdr=FRAGMENT) / end

Any sensible solution for not-fragments with any other
extension headers?

INVERT exists, but hardly useful, since it simply says
that patches which do not match pattern without INVERT
matches the pattern with INVERT and
  invert / eth / ipv6 (proto=FRAGMENT) / end
will match ARP, IPv4, IPv6 with an extension header before
fragment header and so on.

Bit string suggested above will allow to match:
 - UDP over IPv6 with any extension headers:
    eth / ipv6 (ext_hdrs mask empty) / udp / end
 - UDP over IPv6 without any extension headers:
    eth / ipv6 (ext_hdrs mask full, spec empty) / udp / end
 - UDP over IPv6 without fragment header:
    eth / ipv6 (ext.spec & ~FRAGMENT, ext.mask | FRAGMENT) / udp / end
 - UDP over IPv6 with fragment header
    eth / ipv6 (ext.spec | FRAGMENT, ext.mask | FRAGMENT) / udp / end

where FRAGMENT is 1 << IPPROTO_FRAGMENT.

Above I intentionally keep 'proto' unspecified in ipv6
since otherwise it would specify the next header after IPv6
header.

Extension headers mask should be empty by default.

Andrew.