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

[Wiles, Keith]

> On Mar 28, 2017, at 8:57 AM, Hu, Jiayu <jiayu.hu at intel.com> wrote:
> 
> 
> 
>> -----Original Message-----
>> From: Wiles, Keith
>> Sent: Tuesday, March 28, 2017 9:40 PM
>> To: Olivier Matz <olivier.matz at 6wind.com>
>> Cc: Ananyev, Konstantin <konstantin.ananyev at intel.com>; Hu, Jiayu
>> <jiayu.hu at intel.com>; Yuanhan Liu <yuanhan.liu at linux.intel.com>;
>> Richardson, Bruce <bruce.richardson at intel.com>; Stephen Hemminger
>> <stephen at networkplumber.org>; Yigit, Ferruh <ferruh.yigit at intel.com>;
>> dev at dpdk.org; Liang, Cunming <cunming.liang at intel.com>; Thomas
>> Monjalon <thomas.monjalon at 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.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.
> 
> 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