> On Mar 28, 2017, at 8:57 AM, Hu, Jiayu <jiayu...@intel.com> wrote: > > > >> -----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 > > Thanks, > Jiayu >> >>> >>>> >>>> >>>> Regards >>>> Olivier >>> >>> Regards, >>> Keith >> >> Regards, >> Keith Regards, Keith
