From: "Wiles, Keith" <keith.wiles@intel.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Cc: "Hu, Jiayu" <jiayu.hu@intel.com>,
Yuanhan Liu <yuanhan.liu@linux.intel.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
Stephen Hemminger <stephen@networkplumber.org>,
"Yigit, Ferruh" <ferruh.yigit@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"Liang, Cunming" <cunming.liang@intel.com>,
Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: [dpdk-dev] [PATCH 0/2] lib: add TCP IPv4 GRO support
Date: Fri, 24 Mar 2017 14:37:04 +0000 [thread overview]
Message-ID: <0C56AF3E-C8AB-4903-AD34-F39C6D74C889@intel.com> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB9772583FAD80A6@IRSMSX109.ger.corp.intel.com>
> On Mar 24, 2017, at 6:43 AM, Ananyev, Konstantin <konstantin.ananyev@intel.com> wrote:
>
>
>
>> -----Original Message-----
>> From: Hu, Jiayu
>> Sent: Friday, March 24, 2017 8:07 AM
>> To: Yuanhan Liu <yuanhan.liu@linux.intel.com>
>> Cc: Wiles, Keith <keith.wiles@intel.com>; Ananyev, Konstantin <konstantin.ananyev@intel.com>; Richardson, Bruce
>> <bruce.richardson@intel.com>; Stephen Hemminger <stephen@networkplumber.org>; Yigit, Ferruh <ferruh.yigit@intel.com>;
>> dev@dpdk.org; Liang, Cunming <cunming.liang@intel.com>; Thomas Monjalon <thomas.monjalon@6wind.com>
>> Subject: Re: [dpdk-dev] [PATCH 0/2] lib: add TCP IPv4 GRO support
>>
>> On Fri, Mar 24, 2017 at 03:22:30PM +0800, Yuanhan Liu wrote:
>>> On Fri, Mar 24, 2017 at 06:18:48AM +0000, Wiles, Keith wrote:
>>>>>> I think that having a separate library for GRO is a step in a right direction.
>>>>>>> From my perspective - it provides a clean and flexible way to use that feature.
>>>>>> If later someone would like to put GRO into ethdev layer (or particular PMD),
>>>>>> he can use existing librte_gro for that.
>>>>>
>>>>> Agree. I think introducing more flexibility is an important thing for applications.
>>>>
>>>> Creating a new library just for GRO is not a reasonable solution, but adding that support to an existing library like librte_net would
>> be cleaner and not create yet another library.
>>>
>>> Librte_net seems like a good suggestion to me, especially when we are
>>> considering to add GSO in future. The only concern to me is "net" may
>>> be too generic. It maybe kind of hard to decide which should be in
>>> librte_net, and which should be added as a standalone lib. For example,
>>> shouldn't 'lpm' and 'ip_frag' also belong to librte_net?
>
> About librte_gro vs librte_net:
>
> Right now librte_net is quite lightweight one - it mostly contains a net protocols definitions
> plus some extra helper functions: to parse the l2/l3 headers to determine ptype, to calculate cksum, etc.
> GRO code is quite different - it has to allocate and manage hash table(s), etc.
> Again my understanding it would keep growing (with new proto support).
> Again as mentioned above if GRO should go into librte_net, then librte_ipfrag and future GSO should also be here.
> Which would create quite a monstrous library.
> So I think it is better to keep librte_net small and tidy and put GRO functionality into the new library.
The size of a library is not a concern we have some pretty big ones already.
-rw-rw-r-- 2 rkwiles rkwiles 1.2M Mar 21 15:22 librte_acl.a
-rw-rw-r-- 1 rkwiles rkwiles 39K Mar 21 15:22 librte_cfgfile.a
-rw-rw-r-- 1 rkwiles rkwiles 292K Mar 21 15:22 librte_cmdline.a
-rw-rw-r-- 1 rkwiles rkwiles 211K Mar 21 15:23 librte_cryptodev.a
-rw-rw-r-- 1 rkwiles rkwiles 75K Mar 21 15:22 librte_distributor.a
-rw-rw-r-- 1 rkwiles rkwiles 1.4M Mar 21 15:22 librte_eal.a
-rw-rw-r-- 1 rkwiles rkwiles 323K Mar 21 15:23 librte_efd.a
-rw-rw-r-- 1 rkwiles rkwiles 374K Mar 22 09:31 librte_ethdev.a
-rw-rw-r-- 1 rkwiles rkwiles 675K Mar 21 15:22 librte_hash.a
-rw-rw-r-- 1 rkwiles rkwiles 366K Mar 21 15:23 librte_ip_frag.a
-rw-rw-r-- 1 rkwiles rkwiles 29K Mar 21 15:22 librte_jobstats.a
-rw-rw-r-- 1 rkwiles rkwiles 167K Mar 21 15:23 librte_kni.a
-rw-rw-r-- 1 rkwiles rkwiles 19K Mar 21 15:22 librte_kvargs.a
-rw-rw-r-- 1 rkwiles rkwiles 309K Mar 21 15:22 librte_lpm.a
-rw-rw-r-- 1 rkwiles rkwiles 93K Mar 21 15:22 librte_mbuf.a
-rw-rw-r-- 1 rkwiles rkwiles 270K Mar 21 15:22 librte_mempool.a
-rw-rw-r-- 1 rkwiles rkwiles 17K Mar 21 15:22 librte_meter.a
-rw-rw-r-- 1 rkwiles rkwiles 71K Mar 21 15:22 librte_net.a
-rw-rw-r-- 1 rkwiles rkwiles 211K Mar 21 15:23 librte_pdump.a
-rw-rw-r-- 1 rkwiles rkwiles 140K Mar 21 15:23 librte_pipeline.a
-rw-rw-r-- 1 rkwiles rkwiles 1.4M Mar 21 15:23 librte_port.a
-rw-rw-r-- 1 rkwiles rkwiles 122K Mar 21 15:22 librte_power.a
-rw-rw-r-- 1 rkwiles rkwiles 154K Mar 21 15:22 librte_reorder.a
-rw-rw-r-- 1 rkwiles rkwiles 63K Mar 21 15:22 librte_ring.a
-rw-rw-r-- 1 rkwiles rkwiles 377K Mar 21 15:23 librte_sched.a
-rw-rw-r-- 1 rkwiles rkwiles 1.4M Mar 21 15:23 librte_table.a
-rw-rw-r-- 1 rkwiles rkwiles 53K Mar 21 15:22 librte_timer.a
-rw-rw-r-- 1 rkwiles rkwiles 609K Mar 21 15:23 librte_vhost.a
Removed the PMD archives and ls is not a great way to get the true size compared to using ‘size’.
If you look at the size values, the ‘size *.a’ is interesting too.
The size of librte_net is 71K + ip_frag 366K is pretty small compared to a few others. I would assume GRO is pretty small too, so adding GRO into librte_net is very reasonable. We could leave ip_frag out as currently it is a standalone lib, but continue to add GSO to librte_net. I would not assume the size would that large and it seems like the best place to put the code.
If you still want to create a gso lib then I guess you can, just seems unreasonable to me.
>
>>>
>>>> Creating more flexibility is not the best goal as we really want to make GRO easy and simple for the developer to use for any
>> device without having to change his applications to take advantage of the feature. Some times providing more flexibility just means
>> making it more complexed and more APIs the developer needs to understand. Providing GRO as a offload feature is the better
>> direction as it makes it simple for an application to use.
>>>>
>>>> If we provide GRO as a standard offload similar to the other offloads we currently have makes it easy for the developer. The best
>> goal for a feature is the best performance for the application without having the application make even more APIs calls along with
>> simple and easy to use.
>>>
>>> In general, I'd agree with you, if no one is object to add a short piece
>>> of code at the end of rte_eth_rx_burst:
>>>
>>> + if (eth_gro_is_enabled(dev))
>>> + nb_rx = rte_net_gro(...);
>>> +
>>> return nb_rx;
>>> }
>>>
>>> Objections?
Why do we need to modify every driver, why not use the RX callback feature then no drivers were harmed in this patch :-)
>
> I'd better not to open that door.
> If we'll allow that for GRO - we'll have to allow that for every other stuff:
> - ip reassembly
> - l3/l4 cksum calculation if underlying HW doesn't support it
> - SW ptype recognition
> - etc.
>
> Adding all these things into rx_burst() would most likely slow things down
> (remember it is a data-path) and pretty soon would bring rx_burst() into
> messy monster that would be hard to maintain and debug.
>
> My preference would be to keep rte_ethdev data-path as small and tidy as possible.
> If in future we'd really like to introduce all these SW things into dev layer -
> my preference would be to create some sort of new abstraction on top of current ethdev:
> rte_eth_smartdev or so.
> So it would be:
> rte_eth_smartdev_rx_burst(....)
> {
> nb_rx = rte_eth_rx_burst(...);
> /* apply GRO, reassembly, etc. */
> ...
> }
Adding a new API is still not required, as the RX callback code is already in place for these types of post processing of mbufs.
>
> Something similar with what 6Wind trying to introduce with their failsafe dev concept.
The 6Wind is a different story here and not a post processing of RX mbufs.
>
>>>
>>> But one way or another, we need put the gro code at somewhere and we
>>> need introduce a generic API for that. It could be librte_net as you
>>> suggested. So the good thing is that we all at least come an agreement
>>> that it should be implemented in lib, right? The only controversy is
>>> should we export it to application and let them to invoke it, or hide
>>> it inside rte_eth_rx_burst.
>>>
>>> Though it may take some time for all of us to come an agreement on that,
>>> but the good thing is that it would be a very trivial change once it's
>>> done. Agree?
>>
>> Agree.
>>
>>>
>>> Thus I'd suggest Jiayu to focus on the the GRO code developement, such
>>> as making it generic enough and adding other protocols support. And I
>>> would like to ask you guys to help review them. Makes sense to all?
>>>
>>
>> Agree again. No matter where to put GRO code, the apis should be generic
>> and extensible. And more protocols should be supported.
>
> 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.
>
> Konstantin
>
>>
>> Thanks,
>> Jiayu
>>
>>> Thanks.
>>>
>>> --yliu
>>>
>>>
>>>>>> I didn't have a closer look yet, but I think that caught my attention:
>>>>>> API fir the lib seems too IPv4/TCP oriented -
>>>>>> though I understand that the most common case and should be implemented first.
>>>>>> I wonder can we have it a bit more generic and extendable, so user can specify what combination of protocols
>>>>>> he is interested in (let say: ipv4/tcp, ipv6/tcp, etc.).
>>>>>> Even if right now we'll have it implemented only for ipv4/tcp.
>>>>>> Then internally we can have some check is that supported or not and if yes setup things accordingly.
>>>>>
>>>>> Indeed, current apis are too specific. It's not very friendly to applications.
>>>>> Maybe we can use macro to define the combination of protocols, like GRO_TCP_IPV4
>>>>> and GRO_UDP_IPV6; and provide a generic setup function and reassembly function.
>>>>> Both of them perform different operations according to the macro value inputted
>>>>> by the application.
>>>>>
>>>>>> BTW, that's for 17.08, right?
>>>>>
>>>>> Yes, it's for 17.08.
>>>>>
>>>>> Jiayu
>>>>>>
>>>>>> Konstantin
>>>>>>
>>>>>>
>>>>
>>>> Regards,
>>>> Keith
Regards,
Keith
next prev parent reply other threads:[~2017-03-24 14:37 UTC|newest]
Thread overview: 141+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-22 9:32 Jiayu Hu
2017-03-22 9:32 ` [dpdk-dev] [PATCH 1/2] lib: add Generic Receive Offload support for TCP IPv4 packets Jiayu Hu
2017-03-22 9:32 ` [dpdk-dev] [PATCH 2/2] app/testpmd: provide TCP IPv4 GRO function in iofwd mode Jiayu Hu
[not found] ` <1B893F1B-4DA8-4F88-9583-8C0BAA570832@intel.com>
[not found] ` <20170323021502.GA114662@localhost.localdomain>
[not found] ` <C830A6FC-F440-4E68-AB4E-2FD502722E3F@intel.com>
[not found] ` <20170323062433.GA120139@localhost.localdomain>
[not found] ` <59AF69C657FD0841A61C55336867B5B066729E3F@IRSMSX103.ger.corp.intel.com>
[not found] ` <20170323102135.GA124301@localhost.localdomain>
[not found] ` <2601191342CEEE43887BDE71AB9772583FAD410A@IRSMSX109.ger.corp.intel.com>
2017-03-24 2:23 ` [dpdk-dev] [PATCH 0/2] lib: add TCP IPv4 GRO support Jiayu Hu
2017-03-24 6:18 ` Wiles, Keith
2017-03-24 7:22 ` Yuanhan Liu
2017-03-24 8:06 ` Jiayu Hu
2017-03-24 11:43 ` Ananyev, Konstantin
2017-03-24 14:37 ` Wiles, Keith [this message]
2017-03-24 14:59 ` Olivier Matz
2017-03-24 15:07 ` Wiles, Keith
2017-03-28 13:40 ` Wiles, Keith
2017-03-28 13:57 ` Hu, Jiayu
2017-03-28 16:06 ` Wiles, Keith
2017-03-29 10:47 ` Morten Brørup
2017-03-29 12:12 ` Wiles, Keith
2017-04-04 12:31 ` [dpdk-dev] [PATCH v2 0/3] support GRO in DPDK Jiayu Hu
2017-04-04 12:31 ` [dpdk-dev] [PATCH v2 1/3] lib: add Generic Receive Offload API framework Jiayu Hu
2017-04-04 12:31 ` [dpdk-dev] [PATCH v2 2/3] lib/gro: add TCP/IPv4 GRO support Jiayu Hu
2017-04-04 12:31 ` [dpdk-dev] [PATCH v2 3/3] app/testpmd: enable GRO feature Jiayu Hu
2017-04-24 8:09 ` [dpdk-dev] [PATCH v3 0/3] support GRO in DPDK Jiayu Hu
2017-04-24 8:09 ` [dpdk-dev] [PATCH v3 1/3] lib: add Generic Receive Offload API framework Jiayu Hu
2017-05-22 9:19 ` Ananyev, Konstantin
2017-05-23 10:31 ` Jiayu Hu
2017-05-24 12:38 ` Ananyev, Konstantin
2017-05-26 7:26 ` Jiayu Hu
2017-05-26 23:10 ` Ananyev, Konstantin
2017-05-27 3:41 ` Jiayu Hu
2017-05-27 11:12 ` Ananyev, Konstantin
2017-05-27 14:09 ` Jiayu Hu
2017-05-27 16:51 ` Ananyev, Konstantin
2017-05-29 10:22 ` Hu, Jiayu
2017-05-29 12:18 ` Bruce Richardson
2017-05-30 14:10 ` Hu, Jiayu
2017-05-29 12:51 ` Ananyev, Konstantin
2017-05-30 5:29 ` Hu, Jiayu
2017-05-30 11:56 ` Ananyev, Konstantin
2017-04-24 8:09 ` [dpdk-dev] [PATCH v3 2/3] lib/gro: add TCP/IPv4 GRO support Jiayu Hu
2017-04-24 8:09 ` [dpdk-dev] [PATCH v3 3/3] app/testpmd: enable GRO feature Jiayu Hu
2017-06-07 9:24 ` Wu, Jingjing
2017-06-07 11:08 ` [dpdk-dev] [PATCH v4 0/3] Support TCP/IPv4 GRO in DPDK Jiayu Hu
2017-06-07 11:08 ` [dpdk-dev] [PATCH v4 1/3] lib: add Generic Receive Offload API framework Jiayu Hu
2017-06-07 11:08 ` [dpdk-dev] [PATCH v4 2/3] lib/gro: add TCP/IPv4 GRO support Jiayu Hu
2017-06-07 11:08 ` [dpdk-dev] [PATCH v4 3/3] app/testpmd: enable TCP/IPv4 GRO Jiayu Hu
2017-06-18 7:21 ` [dpdk-dev] [PATCH v5 0/3] Support TCP/IPv4 GRO in DPDK Jiayu Hu
2017-06-18 7:21 ` [dpdk-dev] [PATCH v5 1/3] lib: add Generic Receive Offload API framework Jiayu Hu
2017-06-19 4:03 ` Tiwei Bie
2017-06-19 5:16 ` Jiayu Hu
2017-06-19 15:43 ` Tan, Jianfeng
2017-06-19 15:55 ` Stephen Hemminger
2017-06-20 1:48 ` Jiayu Hu
2017-06-18 7:21 ` [dpdk-dev] [PATCH v5 2/3] lib/gro: add TCP/IPv4 GRO support Jiayu Hu
2017-06-19 15:43 ` Tan, Jianfeng
2017-06-20 3:22 ` Jiayu Hu
2017-06-20 15:15 ` Ananyev, Konstantin
2017-06-20 16:16 ` Jiayu Hu
2017-06-20 15:21 ` Ananyev, Konstantin
2017-06-20 23:30 ` Tan, Jianfeng
2017-06-20 23:55 ` Stephen Hemminger
2017-06-22 7:39 ` Jiayu Hu
2017-06-22 8:18 ` Jiayu Hu
2017-06-22 9:35 ` Tan, Jianfeng
2017-06-22 13:55 ` Jiayu Hu
2017-06-18 7:21 ` [dpdk-dev] [PATCH v5 3/3] app/testpmd: enable TCP/IPv4 GRO Jiayu Hu
2017-06-19 1:24 ` Yao, Lei A
2017-06-19 2:27 ` Wu, Jingjing
2017-06-19 3:22 ` Jiayu Hu
2017-06-19 1:39 ` [dpdk-dev] [PATCH v5 0/3] Support TCP/IPv4 GRO in DPDK Tan, Jianfeng
2017-06-19 3:07 ` Jiayu Hu
2017-06-19 5:12 ` Jiayu Hu
2017-06-23 14:43 ` [dpdk-dev] [PATCH v6 " Jiayu Hu
2017-06-23 14:43 ` [dpdk-dev] [PATCH v6 1/3] lib: add Generic Receive Offload API framework Jiayu Hu
2017-06-25 16:53 ` Tan, Jianfeng
2017-06-23 14:43 ` [dpdk-dev] [PATCH v6 2/3] lib/gro: add TCP/IPv4 GRO support Jiayu Hu
2017-06-25 16:53 ` Tan, Jianfeng
2017-06-26 1:58 ` Jiayu Hu
2017-06-23 14:43 ` [dpdk-dev] [PATCH v6 3/3] app/testpmd: enable TCP/IPv4 GRO Jiayu Hu
2017-06-24 8:01 ` Yao, Lei A
2017-06-25 16:03 ` [dpdk-dev] [PATCH v6 0/3] Support TCP/IPv4 GRO in DPDK Tan, Jianfeng
2017-06-26 1:35 ` Jiayu Hu
2017-06-26 6:43 ` [dpdk-dev] [PATCH v7 " Jiayu Hu
2017-06-26 6:43 ` [dpdk-dev] [PATCH v7 1/3] lib: add Generic Receive Offload API framework Jiayu Hu
2017-06-27 23:42 ` Ananyev, Konstantin
2017-06-28 2:17 ` Jiayu Hu
2017-06-28 17:41 ` Ananyev, Konstantin
2017-06-29 1:19 ` Jiayu Hu
2017-06-26 6:43 ` [dpdk-dev] [PATCH v7 2/3] lib/gro: add TCP/IPv4 GRO support Jiayu Hu
2017-06-28 23:56 ` Ananyev, Konstantin
2017-06-29 2:26 ` Jiayu Hu
2017-06-30 12:07 ` Ananyev, Konstantin
2017-06-30 15:40 ` Hu, Jiayu
2017-06-26 6:43 ` [dpdk-dev] [PATCH v7 3/3] app/testpmd: enable TCP/IPv4 GRO Jiayu Hu
2017-06-29 10:58 ` [dpdk-dev] [PATCH v8 0/3] Support TCP/IPv4 GRO in DPDK Jiayu Hu
2017-06-29 10:58 ` [dpdk-dev] [PATCH v8 1/3] lib: add Generic Receive Offload API framework Jiayu Hu
2017-06-29 10:58 ` [dpdk-dev] [PATCH v8 2/3] lib/gro: add TCP/IPv4 GRO support Jiayu Hu
2017-06-29 17:51 ` Stephen Hemminger
2017-06-30 2:07 ` Jiayu Hu
2017-06-29 10:59 ` [dpdk-dev] [PATCH v8 3/3] app/testpmd: enable TCP/IPv4 GRO Jiayu Hu
2017-06-30 2:26 ` Wu, Jingjing
2017-06-30 6:53 ` [dpdk-dev] [PATCH v9 0/3] Support TCP/IPv4 GRO in DPDK Jiayu Hu
2017-06-30 6:53 ` [dpdk-dev] [PATCH v9 1/3] lib: add Generic Receive Offload API framework Jiayu Hu
2017-06-30 6:53 ` [dpdk-dev] [PATCH v9 2/3] lib/gro: add TCP/IPv4 GRO support Jiayu Hu
2017-06-30 6:53 ` [dpdk-dev] [PATCH v9 3/3] app/testpmd: enable TCP/IPv4 GRO Jiayu Hu
2017-07-01 11:08 ` [dpdk-dev] [PATCH v10 0/3] Support TCP/IPv4 GRO in DPDK Jiayu Hu
2017-07-01 11:08 ` [dpdk-dev] [PATCH v10 1/3] lib: add Generic Receive Offload API framework Jiayu Hu
2017-07-02 10:19 ` Tan, Jianfeng
2017-07-03 5:56 ` Hu, Jiayu
2017-07-04 8:11 ` Yuanhan Liu
2017-07-04 8:37 ` Yuanhan Liu
2017-07-04 16:01 ` Hu, Jiayu
2017-07-01 11:08 ` [dpdk-dev] [PATCH v10 2/3] lib/gro: add TCP/IPv4 GRO support Jiayu Hu
2017-07-02 10:19 ` Tan, Jianfeng
2017-07-03 5:13 ` Hu, Jiayu
2017-07-04 9:03 ` Yuanhan Liu
2017-07-04 16:03 ` Hu, Jiayu
2017-07-01 11:08 ` [dpdk-dev] [PATCH v10 3/3] app/testpmd: enable TCP/IPv4 GRO Jiayu Hu
2017-07-05 4:08 ` [dpdk-dev] [PATCH v11 0/3] Support TCP/IPv4 GRO in DPDK Jiayu Hu
2017-07-05 4:08 ` [dpdk-dev] [PATCH v11 1/3] lib: add Generic Receive Offload API framework Jiayu Hu
2017-07-07 6:55 ` Tan, Jianfeng
2017-07-07 9:19 ` Tan, Jianfeng
2017-07-05 4:08 ` [dpdk-dev] [PATCH v11 2/3] lib/gro: add TCP/IPv4 GRO support Jiayu Hu
2017-07-07 6:55 ` Tan, Jianfeng
2017-07-05 4:08 ` [dpdk-dev] [PATCH v11 3/3] app/testpmd: enable TCP/IPv4 GRO Jiayu Hu
2017-07-07 10:39 ` [dpdk-dev] [PATCH v12 0/3] Support TCP/IPv4 GRO in DPDK Jiayu Hu
2017-07-07 10:39 ` [dpdk-dev] [PATCH v12 1/3] lib: add Generic Receive Offload API framework Jiayu Hu
2017-07-08 16:37 ` Tan, Jianfeng
2017-07-07 10:39 ` [dpdk-dev] [PATCH v12 2/3] lib/gro: add TCP/IPv4 GRO support Jiayu Hu
2017-07-08 16:37 ` Tan, Jianfeng
2017-07-07 10:39 ` [dpdk-dev] [PATCH v12 3/3] app/testpmd: enable TCP/IPv4 GRO Jiayu Hu
2017-07-09 1:13 ` [dpdk-dev] [PATCH v13 0/3] Support TCP/IPv4 GRO in DPDK Jiayu Hu
2017-07-09 1:13 ` [dpdk-dev] [PATCH v13 1/3] lib: add Generic Receive Offload API framework Jiayu Hu
2017-07-09 1:13 ` [dpdk-dev] [PATCH v13 2/3] lib/gro: add TCP/IPv4 GRO support Jiayu Hu
2017-07-09 1:13 ` [dpdk-dev] [PATCH v13 3/3] app/testpmd: enable TCP/IPv4 GRO Jiayu Hu
2017-07-09 5:46 ` [dpdk-dev] [PATCH v14 0/3] Support TCP/IPv4 GRO in DPDK Jiayu Hu
2017-07-09 5:46 ` [dpdk-dev] [PATCH v14 1/3] lib: add Generic Receive Offload API framework Jiayu Hu
2017-07-09 5:46 ` [dpdk-dev] [PATCH v14 2/3] lib/gro: add TCP/IPv4 GRO support Jiayu Hu
2017-07-09 5:46 ` [dpdk-dev] [PATCH v14 3/3] app/testpmd: enable TCP/IPv4 GRO Jiayu Hu
2017-07-09 7:59 ` Yao, Lei A
2017-07-09 16:14 ` [dpdk-dev] [PATCH v14 0/3] Support TCP/IPv4 GRO in DPDK Thomas Monjalon
2017-07-10 2:21 ` Hu, Jiayu
2017-07-10 7:03 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0C56AF3E-C8AB-4903-AD34-F39C6D74C889@intel.com \
--to=keith.wiles@intel.com \
--cc=bruce.richardson@intel.com \
--cc=cunming.liang@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=jiayu.hu@intel.com \
--cc=konstantin.ananyev@intel.com \
--cc=stephen@networkplumber.org \
--cc=thomas.monjalon@6wind.com \
--cc=yuanhan.liu@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).