[dpdk-dev] [PATCH 0/2] lib: add TCP IPv4 GRO support

Wiles, Keith keith.wiles at intel.com
Tue Mar 28 15:40:12 CEST 2017


> On Mar 24, 2017, at 10:07 AM, Wiles, Keith <keith.wiles at intel.com> wrote:
> 
>> 
>> On Mar 24, 2017, at 9:59 AM, Olivier Matz <olivier.matz at 6wind.com> wrote:
>> 
>> On Fri, 24 Mar 2017 14:37:04 +0000, "Wiles, Keith" <keith.wiles at intel.com> wrote:
>>>> On Mar 24, 2017, at 6:43 AM, Ananyev, Konstantin <konstantin.ananyev at 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



More information about the dev mailing list