> -----Original Message----- > From: Wiles, Keith > Sent: Tuesday, March 28, 2017 9:40 PM > To: Olivier Matz <olivier.m...@6wind.com> > Cc: Ananyev, Konstantin <konstantin.anan...@intel.com>; Hu, Jiayu > <jiayu...@intel.com>; Yuanhan Liu <yuanhan....@linux.intel.com>; > Richardson, Bruce <bruce.richard...@intel.com>; Stephen Hemminger > <step...@networkplumber.org>; Yigit, Ferruh <ferruh.yi...@intel.com>; > dev@dpdk.org; Liang, Cunming <cunming.li...@intel.com>; Thomas > Monjalon <thomas.monja...@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.wi...@intel.com> wrote: > > > >> > >> On Mar 24, 2017, at 9:59 AM, Olivier Matz <olivier.m...@6wind.com> > wrote: > >> > >> On Fri, 24 Mar 2017 14:37:04 +0000, "Wiles, Keith" > <keith.wi...@intel.com> wrote: > >>>> On Mar 24, 2017, at 6:43 AM, Ananyev, Konstantin > <konstantin.anan...@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
