> 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. > > > Regards > Olivier Regards, Keith
