From: Jiayu Hu <jiayu.hu@intel.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@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: Fri, 26 May 2017 15:26:13 +0800 [thread overview]
Message-ID: <20170526072613.GA85810@localhost.localdomain> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB9772583FAF9BAE@IRSMSX109.ger.corp.intel.com>
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.
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?
>
> >
> > >
> > > And if you like to keep them as helper functions:
> > >
> > > int rte_gro_port_enable(uint8_t port, struct rte_gro_tbl_param *param);
> > > void rte_gro_port_disable(uint8_t port);
> > >
> >
> > Though from my perspective, it is out of scope of that library,
> > > and I'd leave it to the upper layer to decide which callbacks and
> > > in what order have to be installed on particular port.
> >
> > In my opinion, GRO library includes two parts. One is in charge of reassembling
> > packets, the other is in charge of implementing GRO as RX callback. And
> > rte_gro_port_enable/disable belongs to the second part. You mean we should let
> > applications to register RX callback, and GRO library just provides reassembling
> > related functions (e.g. rte_gro_tbl_process and rte_gro_tbl_create)?
>
> Yes, that would be my preference.
> Let the application developer to decide how/when to
> call GRO functions (callback, direct call, some combination).
>
> >
> > >
> > > ....
> > >
> > > > diff --git a/lib/librte_gro/rte_gro.c b/lib/librte_gro/rte_gro.c
> > > > new file mode 100644
> > > > index 0000000..996b382
> > > > --- /dev/null
> > > > +++ b/lib/librte_gro/rte_gro.c
> > > > @@ -0,0 +1,219 @@
> > > > +#include <rte_ethdev.h>
> > > > +#include <rte_mbuf.h>
> > > > +#include <rte_hash.h>
> > > > +#include <stdint.h>
> > > > +#include <rte_malloc.h>
> > > > +
> > > > +#include "rte_gro.h"
> > > > +#include "rte_gro_common.h"
> > > > +
> > > > +gro_reassemble_fn reassemble_functions[GRO_TYPE_MAX_NB] = {NULL};
> > > > +gro_tbl_create_fn tbl_create_functions[GRO_TYPE_MAX_NB] = {NULL};
> > >
> > > Why not to initialize these arrays properly at building time (here)?
> >
> > Yes, I should declare them as static variables.
> >
> > >
> > > > +
> > > > +struct rte_gro_status *gro_status;
> > > > +
> > > > +/**
> > > > + * Internal function. It creates one hashing table for all
> > > > + * DPDK-supported GRO types, and all of them are stored in an object
> > > > + * of struct rte_gro_tbl.
> > > > + *
> > > > + * @param name
> > > > + * Name for GRO lookup table
> > > > + * @param nb_entries
> > > > + * Element number of each hashing table
> > > > + * @param socket_id
> > > > + * socket id
> > > > + * @param gro_tbl
> > > > + * gro_tbl points to a rte_gro_tbl object, which will be initalized
> > > > + * inside rte_gro_tbl_setup.
> > > > + * @return
> > > > + * If create successfully, return a positive value; if not, return
> > > > + * a negative value.
> > > > + */
> > > > +static int
> > > > +rte_gro_tbl_setup(char *name, uint32_t nb_entries,
> > > > + uint16_t socket_id, struct rte_gro_tbl *gro_tbl)
> > > > +{
> > > > + gro_tbl_create_fn create_tbl_fn;
> > > > + const uint32_t len = strlen(name) + 10;
> > > > + char tbl_name[len];
> > > > + int i;
> > > > +
> > > > + for (i = 0; i < GRO_SUPPORT_TYPE_NB; i++) {
> > > > + sprintf(tbl_name, "%s_%u", name, i);
> > > > + create_tbl_fn = tbl_create_functions[i];
> > > > + if (create_tbl_fn && (create_tbl_fn(name,
> > > > + nb_entries,
> > > > + socket_id,
> > > > + &(gro_tbl->
> > > > + lkp_tbls[i].hash_tbl))
> > > > + < 0)) {
> > >
> > > Shouldn't you destroy already created tables here?
> >
> > Yes, I should add codes to destory created tables before creating new ones.
> >
> > >
> > > > + return -1;
> > > > + }
> > > > + gro_tbl->lkp_tbls[i].gro_type = i;
> > > > + }
> > > > + return 1;
> > > > +}
> > > > +
> > > > +/**
> > > > + * Internal function. It frees all the hashing tables stored in
> > > > + * the given struct rte_gro_tbl object.
> > > > + */
> > > > +static void
> > > > +rte_gro_tbl_destroy(struct rte_gro_tbl *gro_tbl)
> > > > +{
> > > > + int i;
> > > > +
> > > > + if (gro_tbl == NULL)
> > > > + return;
> > > > + for (i = 0; i < GRO_SUPPORT_TYPE_NB; i++) {
> > > > + rte_hash_free(gro_tbl->lkp_tbls[i].hash_tbl);
> > > > + gro_tbl->lkp_tbls[i].hash_tbl = NULL;
> > > > + gro_tbl->lkp_tbls[i].gro_type = GRO_EMPTY_TYPE;
> > > > + }
> > > > +}
> > > > +
> > > > +/**
> > > > + * Internal function. It performs all supported GRO types on inputted
> > > > + * packets. For example, if current DPDK GRO supports TCP/IPv4 and
> > > > + * TCP/IPv6 GRO, this functions just reassembles TCP/IPv4 and TCP/IPv6
> > > > + * packets. Packets of unsupported GRO types won't be processed. For
> > > > + * ethernet devices, which want to support GRO, this function is used to
> > > > + * registered as RX callback for all queues.
> > > > + *
> > > > + * @param pkts
> > > > + * Packets to reassemble.
> > > > + * @param nb_pkts
> > > > + * The number of packets to reassemble.
> > > > + * @param gro_tbl
> > > > + * pointer points to an object of struct rte_gro_tbl, which has been
> > > > + * initialized by rte_gro_tbl_setup.
> > > > + * @return
> > > > + * Packet number after GRO. If reassemble successfully, the value is
> > > > + * less than nb_pkts; if not, the value is equal to nb_pkts. If the
> > > > + * parameters are invalid, return 0.
> > > > + */
> > > > +static uint16_t
> > > > +rte_gro_reassemble_burst(uint8_t port __rte_unused,
> > > > + uint16_t queue __rte_unused,
> > > > + struct rte_mbuf **pkts,
> > > > + uint16_t nb_pkts,
> > > > + uint16_t max_pkts __rte_unused,
> > > > + void *gro_tbl)
> > > > +{
> > > > + if ((gro_tbl == NULL) || (pkts == NULL)) {
> > > > + printf("invalid parameters for GRO.\n");
> > > > + return 0;
> > > > + }
> > > > + uint16_t nb_after_gro = nb_pkts;
> > >
> > > Here and everywhere - please move variable definitions to the top of the block.
> >
> > Thanks. I will modify them in next version.
> >
> > >
> > > > +
> > > > + return nb_after_gro;
> > > > +}
> > > > +
> > > > +void
> > > > +rte_gro_init(void)
> > > > +{
> > > > + uint8_t nb_port, i;
> > > > + uint16_t nb_queue;
> > > > + struct rte_eth_dev_info dev_info;
> > > > +
> > > > + /* if init already, return immediately */
> > > > + if (gro_status) {
> > > > + printf("repeatly init GRO environment\n");
> > > > + return;
> > > > + }
> > > > +
> > > > + gro_status = (struct rte_gro_status *)rte_zmalloc(
> > > > + NULL,
> > > > + sizeof(struct rte_gro_status),
> > > > + 0);
> > > > +
> > > > + nb_port = rte_eth_dev_count();
> > >
> > > Number of ports and number of configured queues per port can change dynamically.
> > > In fact, I don't think we need that function and global gro_status at all.
> > > To add/delete RX callback for particular port/queue - you can just scan over exisiting callbacks
> > > Searching for particular cb_func and cb_arg values.
> >
> > Yes, it's better to store these parameters (e.g. hashing table pointers) as cb_arg. But
> > we can't remove RX callback by searching for particular cb_func inside GRO library, since
> > these operations need locking protection and the lock variable (i.e. rte_eth_rx_cb_lock)
> > is unavailable to GRO library. To my knowledge, the only way is to provide a new API in
> > lib/librte_ether/rte_ethdev.c to support removing RX callback via cb_func or cb_arg values.
> > You mean we need to add this API?
>
> Yes my though was to add something like:
> rte_eth_find_rx_callback() /*find specific callback *./
> or rte_eth_remove_get_rx_callbacks() /*get a copy of list of all currently installed callback */
>
> But if we move installing GRO callbacks out of scope of the library, we probably wouldn't need it.
>
> >
> > >
> > > > + gro_status->ports = (struct gro_port_status *)rte_zmalloc(
> > > > + NULL,
> > > > + nb_port * sizeof(struct gro_port_status),
> > > > + 0);
> > > > + gro_status->nb_port = nb_port;
> > > > +
> > > > + for (i = 0; i < nb_port; i++) {
> > > > + rte_eth_dev_info_get(i, &dev_info);
> > > > + nb_queue = dev_info.nb_rx_queues;
> > > > + gro_status->ports[i].gro_tbls =
> > > > + (struct rte_gro_tbl **)rte_zmalloc(
> > > > + NULL,
> > > > + nb_queue * sizeof(struct rte_gro_tbl *),
> > > > + 0);
> > > > + gro_status->ports[i].gro_cbs =
> > > > + (struct rte_eth_rxtx_callback **)
> > > > + rte_zmalloc(
> > > > + NULL,
> > > > + nb_queue *
> > > > + sizeof(struct rte_eth_rxtx_callback *),
> > > > + 0);
> > > > + }
> > > > +}
> > > > +
> > > > +}
> > > ....
> > > > diff --git a/lib/librte_gro/rte_gro_common.h b/lib/librte_gro/rte_gro_common.h
> > > ....
> > >
> > > > +
> > > > +typedef int (*gro_tbl_create_fn)(
> > > > + char *name,
> > > > + uint32_t nb_entries,
> > > > + uint16_t socket_id,
> > > > + struct rte_hash **hash_tbl);
> > > > +
> > >
> > > If you have create_fn, then you'll probably need a destroy_fn too.
> > > Second thing why always assume that particular GRO implementation would
> > > always use rte_hash to store it's data?
> > > Probably better hide that inside something neutral, like 'struct gro_data;' or so.
> >
> > Agree. I will modify it.
> >
> > >
> > > > +typedef int32_t (*gro_reassemble_fn)(
> > > > + struct rte_hash *hash_tbl,
> > > > + struct gro_item_list *item_list);
> > > > +#endif
> > > > diff --git a/mk/rte.app.mk b/mk/rte.app.mk
> > > > index b5215c0..8956821 100644
> > > > --- a/mk/rte.app.mk
> > > > +++ b/mk/rte.app.mk
> > > > @@ -98,6 +98,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_RING) += -lrte_ring
> > > > _LDLIBS-$(CONFIG_RTE_LIBRTE_EAL) += -lrte_eal
> > > > _LDLIBS-$(CONFIG_RTE_LIBRTE_CMDLINE) += -lrte_cmdline
> > > > _LDLIBS-$(CONFIG_RTE_LIBRTE_REORDER) += -lrte_reorder
> > > > +_LDLIBS-$(CONFIG_RTE_LIBRTE_GRO) += -lrte_gro
> > > >
> > > > ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y)
> > > > _LDLIBS-$(CONFIG_RTE_LIBRTE_KNI) += -lrte_kni
> > > > --
> > > > 2.7.4
next prev parent reply other threads:[~2017-05-26 7:25 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 [this message]
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=20170526072613.GA85810@localhost.localdomain \
--to=jiayu.hu@intel.com \
--cc=dev@dpdk.org \
--cc=keith.wiles@intel.com \
--cc=konstantin.ananyev@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).