Thread (1 message) 1 message, 1 author, 2015-01-26

Re: [PATCH v3 0/3] enhance TX checksum command and csum forwarding engine

From: Liu, Jijiang <hidden>
Date: 2015-01-26 06:02:44

Hi,
-----Original Message-----
From: Ananyev, Konstantin
Sent: Monday, January 26, 2015 12:14 PM
To: Olivier MATZ; Liu, Jijiang
Cc: dev-VfR2kkLFssw@public.gmane.org
Subject: RE: [dpdk-dev] [PATCH v3 0/3] enhance TX checksum command and
csum forwarding engine

Hi lads,
quoted
-----Original Message-----
From: Olivier MATZ [mailto:olivier.matz-pdR9zngts4EAvxtiuMwx3w@public.gmane.org]
Sent: Wednesday, January 21, 2015 3:25 PM
To: Liu, Jijiang; Ananyev, Konstantin
Cc: dev-VfR2kkLFssw@public.gmane.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:
quoted
quoted
quoted
quoted
quoted
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.
quoted
quoted
He said "So far as I know it is not yet supported and I have no information on
when it will be."
quoted
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.
Yes, the L4TUNT=0 is ok  for all cases.

But we still need to get confirmation from FVL guys, probably there are some issues in HW/FW.
I and Helin will confirm this with FVL guys ASAP.

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().
Yes, for IPIP, the check should be removed.
Konstantin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help