From: Thomas Monjalon <thomas@monjalon.net>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Cc: dev@dpdk.org, ferruh.yigit@intel.com, john.mcnamara@intel.com
Subject: Re: [PATCH v2] ethdev: introduce lock-free txq capability flag
Date: Sat, 08 Jul 2017 18:08:57 +0200 [thread overview]
Message-ID: <187460180.BTNh70yjrI@xps> (raw)
In-Reply-To: <20170706062120.3895-1-jerin.jacob@caviumnetworks.com>
Hi Jerin,
Thanks for the update.
I think we can add this new flag in 17.08.
I prefer waiting John's review, especially for doc wording,
before applying it. I consider it does not hurt to add it post-rc1.
See below for my first comment on the doc.
06/07/2017 08:21, Jerin Jacob:
> Introducing the DEV_TX_OFFLOAD_MT_LOCKFREE TX capability flag.
> if a PMD advertises DEV_TX_OFFLOAD_MT_LOCKFREE capable, multiple threads
> can invoke rte_eth_tx_burst() concurrently on the same tx queue without
> SW lock. This PMD feature will be useful in the following use cases and
> found in the OCTEON family of NPUs.
>
> 1) Remove explicit spinlock in some applications where lcores
> to TX queues are not mapped 1:1.
> example: OVS has such instance
> https://github.com/openvswitch/ovs/blob/master/lib/netdev-dpdk.c#L299
> https://github.com/openvswitch/ovs/blob/master/lib/netdev-dpdk.c#L1859
> See the the usage of tx_lock spinlock.
>
> 2) In the eventdev use case, Avoid dedicating a separate TX core for
> transmitting and thus enables more scaling as all workers can
> send the packets.
>
> v2:
> - Changed the flag name to DEV_TX_OFFLOAD_MT_LOCKFREE(Thomas)
> - Updated the documentation in doc/guides/prog_guide/poll_mode_drv.rst
> and rte_eth_tx_burst() doxgen comments(Thomas)
>
> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> ---
[...]
> +If the PMD is ``DEV_TX_OFFLOAD_MT_LOCKFREE`` capable, multiple threads can invoke ``rte_eth_tx_burst()``
> +concurrently on the same tx queue without SW lock.This PMD feature found in some NICs and
A space is missing after the dot.
Note: my preference is to start next sentence on a new line (in RST source).
> +useful in the following use cases if PMD supports it. See `Hardware Offload`_ for details.
This sentence is confusing. I would remove "if PMD supports it".
After "following use cases", should we add a colon?
The relation with `Hardware Offload`_ is not obvious.
> +* Remove explicit spinlock in some applications where lcores to TX queues are not mapped 1:1.
Can we reword "lcores to TX queues"?
I suggest "lcores are not mapped to Tx queues with 1:1 relation".
> +* In the eventdev use case, Avoid dedicating a separate TX core for transmitting and thus
Uppercase in the middle of the sentence spotted.
> + enables more scaling as all workers can send the packets.
next prev parent reply other threads:[~2017-07-08 16:08 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
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 [this message]
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=187460180.BTNh70yjrI@xps \
--to=thomas@monjalon.net \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=jerin.jacob@caviumnetworks.com \
--cc=john.mcnamara@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 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.