From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id EBD237E75 for ; Wed, 12 Nov 2014 18:16:30 +0100 (CET) Received: by mail-wg0-f41.google.com with SMTP id k14so14761121wgh.28 for ; Wed, 12 Nov 2014 09:26:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=l4okDTVQTEqYG5uc8USxU/dtl4bAoIaZKu+LNPWOFHE=; b=iZPMIYVwPkVuNQkkMWHJDbOoUc1v9U3ZwEprAxyWhJV5/vuDGBK0G9CqD3Zkqho/R9 glAvEqpORxOAztAyQdKVLqUQ5XZxesFSF+evie9fMcUeiSuC5X3vN0aYyLbwFiozlbtk KdcZBpw9xoKjvsod6zLtA9C36rg2Ib4byBOic5xJvnyVzw8bKXwMc5BWPQb9mVW7DdWj Lo11VS5+MvGCdELdxBTYDdNsO2ZCpKbe/80UFf2fA5pkFGwhAAwLCRLdnATVBaoxIQpf nRQVDCDD5DFnDVtF5lpdh6PMhUVX6XLfFltctgOmlAc7pB61mfmw5uopQPFlfg12LWkg h4ag== X-Gm-Message-State: ALoCoQnmFppmlO5kLuWVmapAhikWODqOrL362QWKbFulAjCYWM98EWVptcmK2yrA1GWCpX6MJWaJ X-Received: by 10.180.187.143 with SMTP id fs15mr43829573wic.55.1415813185953; Wed, 12 Nov 2014 09:26:25 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id lp14sm20470123wic.20.2014.11.12.09.26.24 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Nov 2014 09:26:25 -0800 (PST) From: Thomas Monjalon To: "Liu, Jijiang" Date: Wed, 12 Nov 2014 18:26:07 +0100 Message-ID: <176980123.CbUgamS8oi@xps13> Organization: 6WIND User-Agent: KMail/4.14.2 (Linux/3.17.2-1-ARCH; KDE/4.14.2; x86_64; ; ) In-Reply-To: <1ED644BD7E0A5F4091CF203DAFB8E4CC01D8F7A7@SHSMSX101.ccr.corp.intel.com> References: <1414376006-31402-1-git-send-email-jijiang.liu@intel.com> <5460E512.1050609@6wind.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01D8F7A7@SHSMSX101.ccr.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v8 10/10] app/testpmd:test VxLAN Tx checksum offload X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 17:16:31 -0000 2014-11-11 05:29, Liu, Jijiang: > From: Olivier MATZ > > On 11/10/2014 07:03 AM, Liu, Jijiang wrote: > > > > - if PKT_TX_VXLAN_CKSUM is not set (legacy use case), then the > > > > driver use l2_len and l3_len to offload inner IP/UDP/TCP checksums. > > > > > > If the flag is not set, and imply that it is not VXLAN packet, and do > > > TX checksum offload as regular packet. > > > > > > > - if PKT_TX_VXLAN_CKSUM is set, then the driver has to use > > > > inner_l{23}_len instead of l{23}_len for the same operation. > > > > > > Your understanding is not fully correct. > > > The l{23}_len is still used for TX checksum offload, please refer to > > > i40e_txd_enable_checksum() implementation. > > > > This fields are part of public mbuf API. You cannot say to refer to i40e PMD code > > to understand how to use it. > > > > > > Adding PKT_TX_VXLAN_CKSUM changes the semantic of l2_len and l3_len. > > > > To fix this, I suggest to remove the new fields inner_l{23}_len then > > > > add outer_l{23}_len instead. Therefore, the semantic of l2_len and > > > > l3_len would not change, and a driver would always use the same field for a > > > > specific offload. > > > > > > Oh... > > > > Does it mean you agree? > > I don't agree to change inner_l{23}_len the name. > The reason is that using the "inner" word means incoming packet is tunneling packet or encapsulation packet. > if we add "outer"{2,3}_len, which will cause confusion when processing non-tunneling packet. Sorry Jijiang, maybe I don't understand what you are saying, but I think you missed something. Let me explain the problem. For PKT_TX_IP_CKSUM, we must set l{2,3}_len. When PKT_TX_VXLAN_CKSUM is set, PKT_TX_IP_CKSUM is related to inner IP, right? So we must set inner_l{2,3}_len. It means that PKT_TX_IP_CKSUM requires different fields to be set, depending of PKT_TX_VXLAN_CKSUM. That's what Olivier calls a semantic change. It's not acceptable for an API. PKT_TX_IP_CKSUM should always be related to l{2,3}_len. When PKT_TX_VXLAN_CKSUM is set, we should add outer_l{2,3}_len. Please, correct me if I'm wrong or fix the API. Thanks -- Thomas