[dpdk-dev] [PATCH 2/5] gso/lib: add TCP/IPv4 GSO support

[Kavanagh, Mark B]

>From: Ananyev, Konstantin
>Sent: Wednesday, August 30, 2017 10:59 AM
>To: Ananyev, Konstantin <konstantin.ananyev at intel.com>; Kavanagh, Mark B
><mark.b.kavanagh at intel.com>; Hu, Jiayu <jiayu.hu at intel.com>
>Cc: dev at dpdk.org; Tan, Jianfeng <jianfeng.tan at intel.com>
>Subject: RE: [PATCH 2/5] gso/lib: add TCP/IPv4 GSO support
>
>
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ananyev, Konstantin
>> Sent: Wednesday, August 30, 2017 10:39 AM
>> To: Kavanagh, Mark B <mark.b.kavanagh at intel.com>; Hu, Jiayu
><jiayu.hu at intel.com>
>> Cc: dev at dpdk.org; Tan, Jianfeng <jianfeng.tan at intel.com>
>> Subject: Re: [dpdk-dev] [PATCH 2/5] gso/lib: add TCP/IPv4 GSO support
>>
>> Hi Mark,
>>
>> > >> > +
>> > >> > +void
>> > >> > +gso_parse_packet(struct rte_mbuf *pkt)
>> > >>
>> > >> There is a function rte_net_get_ptype() that supposed to provide
>similar
>> > >functionality.
>> > >> So we probably don't need to create a new SW parse function here,
>instead
>> > >would be better
>> > >> to reuse (and update if needed) an existing one.
>> > >> Again user already might have l2/l3/l4.../_len and packet_type setuped.
>> > >> So better to keep SW packet parsing out of scope of that library.
>> > >
>> > >Hmm, I know we have discussed this design choice in the GRO library, and
>I
>> > >also think it's
>> > >better to reuse these values.
>> > >
>> > >But from the perspective of OVS, it may add extra overhead, since OVS
>doesn't
>> > >parse every
>> > >packet originally. Maybe @Mark can give us more inputs from the view of
>OVS.
>> >
>> > Hi Jiayu, Konstantin
>> >
>> > For GSO, the application needs to know:
>> > - the packet type (as it only currently supports TCP/IPv4, VxLAN, GRE
>packets)
>> > - the l2/3/4_lens, etc. (in order to replicate the original packet's
>headers across outgoing segments)
>> >
>> > For this, we can use the rte_net_get_ptype function, as per Konstantin's
>suggestion, as it provides both - thanks Konstantin!
>> >
>> > WRT the extra overhead in OvS: TSO is the defacto standard, and GSO is
>provided purely as a fallback option. As such, and since the
>> > additional packet parsing is a necessity in order to facilitate GSO, the
>additional overhead is IMO acceptable.
>>
>> As I remember, for TSO in DPDK user still have to provide l2/l3/l4_len and
>mss information to the PMD.

Yes, that's correct. 

>> So unless user knows these value straightway (user creates a packet himself)
>some packet processing will be unavailable anyway.

That's correct also. Currently, packets that originate in a VM, and which have been marked for TSO, have the l2_len, etc. fields populated by the 'parse_ethernet' function, called as part of the call stack of the rte_vhost_dequeue_burst function, so that particular overhead is already implicit in the TSO case.

>> Konstantin
>
>s/unavailable/unavoidable/
>sorry for bad typing.
>Konstantin
>
>> >
>> > Thanks,
>> > Mark
>> >