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 324965A1F for ; Wed, 21 Jan 2015 16:25:12 +0100 (CET) Received: by mail-wg0-f41.google.com with SMTP id a1so18349367wgh.0 for ; Wed, 21 Jan 2015 07:25:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=X1rgPV9puv6A9y4hcxLk9uUgiuhKAKYw88t+uK2hlFw=; b=QMCjGw7sSu9HHeiTO0mcPc3tW0AWQos8UAmK/q3ihrzQCHA0py7/ZgsycYvAo+l4Vd UqVhvcj325RsmxdXj2l1u0phpxdLJOGyKAVKsdcUHQCY8m6hiKI5oDB5Xhal2AHdji9x yv1/BEN2oLxM/IUNI3NggrJNu71s07uWxvFaQCHFKIF+OYabm/sOt0QKNBDqFToosWiw 0i65ze5mG9MYC0SAZEj6z4+Zg6/LQTcallBtjYCTke1WFge6QKAlHOkyuizUWlcEk+Xf 3x65ESijYRiIxlNEWc1k8nizvsqPUKhjdjKjnIrb25Akd2EbJb6Cy4Tj2u2RLt+SPZs9 wnMw== X-Gm-Message-State: ALoCoQnY/1KlpqvzTSXCXxNO8jdGm4CkVKAL+Z7oDmWFyWFSikQH5LE3LF6cnCvXhz44jDYZP+X6 X-Received: by 10.194.237.41 with SMTP id uz9mr14304498wjc.80.1421853911994; Wed, 21 Jan 2015 07:25:11 -0800 (PST) Received: from [10.16.0.195] (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by mx.google.com with ESMTPSA id 18sm148159wjr.46.2015.01.21.07.25.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jan 2015 07:25:11 -0800 (PST) Message-ID: <54BFC4D6.2010903@6wind.com> Date: Wed, 21 Jan 2015 16:25:10 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.2.0 MIME-Version: 1.0 To: "Liu, Jijiang" , "Ananyev, Konstantin" References: <1418173403-30202-1-git-send-email-jijiang.liu@intel.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01DA7CC5@SHSMSX101.ccr.corp.intel.com> <2601191342CEEE43887BDE71AB977258213D3897@irsmsx105.ger.corp.intel.com> <54AFB13E.2080200@6wind.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01DA85A1@SHSMSX101.ccr.corp.intel.com> <54B3B35A.5030803@6wind.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01DA8E36@SHSMSX101.ccr.corp.intel.com> <54B4EB92.40209@6wind.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01DB0789@SHSMSX101.ccr.corp.intel.com> <2601191342CEEE43887BDE71AB977258213D4FCF@irsmsx105.ger.corp.intel.com> <54B94A18.5030700@6wind.com> <2601191342CEEE43887BDE71AB977258213DCD25@irsmsx105.ger.corp.intel.com> <54BD16F1.6050409@6wind.com> <2601191342CEEE43887BDE71AB977258213DDF46@irsmsx105.ger.corp.intel.com> <54BE4C70.7050406@6wind.com> <2601191342CEEE43887BDE71AB977258213DE5FB@irsmsx105.ger.corp.intel.com> <54BE9B56.7050108@6wind.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01DB55DB@SHSMSX101.ccr.corp.intel.com> In-Reply-To: <1ED644BD7E0A5F4091CF203DAFB8E4CC01DB55DB@SHSMSX101.ccr.corp.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v3 0/3] enhance TX checksum command and csum forwarding engine 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, 21 Jan 2015 15:25:12 -0000 Hi, On 01/21/2015 04:12 AM, Liu, Jijiang wrote: >>>>> Ok, and why it should be our problem? >>>>> We have a lot of things done in a different manner then >>>>> linux/freebsd kernel drivers, Why now it became a problem? >>>> >>>> If linux doesn't need an equivalent flag for doing the same thing, it >>>> probably means we don't need it either. >>> >>> Probably yes .... Or probably not. >>> Why do we need to guess what was the intention of guys who wrote that >> part of linux driver? >> >> Because the dpdk looks very similar to that part of linux driver. > > A guy from Intel who have already confirmed that the NVGRE is not supported yet in Linux kernel. > > He said "So far as I know it is not yet supported and I have no information on when it will be." I added the support of Ether over GRE, IP over GRE and IP over IP tunnels in csumonly to do the test. I ask the csum forward engine to calculate inner IP+TCP checksums, and outer IP (case 6 in [1]). Here are the results: 1/ When I use I40E_TXD_CTX_UDP_TUNNELING: - vxlan: all checksums ok - eth over gre: all checksums ok - ip over gre: not transmitted by hw - ip over ip: all checksums wrong (set to 0 by hw) 2/ When I use I40E_TXD_CTX_GRE_TUNNELING: - vxlan: checksums ok - eth over gre: all checksums ok - ip over gre: all checksums ok - ip over ip: all checksums wrong (set to 0 by hw) 3/ When I use 00b: - vxlan: all checksums ok - eth over gre: all checksums ok - ip over gre: all checksums ok - ip over ip: checksums wrong (set to 0 by hw) All the ip over ip tests do not work yet for an unknown reason. There is maybe something wrong in my app or in the driver (although the registers looks consistent with the datasheet). I think we could use 3/ for all tunnels, because the ipip case is supposed to work according to the datasheet, and all other cases work too. It would allow to remove the UDP_TUNNELING flag from mbuf API. I will send a RFC patch that provides the API change and this new feature in csum forward engine, with full tests on ixgbe and i40e and explanations for all changes. Regards, Olivier [1] http://dpdk.org/ml/archives/dev/2015-January/011127.html