From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by dpdk.org (Postfix) with ESMTP id 1A493595B for ; Thu, 13 Nov 2014 10:00:25 +0100 (CET) Received: by mail-wi0-f172.google.com with SMTP id bs8so7517510wib.17 for ; Thu, 13 Nov 2014 01:10:23 -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=lZw2v8nJPhy4OeDJZ89XclxUzUafcEF6xxoZqDgdCd8=; b=kZcAf2ijG9krnCvO8z0osIB7r5r9MJ5R+CSTAvQeBOcwPIJAJjXsfCQq7H4UHoVlur Jfm0bXq5qr72g8m4+nKtAHDz5GG/aApKcZcK6BwuXpawm97Buqq0UjOkIXgSeMbJhsLx sD9R6A0cziiTalt2FpdE5yM4hyMj4+1TRgbecGF7gDCNzkRQOI0sP9MpYakDxq9OZLpW Kom5loN1P1F3cIXrWao6vH8rnRTrJ6I83BIKP8KOHz+XmTqYoDD87vxVMdq1oBst+QOT +N5Y6MhGRAAlUGyOYlwcMnL+LWPkK4r6YJlFt2Vpj5Aoy9H35hekOkCpnfNaA1gaOboo DeGQ== X-Gm-Message-State: ALoCoQlYxyzDMCO/6vsSGOBe6G0uTQsze8USQHAAS/hqSREybUq/kVqz4TiPcvZHNp9y6Hrtpl2F X-Received: by 10.194.93.168 with SMTP id cv8mr1961772wjb.114.1415869823010; Thu, 13 Nov 2014 01:10:23 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id t9sm34675112wjf.41.2014.11.13.01.10.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Nov 2014 01:10:22 -0800 (PST) From: Thomas Monjalon To: "Liu, Jijiang" Date: Thu, 13 Nov 2014 10:10:04 +0100 Message-ID: <3175184.TxKMqZeb6U@xps13> Organization: 6WIND User-Agent: KMail/4.14.2 (Linux/3.17.2-1-ARCH; KDE/4.14.2; x86_64; ; ) In-Reply-To: <1ED644BD7E0A5F4091CF203DAFB8E4CC01D992F8@SHSMSX101.ccr.corp.intel.com> References: <1414376006-31402-1-git-send-email-jijiang.liu@intel.com> <176980123.CbUgamS8oi@xps13> <1ED644BD7E0A5F4091CF203DAFB8E4CC01D992F8@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: Thu, 13 Nov 2014 09:00:25 -0000 2014-11-13 06:51, Liu, Jijiang: > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > 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. > > I'd like to explain what PKT_TX_VXLAN_CKSUM means, it is to tell driver > should set whole VXLAN packet TX checksum according to L3/L4 flag setting. > VXLAN packet IP checksum not only include inner IP, but also include outer > IP, so when PKT_TX_VXLAN_CKSUM is set, the PKT_TX_IP_CKSUM is not only > related to inner IP, but also IP. In other words, we use this one flag to > set inner IP and outer IP checksum offload at the same time in driver, > because it is not necessary to add other flag to stand for inner IP flag You mean that PKT_TX_VXLAN_CKSUM request hardware checksumming of outer L3, outer L4, inner L3 and inner L4? So maybe the name and comments are not enough clear. > L4 flag usage is the same the L3 flag as well. What do you mean? > > 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. > > Probably we can refer to struct sk_buff in Linux kernel . > Just as a reference!! > struct sk_buff { > ... > * @inner_protocol: Protocol (encapsulation) > * @inner_transport_header: Inner transport layer header (encapsulation) > * @inner_network_header: Network layer header (encapsulation) > * @inner_mac_header: Link layer header (encapsulation) > > __u16 inner_transport_header; > __u16 inner_network_header; > __u16 inner_mac_header; > __u16 transport_header; > __u16 network_header; > __u16 mac_header; Yes it's a reference. But some things are made differently in DPDK. Is there a flag PKT_TX_VXLAN_CKSUM in Linux? I'm not sure what the checksumming API would be. But I'm sure the VXLAN API is not enough commented. Olivier is improving documentation of the legacy checksum API: http://dpdk.org/ml/archives/dev/2014-November/007956.html I'd like you do the same thing for VXLAN checksum. Thanks -- Thomas