> -----Original Message----- > From: Wiles, Keith > Sent: Tuesday, March 28, 2017 9:40 PM > To: Olivier Matz <[email protected]> > Cc: Ananyev, Konstantin <[email protected]>; Hu, Jiayu > <[email protected]>; Yuanhan Liu <[email protected]>; > Richardson, Bruce <[email protected]>; Stephen Hemminger > <[email protected]>; Yigit, Ferruh <[email protected]>; > [email protected]; Liang, Cunming <[email protected]>; Thomas > Monjalon <[email protected]> > Subject: Re: [dpdk-dev] [PATCH 0/2] lib: add TCP IPv4 GRO support > > > > On Mar 24, 2017, at 10:07 AM, Wiles, Keith <[email protected]> wrote: > > > >> > >> On Mar 24, 2017, at 9:59 AM, Olivier Matz <[email protected]> > wrote: > >> > >> On Fri, 24 Mar 2017 14:37:04 +0000, "Wiles, Keith" > <[email protected]> wrote: > >>>> On Mar 24, 2017, at 6:43 AM, Ananyev, Konstantin > <[email protected]> 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
