From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [PATCH v2 1/4] ethdev: add Rx offload outer UDP
	checksum definition
Date: Sat, 06 Oct 2018 00:44:52 +0200
Message-ID: <26087815.IDbtF1NTBH@xps>
References: <20180913134707.23698-1-jerin.jacob@caviumnetworks.com>
 <20181004055930.GA4406@jerin>
 <c304808d-32d1-26e5-d3b7-88e79c4512c3@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: Wenzhuo Lu <wenzhuo.lu@intel.com>, Jingjing Wu <jingjing.wu@intel.com>,
 Bernard Iremonger <bernard.iremonger@intel.com>,
 John McNamara <john.mcnamara@intel.com>,
 Marko Kovacevic <marko.kovacevic@intel.com>,
 Olivier Matz <olivier.matz@6wind.com>, dev@dpdk.org, shahafs@mellanox.com,
 "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, didier.pallard@6wind.com
To: Ferruh Yigit <ferruh.yigit@intel.com>,
 Jerin Jacob <jerin.jacob@caviumnetworks.com>,
 Andrew Rybchenko <arybchenko@solarflare.com>
Return-path: <dev-bounces@dpdk.org>
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com
 [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 0C37E1B178
 for <dev@dpdk.org>; Sat,  6 Oct 2018 00:45:29 +0200 (CEST)
In-Reply-To: <c304808d-32d1-26e5-d3b7-88e79c4512c3@intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

05/10/2018 22:04, Ferruh Yigit:
> On 10/4/2018 6:59 AM, Jerin Jacob wrote:
> > From: Andrew Rybchenko <arybchenko@solarflare.com>
> >> On 03.10.2018 21:14, Jerin Jacob wrote:
> >>> From: Andrew Rybchenko <arybchenko@solarflare.com>
> >>>> On 03.10.2018 20:12, Jerin Jacob wrote:
> >>>>> From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> >>>>>> From: Andrew Rybchenko <arybchenko@solarflare.com>
> >>>>>>> 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 <port>" 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.