DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Kulasek, TomaszX" <tomaszx.kulasek@intel.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api
Date: Tue, 2 Feb 2016 10:00:41 +0000	[thread overview]
Message-ID: <3042915272161B4EB253DA4D77EB373A14E440C3@IRSMSX102.ger.corp.intel.com> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB97725836AE637C@irsmsx105.ger.corp.intel.com>

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 = rte_zmalloc("ethdev->txq_bufs",
> > +				sizeof(*dev->data->txq_bufs) * nb_queues, 0);
> > +		if (new_bufs == 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. 


> > +/**
> > + * @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.

Second one is better, I think.

Tomasz

  reply	other threads:[~2016-02-02 10:00 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-15 14:43 [dpdk-dev] [PATCH 0/2] add support for buffered tx to ethdev Tomasz Kulasek
2016-01-15 14:43 ` [dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api Tomasz Kulasek
2016-01-15 18:13   ` Stephen Hemminger
2016-01-15 18:14   ` Stephen Hemminger
2016-01-15 18:44   ` Ananyev, Konstantin
2016-02-02 10:00     ` Kulasek, TomaszX [this message]
2016-02-02 13:49       ` Ananyev, Konstantin
2016-02-09 17:02         ` Kulasek, TomaszX
2016-02-09 23:56           ` Ananyev, Konstantin
2016-02-12 11:44             ` Ananyev, Konstantin
2016-02-12 16:40               ` Ivan Boule
2016-02-12 17:33                 ` Bruce Richardson
2016-01-15 14:43 ` [dpdk-dev] [PATCH 2/2] examples: sample apps rework to use " Tomasz Kulasek
2016-01-15 18:12 ` [dpdk-dev] [PATCH 0/2] add support for buffered tx to ethdev Stephen Hemminger
2016-02-24 17:08 ` [dpdk-dev] [PATCH v2 " Tomasz Kulasek
2016-02-24 17:08   ` [dpdk-dev] [PATCH v2 1/2] ethdev: add buffered tx api Tomasz Kulasek
2016-03-08 22:52     ` Thomas Monjalon
2016-03-09 13:36       ` Ananyev, Konstantin
2016-03-09 14:25         ` Thomas Monjalon
2016-03-09 15:23           ` Ananyev, Konstantin
2016-03-09 15:26             ` Thomas Monjalon
2016-03-09 15:32               ` Kulasek, TomaszX
2016-03-09 15:37                 ` Thomas Monjalon
2016-03-09 15:42               ` Ananyev, Konstantin
2016-03-09 15:52                 ` Thomas Monjalon
2016-03-09 16:17                   ` Ananyev, Konstantin
2016-03-09 16:21                     ` Thomas Monjalon
2016-03-09 16:35       ` Kulasek, TomaszX
2016-03-09 17:06         ` Thomas Monjalon
2016-03-09 18:12           ` Kulasek, TomaszX
2016-02-24 17:08   ` [dpdk-dev] [PATCH v2 2/2] examples: rework to use " Tomasz Kulasek
2016-02-25 16:17   ` [dpdk-dev] [PATCH v2 0/2] add support for buffered tx to ethdev Ananyev, Konstantin
2016-03-10 10:57   ` [dpdk-dev] [PATCH v3 " Tomasz Kulasek
2016-03-10 10:57     ` [dpdk-dev] [PATCH v3 1/2] ethdev: add buffered tx api Tomasz Kulasek
2016-03-10 16:23       ` Thomas Monjalon
2016-03-10 17:15         ` Kulasek, TomaszX
2016-03-10 10:57     ` [dpdk-dev] [PATCH v3 2/2] examples: rework to use buffered tx Tomasz Kulasek
2016-03-10 11:31     ` [dpdk-dev] [PATCH v3 0/2] add support for buffered tx to ethdev Ananyev, Konstantin
2016-03-10 16:01       ` Jastrzebski, MichalX K
2016-03-10 17:19     ` [dpdk-dev] [PATCH v4 " Tomasz Kulasek
2016-03-10 17:19       ` [dpdk-dev] [PATCH v4 1/2] ethdev: add buffered tx api Tomasz Kulasek
2016-03-10 17:19       ` [dpdk-dev] [PATCH v4 2/2] examples: rework to use buffered tx Tomasz Kulasek
2016-03-11 16:39       ` [dpdk-dev] [PATCH v4 0/2] add support for buffered tx to ethdev Thomas Monjalon
  -- strict thread matches above, loose matches on Subject: below --
2016-01-15 14:26 [dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api Tomasz Kulasek

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=3042915272161B4EB253DA4D77EB373A14E440C3@IRSMSX102.ger.corp.intel.com \
    --to=tomaszx.kulasek@intel.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.ananyev@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).