From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: "Hu, Jiayu" <jiayu.hu@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"Wiles, Keith" <keith.wiles@intel.com>,
"yuanhan.liu@linux.intel.com" <yuanhan.liu@linux.intel.com>
Subject: Re: [dpdk-dev] [PATCH v3 1/3] lib: add Generic Receive Offload API framework
Date: Mon, 29 May 2017 12:51:43 +0000 [thread overview]
Message-ID: <2601191342CEEE43887BDE71AB9772583FB02F85@IRSMSX109.ger.corp.intel.com> (raw)
In-Reply-To: <ED946F0BEFE0A141B63BABBD629A2A9B3876017C@shsmsx102.ccr.corp.intel.com>
Hi Jiayu,
> -----Original Message-----
> From: Hu, Jiayu
> Sent: Monday, May 29, 2017 11:23 AM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: dev@dpdk.org; Wiles, Keith <keith.wiles@intel.com>; yuanhan.liu@linux.intel.com
> Subject: RE: [PATCH v3 1/3] lib: add Generic Receive Offload API framework
>
> Hi Konstantin,
>
> > -----Original Message-----
> > From: Ananyev, Konstantin
> > Sent: Sunday, May 28, 2017 12:51 AM
> > To: Hu, Jiayu <jiayu.hu@intel.com>
> > Cc: dev@dpdk.org; Wiles, Keith <keith.wiles@intel.com>;
> > yuanhan.liu@linux.intel.com
> > Subject: RE: [PATCH v3 1/3] lib: add Generic Receive Offload API framework
> >
> >
> > Hi Jiayu,
> >
> > >
> > > Hi Konstantin,
> > >
> > > On Sat, May 27, 2017 at 07:12:16PM +0800, Ananyev, Konstantin wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Hu, Jiayu
> > > > > Sent: Saturday, May 27, 2017 4:42 AM
> > > > > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > > > > Cc: dev@dpdk.org; Wiles, Keith <keith.wiles@intel.com>;
> > yuanhan.liu@linux.intel.com
> > > > > Subject: Re: [PATCH v3 1/3] lib: add Generic Receive Offload API
> > framework
> > > > >
> > > > > On Sat, May 27, 2017 at 07:10:21AM +0800, Ananyev, Konstantin wrote:
> > > > > > Hi Jiayu,
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Hu, Jiayu
> > > > > > > Sent: Friday, May 26, 2017 8:26 AM
> > > > > > > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > > > > > > Cc: dev@dpdk.org; Wiles, Keith <keith.wiles@intel.com>;
> > yuanhan.liu@linux.intel.com
> > > > > > > Subject: Re: [PATCH v3 1/3] lib: add Generic Receive Offload API
> > framework
> > > > > > >
> > > > > > > Hi Konstantin,
> > > > > > >
> > > > > > > On Wed, May 24, 2017 at 08:38:25PM +0800, Ananyev, Konstantin
> > wrote:
> > > > > > > >
> > > > > > > > Hi Jiayu,
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Hi Konstantin,
> > > > > > > > >
> > > > > > > > > Thanks for your comments. My replies/questions are below.
> > > > > > > > >
> > > > > > > > > BRs,
> > > > > > > > > Jiayu
> > > > > > > > >
> > > > > > > > > On Mon, May 22, 2017 at 05:19:19PM +0800, Ananyev,
> > Konstantin wrote:
> > > > > > > > > > Hi Jiayu,
> > > > > > > > > > My comments/questions below.
> > > > > > > > > > Konstantin
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > For applications, DPDK GRO provides three external functions
> > to
> > > > > > > > > > > enable/disable GRO:
> > > > > > > > > > > - rte_gro_init: initialize GRO environment;
> > > > > > > > > > > - rte_gro_enable: enable GRO for a given port;
> > > > > > > > > > > - rte_gro_disable: disable GRO for a given port.
> > > > > > > > > > > Before using GRO, applications should explicitly call
> > rte_gro_init to
> > > > > > > > > > > initizalize GRO environment. After that, applications can call
> > > > > > > > > > > rte_gro_enable to enable GRO and call rte_gro_disable to
> > disable GRO for
> > > > > > > > > > > specific ports.
> > > > > > > > > >
> > > > > > > > > > I think this is too restrictive and wouldn't meet various user's
> > needs.
> > > > > > > > > > User might want to:
> > > > > > > > > > - enable/disable GRO for particular RX queue
> > > > > > > > > > - or even setup different GRO types for different RX queues,
> > > > > > > > > > i.e, - GRO over IPV4/TCP for queue 0, and GRO over
> > IPV6/TCP for queue 1, etc.
> > > > > > > > >
> > > > > > > > > The reason for enabling/disabling GRO per-port instead of per-
> > queue is that LINUX
> > > > > > > > > controls GRO per-port. To control GRO per-queue indeed can
> > provide more flexibility
> > > > > > > > > to applications. But are there any scenarios that different
> > queues of a port may
> > > > > > > > > require different GRO control (i.e. GRO types and enable/disable
> > GRO)?
> > > > > > > >
> > > > > > > > I think yes.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > - For various reasons, user might prefer not to use RX callbacks
> > for various reasons,
> > > > > > > > > > But invoke gro() manually at somepoint in his code.
> > > > > > > > >
> > > > > > > > > An application-used GRO library can enable more flexibility to
> > applications. Besides,
> > > > > > > > > when perform GRO in ethdev layer or inside PMD drivers, it is an
> > issue that
> > > > > > > > > rte_eth_rx_burst returns actually received packet number or
> > GROed packet number. And
> > > > > > > > > the same issue happens in GSO, and even more seriously. This is
> > because applications
> > > > > > > > > , like VPP, always rely on the return value of rte_eth_tx_burst to
> > decide further
> > > > > > > > > operations. If applications can direcly call GRO/GSO libraries,
> > this issue won't exist.
> > > > > > > > > And DPDK is a library, which is not a holistic system like LINUX.
> > We don't need to do
> > > > > > > > > the same as LINUX. Therefore, maybe it's a better idea to
> > directly provide SW
> > > > > > > > > segmentation/reassembling libraries to applications.
> > > > > > > > >
> > > > > > > > > > - Many users would like to control size (number of flows/items
> > per flow),
> > > > > > > > > > max allowed packet size, max timeout, etc., for different GRO
> > tables.
> > > > > > > > > > - User would need a way to flush all or only timeout packets
> > from particular GRO tables.
> > > > > > > > > >
> > > > > > > > > > So I think that API needs to extended to become be much more
> > fine-grained.
> > > > > > > > > > Something like that:
> > > > > > > > > >
> > > > > > > > > > struct rte_gro_tbl_param {
> > > > > > > > > > int32_t socket_id;
> > > > > > > > > > size_t max_flows;
> > > > > > > > > > size_t max_items_per_flow;
> > > > > > > > > > size_t max_pkt_size;
> > > > > > > > > > uint64_t packet_timeout_cycles;
> > > > > > > > > > <desired GRO types (IPV4_TCP | IPV6_TCP, ...)>
> > > > > > > > > > <probably type specific params>
> > > > > > > > > > ...
> > > > > > > > > > };
> > > > > > > > > >
> > > > > > > > > > struct rte_gro_tbl;
> > > > > > > > > > strct rte_gro_tbl *rte_gro_tbl_create(const struct
> > rte_gro_tbl_param *param);
> > > > > > > > > >
> > > > > > > > > > void rte_gro_tbl_destroy(struct rte_gro_tbl *tbl);
> > > > > > > > >
> > > > > > > > > Yes, I agree with you. It's necessary to provide more fine-
> > grained control APIs to
> > > > > > > > > applications. But what's 'packet_timeout_cycles' used for? Is it
> > for TCP packets?
> > > > > > > >
> > > > > > > > For any packets that sits in the gro_table for too long.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > /*
> > > > > > > > > > * process packets, might store some packets inside the GRO
> > table,
> > > > > > > > > > * returns number of filled entries in pkt[]
> > > > > > > > > > */
> > > > > > > > > > uint32_t rte_gro_tbl_process(struct rte_gro_tbl *tbl, struct
> > rte_mbuf *pkt[], uint32_t num);
> > > > > > > > > >
> > > > > > > > > > /*
> > > > > > > > > > * retirieves up to num timeouted packets from the table.
> > > > > > > > > > */
> > > > > > > > > > uint32_t rtre_gro_tbl_timeout(struct rte_gro_tbl *tbl, uint64_t
> > tmt, struct rte_mbuf *pkt[], uint32_t num);
> > > > > > > > >
> > > > > > > > > Currently, we implement GRO as RX callback, whose processing
> > logic is simple:
> > > > > > > > > receive burst packets -> perform GRO -> return to application.
> > GRO stops after
> > > > > > > > > finishing processing received packets. If we provide
> > rte_gro_tbl_timeout, when
> > > > > > > > > and who will call it?
> > > > > > > >
> > > > > > > > I mean the following scenario:
> > > > > > > > We receive a packet, find it is eligible for GRO and put it into
> > gro_table
> > > > > > > > in expectation - there would be more packets for the same flow.
> > > > > > > > But it could happen that we would never (or for some long time)
> > receive
> > > > > > > > any new packets for that flow.
> > > > > > > > So the first packet would never be delivered to the upper layer,
> > > > > > > > or delivered too late.
> > > > > > > > So we need a mechanism to extract such not merged packets
> > > > > > > > and push them to the upper layer.
> > > > > > > > My thought it would be application responsibility to call it from
> > time to time.
> > > > > > > > That's actually another reason why I think we shouldn't use
> > application
> > > > > > > > to always use RX callbacks for GRO.
> > > > > > >
> > > > > > > Currently, we only provide one reassembly function,
> > rte_gro_reassemble_burst,
> > > > > > > which merges N inputted packets at a time. After finishing
> > processing these
> > > > > > > packets, it returns all of them and reset hashing tables. Therefore,
> > there
> > > > > > > are no packets in hashing tables after rte_gro_reassemble_burst
> > returns.
> > > > > >
> > > > > > Ok, sorry I missed that part with rte_hash_reset().
> > > > > > So gro_ressemble_burst() performs only inline processing on current
> > input packets
> > > > > > and doesn't try to save packets for future merging, correct?
> > > > >
> > > > > Yes.
> > > > >
> > > > > > Such approach indeed is much lightweight and doesn't require any
> > extra timeouts and flush().
> > > > > > So my opinion let's keep it like that - nice and simple.
> > > > > > BTW, I think in that case we don't need any hashtables (or any other
> > persistent strucures)at all.
> > > > > > What we need is just a set of GROs (tcp4, tpc6, etc.) we want to
> > perform on given array of packets.
> > > > >
> > > > > Beside GRO types that are desired to perform, maybe it also needs
> > max_pkt_size and
> > > > > some GRO type specific information?
> > > >
> > > > Yes, but we don't need the actual hash-tables, etc. inside.
> > > > Passing something like struct gro_param seems enough.
> > >
> > > Yes, we can just pass gro_param and allocate hashing tables
> > > inside rte_gro_reassemble_burst. If so, hashing tables of
> > > desired GRO types are created and freed in each invocation
> > > of rte_gro_reassemble_burst. In GRO library, hashing tables
> > > are created by GRO type specific gro_tbl_create_fn. These
> > > gro_tbl_create_fn may allocate hashing table space via malloc
> > > (or rte_malloc). Therefore, we may frequently call malloc/free
> > > when using rte_gro_reassemble_burst. In my opinion, it will
> > > degrade GRO performance greatly.
> >
> > I don't' understand why do we need to put/extract each packet into/from
> > hash table at all.
> > We have N input packets that need to be grouped/sorted by some criteria.
> > Surely that can be done without any hash-table involved.
> > What is the need for hash table and all the overhead it brings here?
>
> In current design, I assume all GRO types use hash tables to merge
> packets. The key of the hash table is the criteria to merge packets.
> So the main difference for different GRO types' hash tables is the
> key definition.
>
> And the reason for using hash tables is to speed up reassembly. Given
> There are N TCP packets inputted, the simplest way to process packets[i]
> Is to traverse processed packets[0]~packets[i-1] and try to find a one
> to merge. In the worst case, we need to check all of packets[0~i-1].
> In this case, the time complexity of processing N packets is O(N^2).
> If we use a hash table, whose key is the criteria to merge two packets,
> the time to find a packet that may be merged with packets[i] is O(1).
I understand that, but add/search inside the hash table,
plus resetting it for every burst of packets doesn't come for free also.
I think that for most common burst sizes (< 100 packets)
hash overhead would significantly overweight the price of
worst case O(N^2) scan.
Also, if such worst case really worries you, you can pre-sort
input packets first before starting the actual reassemble for them.
That might help to bring the price down.
Konstantin
>
> Do you think it's too complicated?
>
> Jiayu
>
> > Konstantin
> >
> > >
> > > But if we ask applications to input hashing tables, what we
> > > need to do is to reset them after finishing using in
> > > rte_gro_reassemble_burst, rather than to malloc and free each
> > > time. Therefore, I think this way is more efficient. How do you
> > > think?
> > >
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > If we provide rte_gro_tbl_timeout, we also need to provide another
> > reassmebly
> > > > > > > function, like rte_gro_reassemble, which processes one given
> > packet at a
> > > > > > > time and won't reset hashing tables. Applications decide when to
> > flush packets
> > > > > > > in hashing tables. And rte_gro_tbl_timeout is one of the ways that
> > can be used
> > > > > > > to flush the packets. Do you mean that?
> > > > > >
> > > > > > Yes, that's what I meant, but as I said above - I think your approach is
> > probably
> > > > > > more preferable - it is much simpler and lightweight.
> > > > > > Konstantin
> > > > > >
next prev parent reply other threads:[~2017-05-29 12:52 UTC|newest]
Thread overview: 141+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-22 9:32 [dpdk-dev] [PATCH 0/2] lib: add TCP IPv4 GRO support 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
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 [this message]
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=2601191342CEEE43887BDE71AB9772583FB02F85@IRSMSX109.ger.corp.intel.com \
--to=konstantin.ananyev@intel.com \
--cc=dev@dpdk.org \
--cc=jiayu.hu@intel.com \
--cc=keith.wiles@intel.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).