Hi lads, > -----Original Message----- > From: Olivier MATZ [mailto:olivier.matz at 6wind.com] > Sent: Wednesday, January 21, 2015 3:25 PM > To: Liu, Jijiang; Ananyev, Konstantin > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3 0/3] enhance TX checksum command and csum > forwarding engine > > 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
I tried to repeat Olivier test-cases on my box. Though, I didn't use test-pmd cusmonly and i40ePMD logic, but filled TCD and TDD mostly from hardcoded values. That's what I got: 4 input packets: a) ETHER/IPv4/UDP/VXLAN/ETHER/IPV4/TCP b) ETHER/IPv4/GRE/ETHER/IPV4/TCP c) ETHER/IPv4/GRE/IPV4/TCP d) ETHER/IPv4/IPV4/TCP 1/ L4TUNT==1(I40E_TXD_CTX_UDP_TUNNELING): a),b): all checksums ok c),d): not transmitted by HW. 2/ L4TUNT==2(I40E_TXD_CTX_GRE_TUNNELING): a) b),c): all checksums ok d): not transmitted by HW. 3/ L4TUNT==0(UNKNOWN): a),b),c),d): all checksums ok So yes, it seems that L4TUNT==0 works perfectly ok for all cases, as long as L4TUNLEN and other TCD values are setup properly. Which makes me think, that probably we can do what you suggested: just use L4TUNT=0 for all cases. Though as Jijiang said, we waiting for confirmation from FVL guys, that there are no hidden implications with that approach. Another thing - IPIP seems to work ok by HW. There is something wrong on our (PMD/test-pmd) side. I think at least we have to remove the following check: if (!l2_len) { PMD_DRV_LOG(DEBUG, "L2 length set to 0"); return; } in i40e_txd_enable_checksum(). Konstantin