[dpdk-dev] [PATCH v3 0/3] enhance TX checksum command and csum forwarding engine

[Ananyev, Konstantin]

> -----Original Message-----
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Wednesday, January 21, 2015 9:11 AM
> To: Liu, Jijiang
> Cc: Ananyev, Konstantin; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 0/3] enhance TX checksum command and csum forwarding engine
> 
> Hi Jijiang,
> 
> On 01/21/2015 09:01 AM, Liu, Jijiang wrote:
> >>> I still don't understand why you are so eager to 'forbid' it.
> >>> Yes we support it for FVL, but no one forces you to use it.
> >>
> >> Well, how would you describe this 2 ways of doing the same thing in the
> >> offload API? Would you talk about the i40e registers? It's not because i40e
> >> has 2 ways to do the same operation that the DPDK should do the same.
> >>
> >> How will you explain to a user how to choose between these 2 cases?
> >
> > Talk about B method in http://dpdk.org/ml/archives/dev/2014-December/009213.html again.
> >
> > DPDK Never supports a  NIC that can recognize tunneling packet for TX side before 1.8, right?
> 
> When you say "recognize tunnel", if you mean offlading checksum of
> tunnel headers, I agree.
> 
> If you mean recognizing a tunnel packet in rx, I also agree
> it's new to dpdk-1.8, but I think it's unrelated to what we
> are talking about, which is tx checksum. A DPDK application
> is able to generate tunnel packets by itself and offload the
> checksums to the NIC.
> 
> > So when we need to support TX checksum offload for tunneling packet,  and we have to choose B.2.
> 
> I don't see why we should choose either B.1 or B.2 (I guess you want
> to say B.1 here, right?).
> 
> The m->lX_len are not filled in rx today. If one day they are, it won't
> prevent the application to configure the lX_len fields and offload
> flags according to the API.
> 
> > After introducing i40e(FVL),  FVL is able to recognize tunneling packet and  support outer IP, or inner IP or outer IP and inner IP TX
> checksum for tunneling packet.
> > And you agree on "outer and inner at the same time", why do you object "only inner"?
> >
> > Actually, B.2 method is a software workaround using L2 length when NIC can't recognize tunneling packet.
> > When NIC is able to recognize tunneling packet, I think you shouldn't take B.2 as a standard to 'forbid' other method.
> 
> Again, I'm not sure there is a link between "recognizing tunneling
> packets" and tx checksum offload of tunnels. 

I think what Jijiang doesn't talk about RX here.
What he is trying to say that with B.2 (case 4) we hide from HW the fact that the packet is tunnelling.
We just using the fact, that to calculate cksum for inner packet only, HW doesn't need to know is it a tunnelling packet or not.
All it needs is a proper values of l2_len and l3_len. 

> 
> Regards,
> Olivier