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