From: Thomas Monjalon <thomas@monjalon.net>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Cc: dev@dpdk.org, bruce.richardson@intel.com,
harry.van.haaren@intel.com, hemant.agrawal@nxp.com,
gage.eads@intel.com, nipun.gupta@nxp.com,
santosh.shukla@caviumnetworks.com
Subject: Re: [PATCH] ethdev: add lock-less txq capability flag
Date: Mon, 24 Apr 2017 14:34:59 +0200 [thread overview]
Message-ID: <1937111.PEUejtoCqE@xps> (raw)
In-Reply-To: <20170421122223.24194-1-jerin.jacob@caviumnetworks.com>
21/04/2017 14:22, Jerin Jacob:
> if this flag is advertised by a PMD, Multiple threads can
> invoke rte_eth_tx_burst() concurrently on the same tx queue
> without SW lock. This is an HW feature found in some NICs
> and useful in the following use cases if HW supports it.
Which hardware supports it?
[...]
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> +#define DEV_TX_OFFLOAD_TXQ_MT_LOCKFREE 0x00004000
> +/**< Multiple threads can invoke rte_eth_tx_burst() concurrently on the
> same + * tx queue without SW lock.
> + */
Why TXQ in the name? DEV_TX_OFFLOAD_MT_LOCKFREE would be enough.
I wonder whether "lock free" wording is confusing because
the locks are probably handled in HW.
I think the good wording is "offloaded multi-thread capability",
maybe with a naming like DEV_TX_OFFLOAD_MT.
Anyway we should reference this flag in rte_eth_tx_burst()
and give more details in doc/guides/prog_guide/poll_mode_drv.rst.
Should we wait a first hardware PoC to add this flag?
Candidate for 17.08?
next prev parent reply other threads:[~2017-04-24 12:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-21 12:22 [PATCH] ethdev: add lock-less txq capability flag Jerin Jacob
2017-04-24 12:34 ` Thomas Monjalon [this message]
2017-04-27 11:00 ` Jerin Jacob
2017-07-05 17:46 ` Thomas Monjalon
2017-07-06 6:00 ` Jerin Jacob
2017-07-06 6:21 ` [PATCH v2] ethdev: introduce lock-free " Jerin Jacob
2017-07-08 16:08 ` Thomas Monjalon
2017-07-10 16:56 ` Jerin Jacob
2017-07-10 16:59 ` [PATCH v3 ] " Jerin Jacob
2017-07-13 12:02 ` Hemant Agrawal
2017-07-18 13:43 ` Thomas Monjalon
2017-07-13 18:42 ` santosh
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=1937111.PEUejtoCqE@xps \
--to=thomas@monjalon.net \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=gage.eads@intel.com \
--cc=harry.van.haaren@intel.com \
--cc=hemant.agrawal@nxp.com \
--cc=jerin.jacob@caviumnetworks.com \
--cc=nipun.gupta@nxp.com \
--cc=santosh.shukla@caviumnetworks.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.