From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 7225C256 for ; Tue, 9 Feb 2016 18:04:06 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP; 09 Feb 2016 09:02:49 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,421,1449561600"; d="scan'208";a="649633190" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by FMSMGA003.fm.intel.com with ESMTP; 09 Feb 2016 09:02:49 -0800 Received: from irsmsx155.ger.corp.intel.com (163.33.192.3) by IRSMSX153.ger.corp.intel.com (163.33.192.75) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 9 Feb 2016 17:02:47 +0000 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.97]) by irsmsx155.ger.corp.intel.com ([169.254.14.217]) with mapi id 14.03.0248.002; Tue, 9 Feb 2016 17:02:47 +0000 From: "Kulasek, TomaszX" To: "Ananyev, Konstantin" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api Thread-Index: AQHRT6NciIz4F4C8P0moMmFWu8Y42Z786lAAgAq1fvCAEUIZAIALJMZg Date: Tue, 9 Feb 2016 17:02:47 +0000 Message-ID: <3042915272161B4EB253DA4D77EB373A14E46576@IRSMSX102.ger.corp.intel.com> References: <1452869038-9140-1-git-send-email-tomaszx.kulasek@intel.com> <1452869038-9140-2-git-send-email-tomaszx.kulasek@intel.com> <2601191342CEEE43887BDE71AB97725836AE637C@irsmsx105.ger.corp.intel.com> <3042915272161B4EB253DA4D77EB373A14E440C3@IRSMSX102.ger.corp.intel.com> <2601191342CEEE43887BDE71AB97725836B024AC@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB97725836B024AC@irsmsx105.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 17:04:07 -0000 > -----Original Message----- > From: Ananyev, Konstantin > Sent: Tuesday, February 2, 2016 14:50 > To: Kulasek, TomaszX ; dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api >=20 > Hi Tomasz, >=20 > > -----Original Message----- > > From: Kulasek, TomaszX > > Sent: Tuesday, February 02, 2016 10:01 AM > > To: Ananyev, Konstantin; dev@dpdk.org > > Subject: RE: [dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api > > > > Hi Konstantin, > > > > > -----Original Message----- > > > From: Ananyev, Konstantin > > > Sent: Friday, January 15, 2016 19:45 > > > To: Kulasek, TomaszX; dev@dpdk.org > > > Subject: RE: [dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api > > > > > > Hi Tomasz, > > > > > > > > > > > + /* get new buffer space first, but keep old space around > */ > > > > + new_bufs =3D rte_zmalloc("ethdev->txq_bufs", > > > > + sizeof(*dev->data->txq_bufs) * nb_queues, 0); > > > > + if (new_bufs =3D=3D NULL) > > > > + return -(ENOMEM); > > > > + > > > > > > Why not to allocate space for txq_bufs together with tx_queues (as > > > one chunk for both)? > > > As I understand there is always one to one mapping between them > anyway. > > > Would simplify things a bit. > > > Or even introduce a new struct to group with all related tx queue > > > info togetehr struct rte_eth_txq_data { > > > void *queue; /*actual pmd queue*/ > > > struct rte_eth_dev_tx_buffer buf; > > > uint8_t state; > > > } > > > And use it inside struct rte_eth_dev_data? > > > Would probably give a better data locality. > > > > > > > Introducing such a struct will require a huge rework of pmd drivers. I > don't think it's worth only for this one feature. >=20 > Why not? > Things are getting more and more messy here: now we have a separate array > of pointer to queues, Separate array of queue states, you are going to ad= d > separate array of tx buffers. > For me it seems logical to unite all these 3 fields into one sub-struct. >=20 I agree with you, and probably such a work will be nice also for rx queues,= but these two changes impacts on another part of dpdk. While buffered tx A= PI is more client application helper. For me these two thinks are different features and should be made separatel= y because: 1) They are independent and can be done separately, 2) They can (and should) be reviewed, tested and approved separately, 3) They are addressed to another type of people (tx buffering to applicatio= n developers, rte_eth_dev_data to pmd developers), so another people can be= interested in having (or not) one or second feature Even for bug tracking it will be cleaner to separate these two things. And = yes, it is logical to unite it, maybe also for rx queues, but should be dis= cussed separately. I've made a prototype with this rework, and the impact on the code not rela= ted to this particular feature is too wide and strong to join them. I would= rather to provide it as independent patch for further discussion only on i= t, if needed. > > > > > > > > +/** > > > > + * @internal > > > > + * Structure used to buffer packets for future TX > > > > + * Used by APIs rte_eth_tx_buffer and rte_eth_tx_buffer_flush */ > > > > +struct rte_eth_dev_tx_buffer { > > > > + struct rte_mbuf *pkts[RTE_ETHDEV_TX_BUFSIZE]; > > > > > > I think it is better to make size of pkts[] configurable at runtime. > > > There are a lot of different usage scenarios - hard to predict what > > > would be an optimal buffer size for all cases. > > > > > > > This buffer is allocated in eth_dev shared memory, so there are two > scenarios: > > 1) We have prealocated buffer with maximal size, and then we can set > > threshold level without restarting device, or > > 2) We need to set its size before starting device. >=20 > > > > Second one is better, I think. >=20 > Yep, I was thinking about 2) too. > Might be an extra parameter in struct rte_eth_txconf. >=20 Struct rte_eth_txconf is passed to ethdev after rte_eth_dev_tx_queue_config= , so we don't know its value when buffers are allocated. I'm looking for another solution. > > > > Tomasz