From: Bruce Richardson <bruce.richardson@intel.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Added Spinlock to l3fwd-vf example to prevent race conditioning
Date: Wed, 10 Dec 2014 14:54:56 +0000 [thread overview]
Message-ID: <20141210145455.GC1632@bricha3-MOBL3> (raw)
In-Reply-To: <20141210144745.GC17040@localhost.localdomain>
On Wed, Dec 10, 2014 at 09:47:45AM -0500, Neil Horman wrote:
> On Wed, Dec 10, 2014 at 08:18:36AM +0000, Wodkowski, PawelX wrote:
> > > Though, that said, doesn't it seem to anyone else like serialization of enqueue
> > > to a port should be the responsibility of the library, not the application?
> > >
> > > Neil
> >
> > From my knowledge it is an application responsibility to serialize access to
> > queue on particular port.
> >
> I understand thats the way it currently is, I'm advocating for the fact that it
> should not be.
> Neil
>
It could be done, but I think we'd need to add a new API (or new parameter to
existing API) to do so, as the cost of adding the locks would be severe, even in
the uncontented case.
This is why it hasn't been done up till now, obviously enough. In general, where
we don't provide performant multi-thread safe APIs, we generally don't try and
provide versions with locks, we just document the limitation and then leave it
up to the app to determine how best to handle things.
/Bruce
next prev parent reply other threads:[~2014-12-10 14:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-08 11:16 [dpdk-dev] [PATCH] " Daniel Mrzyglod
2014-07-23 8:33 ` Thomas Monjalon
2014-11-11 22:56 ` Thomas Monjalon
2014-11-11 23:18 ` Xie, Huawei
2014-12-08 14:45 ` [dpdk-dev] " Neil Horman
2014-12-10 8:18 ` Wodkowski, PawelX
2014-12-10 14:47 ` Neil Horman
2014-12-10 14:54 ` Bruce Richardson [this message]
2014-12-10 15:53 ` Mrzyglod, DanielX T
2014-12-10 16:16 ` Neil Horman
2014-12-10 23:38 ` Stephen Hemminger
2014-12-11 0:34 ` Neil Horman
2014-12-10 10:53 ` Thomas Monjalon
2014-12-11 1:08 ` 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=20141210145455.GC1632@bricha3-MOBL3 \
--to=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=nhorman@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).