From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 0C37E1B178 for ; Sat, 6 Oct 2018 00:45:29 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 13A1621964; Fri, 5 Oct 2018 18:44:57 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 05 Oct 2018 18:44:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=nn4fbh1bw7Z3S5R+9URjtB1ym+VBI7oezkClRgW7EFE=; b=T6THBZykWfyg LVWUim7Cz0iRIK6MUqpmEZRejQOU274IpO9C8ifhaeS6zJkJMS8pX1pOHH5Ghs6X VLGoyB/RJfsYvF0WX+3txMGseYU+3wOTrVl9Tt81Ie/VShyWZf3exrpKRVqu6ATi hKrGZFgaHw9TLKfgEBa3VpZbH/6iXHc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=nn4fbh1bw7Z3S5R+9URjtB1ym+VBI7oezkClRgW7E FE=; b=ncYz86SsuFuej+2fjl648phLVA+4DgDKF2bt/pXE/VW2sl0FJQPX0n5h1 vMtseohGpmTwaKrnXQ7pqA7pi0ItnGDe6UxIjC3WG5sNvdTEJgcYl3W1PDmkkIdr gxTcR/7sgrsr6O3uohMhwYMhkVRaD6x58gfxtqsNWlPL2qEoWP5TwZ5ah8yfo0qP Rr1rOJjgs+2FN8iRLHFs4bHqvfXmxJwvkN+XP/P0LzN6LQ9ms5SSuP9HYXCFzopd CX77yMC8091miPtIyqqLaQIOfkokwj9WkykAalWoDC3rR6DkdyOHhxqNMaeUOuay r9JXXXu3gjEZg+AQVVDxXNBHiVDjQ== X-ME-Sender: X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id AEE7F102D7; Fri, 5 Oct 2018 18:44:54 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit , Jerin Jacob , Andrew Rybchenko Cc: Wenzhuo Lu , Jingjing Wu , Bernard Iremonger , John McNamara , Marko Kovacevic , Olivier Matz , dev@dpdk.org, shahafs@mellanox.com, "Ananyev, Konstantin" , didier.pallard@6wind.com Date: Sat, 06 Oct 2018 00:44:52 +0200 Message-ID: <26087815.IDbtF1NTBH@xps> In-Reply-To: References: <20180913134707.23698-1-jerin.jacob@caviumnetworks.com> <20181004055930.GA4406@jerin> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 1/4] ethdev: add Rx offload outer UDP checksum definition 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: , X-List-Received-Date: Fri, 05 Oct 2018 22:45:29 -0000 05/10/2018 22:04, Ferruh Yigit: > On 10/4/2018 6:59 AM, Jerin Jacob wrote: > > From: Andrew Rybchenko > >> On 03.10.2018 21:14, Jerin Jacob wrote: > >>> From: Andrew Rybchenko > >>>> On 03.10.2018 20:12, Jerin Jacob wrote: > >>>>> From: Jerin Jacob > >>>>>> From: Andrew Rybchenko > >>>>>>> 3. PKT_RX_L4_CKSUM_MASK description says nothing if it is inner or outer. > >>>>>>> May be it is not directly related to changeset, but I think it would be really > >>>>>>> useful to clarify it. > >>>>>> I will update the comment. > >>>>> Hi Andrew, > >>>>> > >>>>> I looked at the other definitions in mbuf.h, according the documentation, > >>>>> If nothing is mentioned it is treated as inner if the packet is > >>>>> tunneled else it is outer most. So I would like avoid confusion by > >>>>> adding "inner" in the exiting PKT_RX_L4_CKSUM_MASK comment. > >>>>> Technically it is not correct to say "inner" if the packet is not > >>>>> tunneled. So I am untouching the exiting comment. > >>>>> > >>>> Yes, it is incorrect to say that it is inner. How does application find > >>>> how to treat PKT_RX_L4_CKSUM (inner or outer)? > >>>> Should it rely on packet type provided in mbuf? > >>> AFAIK, Finding is it a tunneled packet or not is through ptype or SW has > >>> to parse the packet. For example, testpmd chooses later method using > >>> "csum parse-tunnel on " to detect the presence of the tunnel. > >> > >> SW parsing of the packet cannot help, since app should be sure > >> that HW has classified the packet as tunneled and provided information > >> about inner and outer checksum checks. > > > > > > I thought the question was, How does the application find how to treat > > PKT_RX_L4_CKSUM (inner or outer)? > > Obviously, ptype will help here > > Not sure why SW parsing won't help here if SW parses and find it is an > > inner packet or it is not a tunneled packet. PKT_RX_L4_CKSUM treat as > > inner checksum for former case and PKT_RX_L4_CKSUM treated as plain l4 > > checksum in the latter case. > > I don't know if PKT_RX_L4_CKSUM is inner or outer with current design, > but wouldn't be easier if PKT_RX_L4_CKSUM always refer to outer and if tunneled > use something like PKT_RX_INNER_L4_CKSUM, same for IP and TX. The return of the come back of the "inner vs outer" discussion :-) There were some thoughts about what is the most convenient for apps doing decapsulation of tunnels. I think the decision was to choose inner as the default, while outer must be explicited. Honestly, we should not try to change again the meaning of symbols having no outer/inner word in their name, except if we have a very very good reason and arguments. And for new symbols, we must follow the community decision. However, we should re-visit the flag PKT_RX_EIP_CKSUM_BAD.