[dpdk-dev] [PATCH 0/2] lib: add TCP IPv4 GRO support

[Hu, Jiayu]

> -----Original Message-----
> From: Wiles, Keith
> Sent: Tuesday, March 28, 2017 9:40 PM
> To: Olivier Matz <olivier.matz at 6wind.com>
> Cc: Ananyev, Konstantin <konstantin.ananyev at intel.com>; Hu, Jiayu
> <jiayu.hu at intel.com>; Yuanhan Liu <yuanhan.liu at linux.intel.com>;
> Richardson, Bruce <bruce.richardson at intel.com>; Stephen Hemminger
> <stephen at networkplumber.org>; Yigit, Ferruh <ferruh.yigit at intel.com>;
> dev at dpdk.org; Liang, Cunming <cunming.liang at intel.com>; Thomas
> Monjalon <thomas.monjalon at 6wind.com>
> Subject: Re: [dpdk-dev] [PATCH 0/2] lib: add TCP IPv4 GRO support
> 
> 
> > On Mar 24, 2017, at 10:07 AM, Wiles, Keith <keith.wiles at intel.com> wrote:
> >
> >>
> >> On Mar 24, 2017, at 9:59 AM, Olivier Matz <olivier.matz at 6wind.com>
> wrote:
> >>
> >> On Fri, 24 Mar 2017 14:37:04 +0000, "Wiles, Keith"
> <keith.wiles at intel.com> wrote:
> >>>> On Mar 24, 2017, at 6:43 AM, Ananyev, Konstantin
> <konstantin.ananyev at intel.com> wrote:
> >>>>
> >>>>
> >>>>
> >>
> >> [...]
> >>
> >>>> Yep, that's what my take from the beginning:
> >>>> Let's develop a librte_gro first and make it successful, then we can think
> should
> >>>> we (and how) put into ethdev layer.
> >>>
> >>> Let not create a gro library and put the code into librte_net as size is not
> a concern yet and it is the best place to put the code. As for ip_frag someone
> can move it into librte_net if someone writes the patch.
> >>
> >> The size of a library _is_ an argument. Not the binary size in bytes, but
> >> its API, because that's what the developper sees. Today, librte_net
> contains
> >> protocol headers definitions and some network helpers, and the API
> surface
> >> is already quite big (look at the number of lines of .h files).
> >>
> >> I really like having a library name which matches its content.
> >> The anwser to "what can I find in librte_gro?" is quite obvious.
> >
> > If we are going to talk about API surface area lets talk about ethdev then :-)
> >
> > Ok, lets create a new librte_gro, but I am not convinced it is reasonable.
> Maybe a better generic name is needed if we are going to add GSO to the
> library too. So a new name for the lib is better then librte_gro, unless you are
> going to create another library for GSO.
> >
> > I still think the design needs to be integrated in as a real offload as I stated
> before and that is not something I am willing let drop.
> 
> I guess we agree to create the library librte_gro and the current code needs
> to be updated to be include as a real offload support to DPDK as I see no real
> conclusion to this topic.

OK, I have known your opinions, and I agree with you. I will provide a real offloading
example to demonstrate the usage of librte_gro in the next patch.

Thanks,
Jiayu
> 
> >
> >>
> >>
> >> Regards
> >> Olivier
> >
> > Regards,
> > Keith
> 
> Regards,
> Keith