> On Mar 28, 2017, at 8:57 AM, Hu, Jiayu <[email protected]> wrote: > > > >> -----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 > > Thanks, > Jiayu >> >>> >>>> >>>> >>>> Regards >>>> Olivier >>> >>> Regards, >>> Keith >> >> Regards, >> Keith Regards, Keith
