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

Liu, Jijiang jijiang.liu at intel.com
Wed Jan 21 09:01:40 CET 2015


Hi,

> -----Original Message-----
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Wednesday, January 21, 2015 2:16 AM
> To: Ananyev, Konstantin; Liu, Jijiang
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 0/3] enhance TX checksum command and
> csum forwarding engine
> 
> Hi Konstantin,
> >
> >> Case 4) and case 9) would fill the hardware registers exactly the same.
> >
> > No, they wouldn't.
> > Please read corresponding section of FVL spec and i40e_rxtx.c For case
> > 4) we only need to setup TDD (TX data descriptor) with the following
> values:
> > IIPT, IPLEN, L4T, L4LEN
> > For case 9) we need to setup both TDD and TCD (TX context descriptor)
> with the following values:
> > TDD: IIPT, IPLEN, L4T, L4LEN
> > TCD: EIPT, EIPLEN,  L4TUNT, L4TUNLEN
> >
> >> To me, it's just an API question.
> >
> > No, it is not.
> >
> > 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?
So when we need to support TX checksum offload for tunneling packet,  and we have to choose B.2.

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.


> Having to support these 2 different cases for the same thing will complexify
> all future drivers that will not work the same way than i40e.
> 
> >>> As one of possible use-cases:  HW VLAN tags insertion for both inner and
> outer packets.
> >>> FVL can do that, though as I know our PMD doesn't implement it yet.
> >>> For that, we'll need to specify at least:
> >>> outer_l2_len, outer_l3_len, l2_len.
> >>> While PKT_TX_OUTER_* might stay cleared.
> >>
> >> If a VLAN flag has to be inserted in outer header, a new flag
> >> PKT_TX_OUTER_INSERT_VLAN would be added. So my specification
> would
> >> still be correct:
> >>
> >>     The driver should look at mb->outer_lX_len only if a
> >>     PKT_TX_OUTER_* flag is present.
> >>
> >
> > Introducing PKT_TX_OUTER_INSERT_VLAN is ok.
> > Though I still think we'll need TX_*_TUNNEL flags and no need to 'forbid'
> case 9).
> > BTW, as I can see linux i40e driver for tunnelling packets uses case 9), not
> case 4), right?
> 
> I need to check this.
> 
> Regards,
> Olivier



More information about the dev mailing list