DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Venkatesan, Venky" <venky.venkatesan@intel.com>
To: "John W. Linville" <linville@tuxdriver.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices
Date: Fri, 11 Jul 2014 16:29:11 +0000	[thread overview]
Message-ID: <1FD9B82B8BF2CF418D9A1000154491D974124768@ORSMSX102.amr.corp.intel.com> (raw)
In-Reply-To: <20140711153309.GD25478@tuxdriver.com>

On Fri, Jul 11, 2014 at 03:29:17PM +0000, Venkatesan, Venky wrote:
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of John W. 
> > Linville
> > Sent: Friday, July 11, 2014 7:49 AM
> > To: Stephen Hemminger
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for
> > AF_PACKET- based virtual devices
> > 
> > On Fri, Jul 11, 2014 at 06:11:47AM -0700, Stephen Hemminger wrote:
> > > On Thu, 10 Jul 2014 16:32:49 -0400 "John W. Linville" 
> > > <linville@tuxdriver.com> wrote:
> > >
> > > > This is a Linux-specific virtual PMD driver backed by an 
> > > > AF_PACKET

<snip>

> > > > +struct pkt_rx_queue {
> > > > +	int sockfd;
> > > > +
> > > > +	struct iovec *rd;
> > > > +	uint8_t *map;
> > > > +	unsigned int framecount;
> > > > +	unsigned int framenum;
> > > > +
> > > > +	struct rte_mempool *mb_pool;
> > > > +
> > > > +	volatile unsigned long rx_pkts;
> > > > +	volatile unsigned long err_pkts;
> > >
> > > Use of volatile will generate slow code, don't think it is 
> > > necessary, especially when only one CPU can use a queue at a time.
> > 
> > That is a good point, worth checking out.  FWIW, those lines are 
> > boilerplate originally copied from the pcap PMD. :-)
> > 
> 
> > Yes, I agree it's worth checking out if there is a performance 
> > impact, but if we assume that the stats for RX/TX are possibly going 
> > to be read by another core, they really should be volatile for 
> > correctness
> 
> Accessing the rx_queue structure directly for stats is unlikely to happen from a second core; we should probably change the PCAP PMD as well (thanks for pointing that out John). 

> "Unlikely" doesn't sound completely safe... :-)

LOL. :-). This is an internal data structure and the DPDK docs specifically mention that they are not  multi-process safe/accessible. The unlikely was for people that don't read the docs ... ;)

  reply	other threads:[~2014-07-11 16:29 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-10 20:32 John W. Linville
2014-07-11 13:11 ` Stephen Hemminger
2014-07-11 14:49   ` John W. Linville
2014-07-11 15:06     ` Richardson, Bruce
2014-07-11 15:16       ` Stephen Hemminger
2014-07-11 16:07         ` Richardson, Bruce
2014-07-11 15:29       ` Venkatesan, Venky
2014-07-11 15:33         ` John W. Linville
2014-07-11 16:29           ` Venkatesan, Venky [this message]
2014-07-11 13:26 ` Thomas Monjalon
2014-07-11 14:51   ` John W. Linville
2014-07-11 15:04     ` Thomas Monjalon
2014-07-11 15:30       ` John W. Linville
2014-07-11 16:47         ` Thomas Monjalon
2014-07-11 17:38           ` Richardson, Bruce
2014-07-11 17:41             ` John W. Linville
2014-07-12 11:48           ` Neil Horman
     [not found] ` <D0158A423229094DA7ABF71CF2FA0DA3117D3A23@shsmsx102.ccr.corp.intel.com>
2014-07-11 17:20   ` Zhou, Danny
2014-07-11 17:40     ` John W. Linville
2014-07-11 18:01       ` Zhou, Danny
2014-07-11 18:46         ` John W. Linville
2014-07-12  0:42           ` Zhou, Danny
2014-07-14 13:45             ` John W. Linville
2014-07-11 19:04       ` Zhou, Danny
2014-07-11 19:31         ` John W. Linville
2014-07-11 20:27           ` Zhou, Danny
2014-07-11 20:31             ` Shaw, Jeffrey B
2014-07-11 20:35               ` Zhou, Danny
2014-07-11 20:40                 ` John W. Linville
2014-07-11 22:34       ` Thomas Monjalon
2014-07-14 13:46         ` John W. Linville
2014-07-15 21:27           ` Thomas Monjalon
2014-07-16 12:35             ` Neil Horman
2014-07-16 13:37               ` Thomas Monjalon
2014-07-16 14:07             ` John W. Linville
2014-07-16 14:26               ` Thomas Monjalon
2014-07-16 15:59                 ` Shaw, Jeffrey B
2014-07-11 22:30 ` Thomas Monjalon
2014-07-14 17:53   ` John W. Linville
2014-07-11 22:51 ` Bruce Richardson
2014-07-14 13:48   ` John W. Linville
2014-07-14 17:35     ` John W. Linville
2014-07-14 18:24 ` [dpdk-dev] [PATCH v2] " John W. Linville
2014-07-15  0:15   ` Zhou, Danny
2014-07-15 12:17     ` Neil Horman
2014-07-15 14:01       ` John W. Linville
2014-07-15 15:40         ` Zhou, Danny
2014-07-15 19:08           ` John W. Linville
2014-07-15 20:31         ` Neil Horman
2014-07-15 20:41           ` Zhou, Danny
2014-07-15 15:34       ` Zhou, Danny
2014-09-12 18:05   ` John W. Linville
2014-09-12 18:31     ` Zhou, Danny
2014-09-12 18:54       ` John W. Linville
2014-09-12 20:35         ` Zhou, Danny
2014-09-15 15:09           ` Neil Horman
2014-09-15 15:15             ` John W. Linville
2014-09-15 15:43             ` Zhou, Danny
2014-09-15 16:22               ` Neil Horman
2014-09-15 17:48                 ` John W. Linville
2014-09-15 19:11                   ` Zhou, Danny
2014-09-16 20:16     ` Neil Horman
2014-09-26  9:28       ` Thomas Monjalon
2014-09-26 14:08         ` Neil Horman
2014-09-29 10:05           ` Bruce Richardson
2014-10-08 15:57             ` Thomas Monjalon
2014-10-08 19:14               ` Neil Horman
2014-11-13 10:03                 ` Thomas Monjalon
2014-11-13 11:14                   ` Neil Horman
2014-11-13 11:57                     ` Thomas Monjalon
2014-11-14  0:42                       ` Neil Horman
2014-11-14 14:45                         ` John W. Linville
2014-11-17 15:57                           ` [dpdk-dev] [PATCH v3] librte_pmd_af_packet: " John W. Linville
2014-11-24 16:16                             ` Thomas Monjalon
2014-11-17 11:19                       ` [dpdk-dev] [PATCH v2] librte_pmd_packet: " Neil Horman
2014-11-17 11:22                         ` Thomas Monjalon

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=1FD9B82B8BF2CF418D9A1000154491D974124768@ORSMSX102.amr.corp.intel.com \
    --to=venky.venkatesan@intel.com \
    --cc=dev@dpdk.org \
    --cc=linville@tuxdriver.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).