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 1AF1CA00C3; Wed, 21 Sep 2022 20:46:10 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F14E140691; Wed, 21 Sep 2022 20:46:09 +0200 (CEST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id 74D294067C for ; Wed, 21 Sep 2022 20:46:09 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id D36C95C00E3; Wed, 21 Sep 2022 14:46:07 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 21 Sep 2022 14:46:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1663785967; x= 1663872367; bh=F5OoJjJPv87NZsJ/mvCraavz/e6aTgR22j/DXj467wc=; b=E 4+PRK9eA0qcHB8L5G6BgWcD58BY66C1TQgFTrCUeQhRA3x7f9gXVcZUwtldmxgMS ybzpRt7OmEmYqatzwFL0sZ8mEe3xWFLhqele1ATH7Wnae7huBcGwZkqJfZnqqkJe tkyPIpyQLF5UW2aqL+b6sehr3w7EpbKDGXXU4fkm3LlMcSo1x2iY+VMJsIkPj+Q/ nmXVLxYDexfVSNkzcAHGZEKq2SjzxJ4SwsuWwSeezJSM0zNWnP4PxXK9AjCxg+DO t43+JNFHtOQ85zv8+LA6GcQI+lV3m1IrujjNKa3pSNhOFXonfvDystXmT//3uFEn 8d5byyRdUNiD5n7ZOWKGA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1663785967; x= 1663872367; bh=F5OoJjJPv87NZsJ/mvCraavz/e6aTgR22j/DXj467wc=; b=Z jV0idCZ9axDPpXK6fp+aB/w4qgK50YVvXDaI/hplcMX9NakzyxHIBajQ1aEH7EzJ vgd3smO6HReHZtsvitrGFL7lKmKD8HqFvcahFKJfaubxfbYWVxmt9+tup1ftjxGd +v77nDvafDxbaSqlgqe2W0m4j9iKwEi8tZcef5spul5sbHSc0LVbKMo4OWlTRVKx uZ/QSDpF4KmA0OXwsjv4/sPzZisjDkjIbvowQkm57Q6h5X+k7d5aF1i94/w2CZ2F 6fivPpj2Ntw/DqNYWWQWWnEhN0HApyB8EZ/gDSCDa98BsCvpKfgmMSVbsUqb5Qf6 xbwWB4wKKUs0anCN2b1dg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeefuddgudeftdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhho mhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqne cuggftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddt ieekgfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 21 Sep 2022 14:46:06 -0400 (EDT) From: Thomas Monjalon To: Nithin Kumar Dabilpuram , Olivier Matz , "Ananyev, Konstantin" , Akhil Goyal Cc: Jerin Jacob Kollanukkaran , "dev@dpdk.org" , "ruifeng.wang@arm.com" Subject: Re: [PATCH v3 1/5] mbuf: clarify meta data needed for Outbound Inline Date: Wed, 21 Sep 2022 20:46:03 +0200 Message-ID: <1695610.QkHrqEjB74@thomas> In-Reply-To: References: <20220707072921.13448-1-ndabilpuram@marvell.com> <93c8eb1c-a15c-27ec-140e-55a30cca1a87@marvell.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 21/09/2022 20:21, Akhil Goyal: > > Ping. Any thoughts on this ? > > > > This is just clarification of existing assumptions for Inline Outbound > > that are being made. > > > > > > On 2022-08-22 8:08 PM, Nithin Dabilpuram wrote: > > > Clarify mbuf meta data needed for Outbound Inline processing. > > > Application needs to provide mbuf.l3_len and L3 type in > > > mbuf.ol_flags so that like tunnel mode using mbuf.l2_len, transport mode > > > can make use of l3_len and l3_type to determine perform > > > proper transport mode IPsec processing. > > > > > > Signed-off-by: Nithin Dabilpuram > > Series > Acked-by: Akhil Goyal > > @Thomas : Can this series be merged into crypto tree? > > Any objections? That's all about crypto, so that's perfectly fine to merge in crypto tree.