From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0F9AAA04BC; Wed, 7 Oct 2020 01:44:09 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B0E7025B3; Wed, 7 Oct 2020 01:44:06 +0200 (CEST) Received: from mail-ot1-f65.google.com (mail-ot1-f65.google.com [209.85.210.65]) by dpdk.org (Postfix) with ESMTP id F1A0611A4 for ; Wed, 7 Oct 2020 01:44:04 +0200 (CEST) Received: by mail-ot1-f65.google.com with SMTP id m11so505134otk.13 for ; Tue, 06 Oct 2020 16:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=P9+nTwGqArwHXyddNUSTLvb9gcRdRtCRxsFPtk2xIWA=; b=PY5pu9grOuOLOTCC7/crzrPeILMlF/oK4b9HHQQp8d0W3eTM2nV8PtCQSf8d2x6dv3 chPNM4brrBE4VMpM/+BEoN8NouAWuAgcEV8nmOd3rdpRb1Ti0rkJQm4rIbLHmztiwaSv F42yikL3eJltdtUVLI3AoQmPxbonRICD/Ep8E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=P9+nTwGqArwHXyddNUSTLvb9gcRdRtCRxsFPtk2xIWA=; b=OpBe4Fp2Y5uTmIlsA6apc6ftChNjYGzOdMkAHYGpwCBi3XtlUISZIf630pyLHbtuIo 0qYAwtJp9FaWI5gVWwIxs3KZ/3W1g39T1ptiZvqKUIh6zDHEWqT6KSuGUHH4OCszBray xaEY9KjdCZTPnG0xt4plHSxZWYrgPrBJZeDmBdl2VrsBPwcxrLHa7DtztpFbv9mzk+e4 suRZ+JFn6SwHwqKvJNBpVLSSvG+MrJlamxIO7Q5Bbm95flLYAQ5yfcpuEr6MdQhGDp2d Z7pNsS8fuQBBZjcPtL/oefD772eyC5dBH5Zrbb1XjdDpOFCM7nhbZnb5JKBrw9/n4VVV CCkQ== X-Gm-Message-State: AOAM533M04c7kffjVJbVVNEotwHsFGVK8tbtCTRi6+IAnQMqriUlA397 0th3NWkcc/0tt5/XRlWjRnkO920v1IkWVy3FjpwWZQ== X-Google-Smtp-Source: ABdhPJwdtzy6nFbJA6ojUAmVcZYmaCzQZzOJCcHVFU/Qg1x+J47rjiXDWkpOjBjRMGTJ3oAdwRj98CdkymBdxyKjpRw= X-Received: by 2002:a9d:5509:: with SMTP id l9mr260556oth.154.1602027842977; Tue, 06 Oct 2020 16:44:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ajit Khaparde Date: Tue, 6 Oct 2020 16:43:46 -0700 Message-ID: To: Dekel Peled Cc: Ori Kam , Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko , "Ananyev, Konstantin" , Olivier Matz , Wenzhuo Lu , Beilei Xing , "Iremonger, Bernard" , Matan Azrad , Shahaf Shuler , Slava Ovsiienko , dpdk-dev Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v3 01/11] ethdev: add extensions attributes to IPv6 item X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Mon, Oct 5, 2020 at 1:37 AM Dekel Peled 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 > Acked-by: Ori Kam > --- > 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. > > - ``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 >