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 670DBA04BC; Thu, 8 Oct 2020 20:29:13 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E49A21B6F3; Thu, 8 Oct 2020 20:29:10 +0200 (CEST) Received: from mail-ot1-f67.google.com (mail-ot1-f67.google.com [209.85.210.67]) by dpdk.org (Postfix) with ESMTP id B81B51B65F for ; Thu, 8 Oct 2020 20:29:09 +0200 (CEST) Received: by mail-ot1-f67.google.com with SMTP id 60so6481800otw.3 for ; Thu, 08 Oct 2020 11:29:09 -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=mLxPgV465HCJk3USdKl81ojMCtBSLTJLYYv7BMcf+D0=; b=UMPgQ5mKbCNHKnXoyiW+qcBnIqdCzxwc42kq6cFdT7ENoEm+S6GxOuKA8E3MCPXVV/ cfRwc6Ol5/J+g0oScAKfjgQT8lj3x1E3DWLZitQmXng8ogvLoZGzQf2h2s8YESjr0RHD LcRyPYMuPT3YuPqklUEnyAbInjoO/1ETtqw+E= 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=mLxPgV465HCJk3USdKl81ojMCtBSLTJLYYv7BMcf+D0=; b=mH7UXkvSCPMgX+2rSQ7xetip1Vbz9nw0m4PB70/2knkzi4H1T/vHP0am0nPb+rBODQ TOq7Zun/9yCMOvzZBXcO3uZK2jqNN6VTnNorCB8iU+AoggK4XoPdkEGnJ9jufx1ln4/D 2o4ABCrr0xAot2CUFNw3cJW+li3swxA4MNg5UZsBQ0nPPn5P82yj94JCNdJgrNauUY8H ymRi9DbNRsHhjcgrGHgHHtpEqgn1Vnn0LwuouwzQV6CrPvd5Sw64JSrYXjYZj/nGNNaQ cJeO7DHv4SMOhCr6bP6SiXdz8jSGxvS/vCc+vGk3zCI7YAn9qhHhMX+VWJaWfOh+Za5Y QBFw== X-Gm-Message-State: AOAM532QnJN6iTW+Pz1oku7LRi/8BeDwWG4H7IP9pW+yC9HIuc7Kpc+0 u397Fl5LjHbRkkuuQt4tLQ1xxxLdl4wIgYC9YLkjHg== X-Google-Smtp-Source: ABdhPJw7NnrgRA4yBDr1QrF3a6g+mJZVheniyhuLDruC22e2jOHYZiA6IbtkQQz2ETjPFfb5qX7hJ5CqunwCZdhJxqY= X-Received: by 2002:a9d:6acc:: with SMTP id m12mr5614078otq.95.1602181747739; Thu, 08 Oct 2020 11:29:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ajit Khaparde Date: Thu, 8 Oct 2020 11:28:51 -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 v4 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 Wed, Oct 7, 2020 at 3:55 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. > To match on non-fragmented IPv6 packets, need to use frag_ext_exist 0. > To match on fragmented IPv6 packets, need to use frag_ext_exist 1. > To match on any IPv6 packets, the frag_ext_exist field should > not be specified for match. > > [1] https://mails.dpdk.org/archives/dev/2020-August/177257.html > > Signed-off-by: Dekel Peled > Acked-by: Ori Kam Acked-by: Ajit Khaparde > --- > doc/guides/prog_guide/rte_flow.rst | 22 +++++++++++++++++++--- > lib/librte_ethdev/rte_flow.h | 25 +++++++++++++++++++++++-- > 2 files changed, 42 insertions(+), 5 deletions(-) > > diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst > index 119b128..ae090db 100644 > --- a/doc/guides/prog_guide/rte_flow.rst > +++ b/doc/guides/prog_guide/rte_flow.rst > @@ -946,11 +946,27 @@ 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`_. > +To match on packets containing a specific extension header, an application > +should match on the dedicated flag set to 1. > +To match on packets not containing a specific extension header, an application > +should match on the dedicated flag clear to 0. > +In case application doesn't care about the existence of a specific extension > +header, it should not specify the dedicated flag for matching. > > - ``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 >