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 <dek...@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.