>From: Ananyev, Konstantin >Sent: Wednesday, August 30, 2017 10:59 AM >To: Ananyev, Konstantin <konstantin.anan...@intel.com>; Kavanagh, Mark B ><mark.b.kavan...@intel.com>; Hu, Jiayu <jiayu...@intel.com> >Cc: dev@dpdk.org; Tan, Jianfeng <jianfeng....@intel.com> >Subject: RE: [PATCH 2/5] gso/lib: add TCP/IPv4 GSO support > > > >> -----Original Message----- >> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ananyev, Konstantin >> Sent: Wednesday, August 30, 2017 10:39 AM >> To: Kavanagh, Mark B <mark.b.kavan...@intel.com>; Hu, Jiayu ><jiayu...@intel.com> >> Cc: dev@dpdk.org; Tan, Jianfeng <jianfeng....@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 >> >
