Thanks, PSB.
> -----Original Message-----
> From: Ajit Khaparde <ajit.khapa...@broadcom.com>
> Sent: Wednesday, October 7, 2020 2:44 AM
> To: Dekel Peled <dek...@nvidia.com>
> Cc: Ori Kam <or...@nvidia.com>; NBU-Contact-Thomas Monjalon
> <tho...@monjalon.net>; Ferruh Yigit <ferruh.yi...@intel.com>; Andrew
> Rybchenko <arybche...@solarflare.com>; Ananyev, Konstantin
> <konstantin.anan...@intel.com>; Olivier Matz <olivier.m...@6wind.com>;
> Wenzhuo Lu <wenzhuo...@intel.com>; Beilei Xing <beilei.x...@intel.com>;
> Iremonger, Bernard <bernard.iremon...@intel.com>; Matan Azrad
> <ma...@nvidia.com>; Shahaf Shuler <shah...@nvidia.com>; Slava
> Ovsiienko <viachesl...@nvidia.com>; dpdk-dev <dev@dpdk.org>
> Subject: Re: [dpdk-dev] [PATCH v3 01/11] ethdev: add extensions attributes
> to IPv6 item
>
> On Mon, Oct 5, 2020 at 1:37 AM Dekel Peled <dek...@nvidia.com> wrote:
> >
> > Using the current implementation of DPDK, an application cannot match on
> > IPv6 packets, based on the existing extension headers, in a simple way.
> >
> > Field 'Next Header' in IPv6 header indicates type of the first extension
> > header only. Following extension headers can't be identified by
> > inspecting the IPv6 header.
> > As a result, the existence or absence of specific extension headers
> > can't be used for packet matching.
> >
> > For example, fragmented IPv6 packets contain a dedicated extension
> header
> > (which is implemented in a later patch of this series).
> > 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.
> >
> > This patch implements the update as detailed in RFC [1].
> > A set of additional values will be added to IPv6 header struct.
> > These values will indicate the existence of every defined extension
> > header type, providing simple means for identification of existing
> > extensions in the packet header.
> > Continuing the above example, fragmented packets can be identified using
> > the specific value indicating existence of fragment extension header.
> >
> > [1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
> >
> > Signed-off-by: Dekel Peled <dek...@nvidia.com>
> > Acked-by: Ori Kam <or...@nvidia.com>
> > ---
> > doc/guides/prog_guide/rte_flow.rst | 16 +++++++++++++---
> > lib/librte_ethdev/rte_flow.h | 25 +++++++++++++++++++++++--
> > 2 files changed, 36 insertions(+), 5 deletions(-)
> >
> > diff --git a/doc/guides/prog_guide/rte_flow.rst
> b/doc/guides/prog_guide/rte_flow.rst
> > index 119b128..0b476da 100644
> > --- a/doc/guides/prog_guide/rte_flow.rst
> > +++ b/doc/guides/prog_guide/rte_flow.rst
> > @@ -946,11 +946,21 @@ Item: ``IPV6``
> >
> > Matches an IPv6 header.
> >
> > -Note: IPv6 options are handled by dedicated pattern items, see `Item:
> > -IPV6_EXT`_.
> > +Dedicated flags indicate existence of specific extension headers.
> > +Every type of extension header can use a dedicated pattern item, or
> > +the generic `Item: IPV6_EXT`_.
>
> Can you add how the PMD should interpret if these flags are not set
> by the application.
> There is a mention of some of that in the testpmd commit log.
> I think it is good to spell it out here.
Agree, I will add it in the git log for next version.
>
> >
> > - ``hdr``: IPv6 header definition (``rte_ip.h``).
> > -- Default ``mask`` matches source and destination addresses only.
> > +- ``hop_ext_exist``: Hop-by-Hop Options extension header exists.
> > +- ``rout_ext_exist``: Routing extension header exists.
> > +- ``frag_ext_exist``: Fragment extension header exists.
> > +- ``auth_ext_exist``: Authentication extension header exists.
> > +- ``esp_ext_exist``: Encapsulation Security Payload extension header
> exists.
> > +- ``dest_ext_exist``: Destination Options extension header exists.
> > +- ``mobil_ext_exist``: Mobility extension header exists.
> > +- ``hip_ext_exist``: Host Identity Protocol extension header exists.
> > +- ``shim6_ext_exist``: Shim6 Protocol extension header exists.
> > +- Default ``mask`` matches ``hdr`` source and destination addresses only.
> >
> > Item: ``ICMP``
> > ^^^^^^^^^^^^^^
> > diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> > index da8bfa5..5b5bed2 100644
> > --- a/lib/librte_ethdev/rte_flow.h
> > +++ b/lib/librte_ethdev/rte_flow.h
> > @@ -792,11 +792,32 @@ struct rte_flow_item_ipv4 {
> > *
> > * Matches an IPv6 header.
> > *
> > - * Note: IPv6 options are handled by dedicated pattern items, see
> > - * RTE_FLOW_ITEM_TYPE_IPV6_EXT.
> > + * Dedicated flags indicate existence of specific extension headers.
> > + * Every type of extension header can use a dedicated pattern item, or
> > + * the generic item RTE_FLOW_ITEM_TYPE_IPV6_EXT.
> > */
> > struct rte_flow_item_ipv6 {
> > struct rte_ipv6_hdr hdr; /**< IPv6 header definition. */
> > + uint32_t hop_ext_exist:1;
> > + /**< Hop-by-Hop Options extension header exists. */
> > + uint32_t rout_ext_exist:1;
> > + /**< Routing extension header exists. */
> > + uint32_t frag_ext_exist:1;
> > + /**< Fragment extension header exists. */
> > + uint32_t auth_ext_exist:1;
> > + /**< Authentication extension header exists. */
> > + uint32_t esp_ext_exist:1;
> > + /**< Encapsulation Security Payload extension header exists. */
> > + uint32_t dest_ext_exist:1;
> > + /**< Destination Options extension header exists. */
> > + uint32_t mobil_ext_exist:1;
> > + /**< Mobility extension header exists. */
> > + uint32_t hip_ext_exist:1;
> > + /**< Host Identity Protocol extension header exists. */
> > + uint32_t shim6_ext_exist:1;
> > + /**< Shim6 Protocol extension header exists. */
> > + uint32_t reserved:23;
> > + /**< Reserved for future extension headers, must be zero. */
> > };
> >
> > /** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */
> > --
> > 1.8.3.1
> >
