Re: [dpdk-dev] Added Spinlock to l3fwd-vf example to prevent race conditioning

["Mrzyglod, DanielX T" <danielx.t.mrzyglod@intel.com>]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson
> Sent: Wednesday, December 10, 2014 3:55 PM
> To: Neil Horman
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] Added Spinlock to l3fwd-vf example to prevent race
> conditioning
> 
> 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


the problem is when the routing is through the same queue the app crashed. 
example: traffic to 1.1.1.1 from port 0 and 1.1.1.1 from port 1.
You all are right :)
So the only solution are spinlocks, or we must modify 
intel-dpdk-sample-applications-user-guide.pdf to inform users about limitations.