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