DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: "Walukiewicz, Miroslaw" <Miroslaw.Walukiewicz@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCHv2 0/5] ethdev: add new API to retrieve RX/TX	queue information
Date: Thu, 18 Jun 2015 14:17:14 +0000	[thread overview]
Message-ID: <2601191342CEEE43887BDE71AB97725836A1389C@irsmsx105.ger.corp.intel.com> (raw)
In-Reply-To: <7C4248CAE043B144B1CD242D27562653454ABD61@IRSMSX104.ger.corp.intel.com>

Hi Mirek,

> -----Original Message-----
> From: Walukiewicz, Miroslaw
> Sent: Thursday, June 18, 2015 2:31 PM
> To: Ananyev, Konstantin; dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCHv2 0/5] ethdev: add new API to retrieve RX/TX queue information
> 
> Konstantin,
> 
> Is there a possibility to read information about available space in NIC queue for TX.

I suppose it is possible as some future addition.
As I said in the commit message, I left some reserved space, so extra fields could be added to the structure without ABI breakage.
For now, I just added some static/config information for the queue, but I think it is possible and plausible to have some runtime information too.

> 
> It is quite easy to compute (or even available directly)  and very useful especially for application sending multi-descriptor packets like
> TCP TSO.
> 
> Now there is no access to such information and the transmit packet function must be called to
> be sure that there is available space.

Hmm, as I said I was thinking about adding some RT information in future:
number of free descriptors (from SW point of view), index of next descriptor to process by SW, etc.
But my thought it would be use by some watchdog thread to collect statistics/detect stall, etc.
I didn't intend it to be used by IO thread. 

I am not sure why do you need to call such function at RT?
PMD wouldn't TX a packet, if there is not enough free TXDs for the whole packet.
>From other side upper layer, can't always calculate correctly how many TXD it would really need
(context descriptors might be needed, etc).
 Plus, even if nb_tx_free==X, in reality it could be there much more free TXDs, and SW just need
to process them (and would do that at next  tx_burst() call.
So, why just not:
...
n = tx_burst(..., nb_tx);
if (n < nb_tx) {requeue unsent of packets;}
?

Konstantin

> 
> Mirek
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Konstantin Ananyev
> > Sent: Thursday, June 18, 2015 3:19 PM
> > To: dev@dpdk.org
> > Subject: [dpdk-dev] [PATCHv2 0/5] ethdev: add new API to retrieve RX/TX
> > queue information
> >
> > Add the ability for the upper layer to query RX/TX queue information.
> > Right now supported for:
> > ixgbe, i40e, e1000 PMDs.
> >
> > Konstantin Ananyev (5):
> >   ethdev: add new API to retrieve RX/TX queue information
> >   i40e: add support for eth_(rxq|txq)_info_get
> >   ixgbe: add support for eth_(rxq|txq)_info_get
> >   e1000: add support for eth_(rxq|txq)_info_get
> >   testpmd: add new command to display RX/TX queue information
> >
> >  app/test-pmd/cmdline.c           | 48 +++++++++++++++++++++++++
> >  app/test-pmd/config.c            | 67
> > ++++++++++++++++++++++++++++++++++
> >  app/test-pmd/testpmd.h           |  2 ++
> >  drivers/net/e1000/e1000_ethdev.h | 12 +++++++
> >  drivers/net/e1000/em_ethdev.c    |  2 ++
> >  drivers/net/e1000/em_rxtx.c      | 38 ++++++++++++++++++++
> >  drivers/net/e1000/igb_ethdev.c   |  4 +++
> >  drivers/net/e1000/igb_rxtx.c     | 36 +++++++++++++++++++
> >  drivers/net/i40e/i40e_ethdev.c   |  2 ++
> >  drivers/net/i40e/i40e_ethdev.h   |  5 +++
> >  drivers/net/i40e/i40e_rxtx.c     | 42 ++++++++++++++++++++++
> >  drivers/net/ixgbe/ixgbe_ethdev.c |  4 +++
> >  drivers/net/ixgbe/ixgbe_ethdev.h |  6 ++++
> >  drivers/net/ixgbe/ixgbe_rxtx.c   | 42 ++++++++++++++++++++++
> >  lib/librte_ether/rte_ethdev.c    | 54 ++++++++++++++++++++++++++++
> >  lib/librte_ether/rte_ethdev.h    | 77
> > +++++++++++++++++++++++++++++++++++++++-
> >  16 files changed, 440 insertions(+), 1 deletion(-)
> >
> > --
> > 1.8.5.3

  parent reply	other threads:[~2015-06-18 14:17 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-17 16:54 [dpdk-dev] [PATCH " Konstantin Ananyev
2015-06-17 16:54 ` [dpdk-dev] [PATCH 1/5] " Konstantin Ananyev
2015-06-18 13:18   ` [dpdk-dev] [PATCHv2 0/5] " Konstantin Ananyev
2015-06-18 13:18     ` [dpdk-dev] [PATCHv2 1/5] " Konstantin Ananyev
2015-07-20  0:12       ` Thomas Monjalon
2015-07-20  9:52         ` Ananyev, Konstantin
2015-06-18 13:18     ` [dpdk-dev] [PATCHv2 2/5] i40e: add support for eth_(rxq|txq)_info_get Konstantin Ananyev
2015-06-18 13:18     ` [dpdk-dev] [PATCHv2 3/5] ixgbe: " Konstantin Ananyev
2015-06-18 13:18     ` [dpdk-dev] [PATCHv2 4/5] e1000: " Konstantin Ananyev
2015-06-18 13:18     ` [dpdk-dev] [PATCHv2 5/5] testpmd: add new command to display RX/TX queue information Konstantin Ananyev
2015-06-18 13:30     ` [dpdk-dev] [PATCHv2 0/5] ethdev: add new API to retrieve " Walukiewicz, Miroslaw
2015-06-18 13:39       ` Bruce Richardson
2015-06-18 13:56         ` Walukiewicz, Miroslaw
2015-06-18 14:13           ` Bruce Richardson
2015-06-18 14:17       ` Ananyev, Konstantin [this message]
2015-06-18 14:37         ` Walukiewicz, Miroslaw
2015-06-18 13:58     ` Bruce Richardson
2015-06-19  3:18     ` Zhang, Helin
2015-06-23 12:35     ` David Harton (dharton)
2015-06-17 16:54 ` [dpdk-dev] [PATCH 2/5] i40e: add support for eth_(rx|tx)_qinfo_get Konstantin Ananyev
2015-06-17 16:54 ` [dpdk-dev] [PATCH 3/5] ixgbe: " Konstantin Ananyev
2015-06-17 16:54 ` [dpdk-dev] [PATCH 4/5] e1000: " Konstantin Ananyev
2015-06-17 16:54 ` [dpdk-dev] [PATCH 5/5] testpmd: add new command to display RX/TX queue information Konstantin Ananyev

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=2601191342CEEE43887BDE71AB97725836A1389C@irsmsx105.ger.corp.intel.com \
    --to=konstantin.ananyev@intel.com \
    --cc=Miroslaw.Walukiewicz@intel.com \
    --cc=dev@dpdk.org \
    /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).