From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6E691A0579; Thu, 8 Apr 2021 13:10:10 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 38D5640698; Thu, 8 Apr 2021 13:10:10 +0200 (CEST) Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) by mails.dpdk.org (Postfix) with ESMTP id 8F25740138 for ; Thu, 8 Apr 2021 13:10:08 +0200 (CEST) Received: by mail-wm1-f46.google.com with SMTP id y20-20020a1c4b140000b029011f294095d3so2698665wma.3 for ; Thu, 08 Apr 2021 04:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=i8lzU/1SC4ILk4RgiDAKqnKuTndjtbfI4l4pgsW3PtI=; b=FdJTLYoh40wgJGFb2m3IDzlxb+Kc6OqrpK4z6cRyVX3iXZWTR8gAbYXFxSHjmpciAq wVo8uLL0YaQLaSjx35ohovbGZMvEKB25IR9EvAI9DEL970pvOScDzKMUcx8wlOWJuqiK TcuLDAxAeculoIl8I0NZEQiYq+uQc7NXGtWArsSn58VO3dcs3yzJLs9nVpYoXdYwRun3 DERmDZxELEMIEhzOACUZ67DczDrxIQVyO0239PGKswavBBVYOTLXlH8dt30444TEW0VF 0pjrbpDPUyZvy9k2p6hW3GuO8FvWFktu740e1dZqIW0I4ETPaOMPU0OuQIpQsj96/F6j RADA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=i8lzU/1SC4ILk4RgiDAKqnKuTndjtbfI4l4pgsW3PtI=; b=ZDihAwxyDCUMqEkOlA8j26azQsCn2nA8PnxoZX2iHc4qtunn9Ty0eppoU8V1Udbw5n nPBVb0xc+xZUHYsiI4a4VMan7o+75BFPrkfdyEghvN0YXkl1PO7R4/aT4gWfwJRGZuYx LO/cktcnDTeq1DNUj9q+sGQohuMotSOHmapXoX/XYbfZf9Or8Ztd/VwvRkyT6eguy2D4 irejKlaOrPGFUzzWgqmM8Q53nm0lDLNdgyoeFWdr1+FoVJkbu13tLl3lFLdNx0VbwxDK E0S2c6T0352mP0aai5Wdqtnh/A2vALwHOaTBr1a/8EDt0+LKe+Y6svytHepLKDCEZaO3 WlXw== X-Gm-Message-State: AOAM530f4cIDSTGB5kC9g+DxyvikE24yOD/P9eNYyEXx5WanK0qn6nWa dUs9uh2+ryqY0d87q0VtY3gorQ== X-Google-Smtp-Source: ABdhPJzHJ/QBYjBbHz06grLTohR6uHPeLfXa2TB+QxF/3o8fMefzku+SIuZzOYr8QyrKsDxSuz4DOw== X-Received: by 2002:a1c:7f14:: with SMTP id a20mr7878959wmd.55.1617880208260; Thu, 08 Apr 2021 04:10:08 -0700 (PDT) Received: from 6wind.com ([2a01:e0a:5ac:6460:c065:401d:87eb:9b25]) by smtp.gmail.com with ESMTPSA id v189sm13935532wme.39.2021.04.08.04.10.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Apr 2021 04:10:07 -0700 (PDT) Date: Thu, 8 Apr 2021 13:10:07 +0200 From: Olivier Matz To: Tejasree Kondoj Cc: Akhil Goyal , Radu Nicolau , Konstantin Ananyev , Anoob Joseph , Ankur Dwivedi , Jerin Jacob , dev@dpdk.org Message-ID: <20210408111007.GT1650@platinum> References: <20210408081720.23314-1-ktejasree@marvell.com> <20210408081720.23314-3-ktejasree@marvell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210408081720.23314-3-ktejasree@marvell.com> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-dev] [PATCH v3 2/4] mbuf: add packet type for UDP-ESP tunnel packets X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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 Thu, Apr 08, 2021 at 01:47:18PM +0530, Tejasree Kondoj wrote: > Adding new mbuf packet type for UDP encapsulated > ESP packets. > > Signed-off-by: Tejasree Kondoj > --- > doc/guides/rel_notes/release_21_05.rst | 5 +++++ > lib/librte_mbuf/rte_mbuf_ptype.h | 21 +++++++++++++++++++++ > 2 files changed, 26 insertions(+) > > diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst > index 5565c7637c..c9e9e2ec22 100644 > --- a/doc/guides/rel_notes/release_21_05.rst > +++ b/doc/guides/rel_notes/release_21_05.rst > @@ -55,6 +55,11 @@ New Features > Also, make sure to start the actual text at the margin. > ======================================================= > > +* **Added new packet type for UDP-ESP packets in mbuf.** > + > + Added new packet type ``RTE_PTYPE_TUNNEL_ESP_IN_UDP`` which can be > + used to identify UDP encapsulated ESP packets. > + > * **Enhanced ethdev representor syntax.** > > * Introduced representor type of VF, SF and PF. > diff --git a/lib/librte_mbuf/rte_mbuf_ptype.h b/lib/librte_mbuf/rte_mbuf_ptype.h > index 17a2dd3576..bf92ce0c1a 100644 > --- a/lib/librte_mbuf/rte_mbuf_ptype.h > +++ b/lib/librte_mbuf/rte_mbuf_ptype.h > @@ -491,6 +491,27 @@ extern "C" { > * | 'destination port'=6635> > */ > #define RTE_PTYPE_TUNNEL_MPLS_IN_UDP 0x0000d000 > +/** > + * ESP-in-UDP tunneling packet type (RFC 3948). > + * > + * Packet format: > + * <'ether type'=0x0800 > + * | 'version'=4, 'protocol'=17 > + * | 'destination port'=4500> > + * or, > + * <'ether type'=0x86DD > + * | 'version'=6, 'next header'=17 > + * | 'destination port'=4500> > + * or, > + * <'ether type'=0x0800 > + * | 'version'=4, 'protocol'=17 > + * | 'source port'=4500> > + * or, > + * <'ether type'=0x86DD > + * | 'version'=6, 'next header'=17 > + * | 'source port'=4500> > + */ > +#define RTE_PTYPE_TUNNEL_ESP_IN_UDP 0x0000e000 > /** > * Mask of tunneling packet types. > */ We arrive at the end of the values in packet type tunnel types, and there is another pending patch that needs another tunnel type. As there is already a RTE_PTYPE_TUNNEL_ESP, what would you think about trying to reuse it, and differentiate IP/ESP from IP/UDP/ESP by using the L4 layer type (unknown vs udp)? Or maybe add RTE_PTYPE_L4_NONE. It is sensible, because it can be considered as an API change for current users of RTE_PTYPE_TUNNEL_ESP. I don't really know how this type is used by applications. I think it is time to start thinking about how the packet_type mbuf API can evolve to solve this issue. By the way, the update of *rte_get_ptype_tunnel_name() is missing.