Re: Added Spinlock to l3fwd-vf example to prevent race conditioning

-----Original Message-----
From: dev [mailto:dev-bounces-VfR2kkLFssw@public.gmane.org] On Behalf Of Bruce Richardson
Sent: Wednesday, December 10, 2014 3:55 PM
To: Neil Horman
Cc: dev-VfR2kkLFssw@public.gmane.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:

quoted

On Wed, Dec 10, 2014 at 08:18:36AM +0000, Wodkowski, PawelX wrote:

quoted

quoted

Though, that said, doesn't it seem to anyone else like serialization of

enqueue

quoted

quoted

quoted

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.