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 B957B425EF; Wed, 20 Sep 2023 12:00:45 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A6A4E41109; Wed, 20 Sep 2023 12:00:45 +0200 (CEST) Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) by mails.dpdk.org (Postfix) with ESMTP id F0B734027B for ; Wed, 20 Sep 2023 12:00:43 +0200 (CEST) Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-414b0bdea1cso40875181cf.1 for ; Wed, 20 Sep 2023 03:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695204043; x=1695808843; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Kabo6JYJ0FKlJwEGvcVElX5eXcp32e3rqsoQtJRLg6I=; b=kuTwB03qKI1XIoo+ypD+vV3wHpXaslPXGyijXLcvupDJ7GqNj9SrJ+qjd7GCYZ+/pR YR+vuQ6MfxW2obK/ejd4XhwgM3i4gZTgi0U0nZ2xwHhzb7hQ7dTKTdqOGdhy8ec6UXm9 yTTbtMbaz9DKieZXnUFDk6wbniMrWT/S7Vb9o4QNOrgWNdxst1iFhM/FvjDziV0j56Yu xNO2W/FbvFruW/VeqGX37npgfDjFnGGRX94WFosGIwUgX81AJovvJVGdbhCw6uMYpsFc owo/m6D29cGMckk7GYKWkSPMNOLI6gvnYNQDRQshrW20KcTo43t4nbYBUa4g1Q42+aZD KO9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695204043; x=1695808843; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Kabo6JYJ0FKlJwEGvcVElX5eXcp32e3rqsoQtJRLg6I=; b=YvDeU2yz4+6FrBw4pw/xCQbZSbcClPoKp7MufUmIsf/jb+prI3ajb5Eg558U6sGCxT 7PF8d4GYBMNbRaRF3zwBBqZT8FcExXSgttmDDnH8f1flPkq/fWAxImk9g0Vtp8B8NGBs fqXIp+cMY3vqb5ioUSbCIeMoSga3WNXGJeuy1n2ERnban3M/Ue1/Hyb+DWgcUID0XoxS oRamhnEwY/zgPKLAzCo7XlTMKBrbrae2VffDB/th3ls0gUD3BlL2Qld8g+vdb61xLA3u 5+XhkXo91uyxEzqtF9q1ed9JiuxoWHik2fcab0JDRpMNX3pmn1C6G+GWhtsxcJJazxog RgDA== X-Gm-Message-State: AOJu0YwIJUPBoizC2CGNyfdtt6QCmGY3MN6BiROzZgoHMRfILkp3MKfs Y1z+UBbgS9KXS3EW+S0g+TN9NKGYjAmkY9/vnUvPazfQ/dc= X-Google-Smtp-Source: AGHT+IHVPJjQz15OvVI2Wc2I1aW17Ydnym/coDIR/UvyhHpnO7q8wP19Fu/cRsIK61RVwcsCi5SzVA1RgIiUcvruoGQ= X-Received: by 2002:a05:622a:453:b0:412:1afe:f9f1 with SMTP id o19-20020a05622a045300b004121afef9f1mr1966854qtx.67.1695204043252; Wed, 20 Sep 2023 03:00:43 -0700 (PDT) MIME-Version: 1.0 References: <20230825233406.3647006-1-akozyrev@nvidia.com> <20230828182251.3917624-1-akozyrev@nvidia.com> In-Reply-To: <20230828182251.3917624-1-akozyrev@nvidia.com> From: Nithin Dabilpuram Date: Wed, 20 Sep 2023 15:30:31 +0530 Message-ID: Subject: Re: [PATCH v3] mbuf: add ESP packet type To: Alexander Kozyrev Cc: dev@dpdk.org, mb@smartsharesystems.com, orika@nvidia.com, olivier.matz@6wind.com, matan@nvidia.com, thomas@monjalon.net, Jerin Jacob , rbhansali@marvell.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 On Mon, Aug 28, 2023 at 11:53=E2=80=AFPM Alexander Kozyrev wrote: > > Support the IP Encapsulating Security Payload (ESP) in transport mode. As per IPSEC ESP RFC 4303, for both tunnel mode or transport mode, next proto 50, so we cannot identify a packet is for tunnel mode or transport mode by just packet parsing. Am I missing something ? > > Signed-off-by: Alexander Kozyrev > Acked-by: Morten Br=C3=B8rup > --- > lib/mbuf/rte_mbuf_ptype.h | 36 ++++++++++++++++++++++++++++++------ > 1 file changed, 30 insertions(+), 6 deletions(-) > > diff --git a/lib/mbuf/rte_mbuf_ptype.h b/lib/mbuf/rte_mbuf_ptype.h > index 17a2dd3576..cdd6fd460e 100644 > --- a/lib/mbuf/rte_mbuf_ptype.h > +++ b/lib/mbuf/rte_mbuf_ptype.h > @@ -247,7 +247,7 @@ extern "C" { > * It refers to those packets of any IP types, which can be recognized a= s > * fragmented. A fragmented packet cannot be recognized as any other L4 = types > * (RTE_PTYPE_L4_TCP, RTE_PTYPE_L4_UDP, RTE_PTYPE_L4_SCTP, RTE_PTYPE_L4_= ICMP, > - * RTE_PTYPE_L4_NONFRAG). > + * RTE_PTYPE_L4_NONFRAG, RTE_PTYPE_L4_IGMP, RTE_PTYPE_L4_ESP). > * > * Packet format: > * <'ether type'=3D0x0800 > @@ -290,14 +290,15 @@ extern "C" { > * > * It refers to those packets of any IP types, while cannot be recognize= d as > * any of above L4 types (RTE_PTYPE_L4_TCP, RTE_PTYPE_L4_UDP, > - * RTE_PTYPE_L4_FRAG, RTE_PTYPE_L4_SCTP, RTE_PTYPE_L4_ICMP). > + * RTE_PTYPE_L4_FRAG (for IPv6), RTE_PTYPE_L4_SCTP, RTE_PTYPE_L4_ICMP, > + * RTE_PTYPE_L4_IGMP (for IPv4), RTE_PTYPE_L4_ESP). > * > * Packet format: > * <'ether type'=3D0x0800 > - * | 'version'=3D4, 'protocol'!=3D[6|17|132|1], 'MF'=3D0, 'frag_offset'= =3D0> > + * | 'version'=3D4, 'protocol'!=3D[1|2|6|17|50|132], 'MF'=3D0, 'frag_off= set'=3D0> > * or, > * <'ether type'=3D0x86DD > - * | 'version'=3D6, 'next header'!=3D[6|17|44|132|1]> > + * | 'version'=3D6, 'next header'!=3D[1|6|17|44|50|132]> > */ > #define RTE_PTYPE_L4_NONFRAG 0x00000600 > /** > @@ -308,6 +309,17 @@ extern "C" { > * | 'version'=3D4, 'protocol'=3D2, 'MF'=3D0, 'frag_offset'=3D0> > */ > #define RTE_PTYPE_L4_IGMP 0x00000700 > +/** > + * ESP (IP Encapsulating Security Payload) transport packet type. > + * > + * Packet format: > + * <'ether type'=3D0x0800 > + * | 'version'=3D4, 'protocol'=3D50, 'MF'=3D0, 'frag_offset'=3D0> > + * or, > + * <'ether type'=3D0x86DD > + * | 'version'=3D6, 'next header'=3D50> > + */ > +#define RTE_PTYPE_L4_ESP 0x00000800 Currently there is already a PTYPE `RTE_PTYPE_TUNNEL_ESP` being used by all drivers / ipsec-secgw to indicate ESP packet. So why is this needed ? There is also a documentation issue with `RTE_PTYPE_TUNNEL_ESP` where it indicates next-proto of 51 but it should have been 50. next-proto of 51 is for IPSEC AH. > /** > * Mask of layer 4 packet types. > * It is used for outer packet for tunneling cases. > @@ -652,12 +664,24 @@ extern "C" { > * > * Packet format (inner only): > * <'ether type'=3D0x0800 > - * | 'version'=3D4, 'protocol'!=3D[6|17|132|1], 'MF'=3D0, 'frag_offset'= =3D0> > + * | 'version'=3D4, 'protocol'!=3D[1|6|17|50|132], 'MF'=3D0, 'frag_offse= t'=3D0> > * or, > * <'ether type'=3D0x86DD > - * | 'version'=3D6, 'next header'!=3D[6|17|44|132|1]> > + * | 'version'=3D6, 'next header'!=3D[1|6|17|44|50|132]> > */ > #define RTE_PTYPE_INNER_L4_NONFRAG 0x06000000 > +/** > + * ESP (IP Encapsulating Security Payload) transport packet type. > + * It is used for inner packet only. > + * > + * Packet format (inner only): > + * <'ether type'=3D0x0800 > + * | 'version'=3D4, 'protocol'=3D50, 'MF'=3D0, 'frag_offset'=3D0> > + * or, > + * <'ether type'=3D0x86DD > + * | 'version'=3D6, 'next header'=3D50> > + */ > +#define RTE_PTYPE_INNER_L4_ESP 0x08000000 > /** > * Mask of inner layer 4 packet types. > */ > -- > 2.18.2 >