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:
quoted
quoted
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
-----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.
On Wed, Dec 10, 2014 at 02:54:56PM +0000, Bruce Richardson wrote:
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
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.
This really seems like a false savings to me. If an application intends to use
multiple processes (which by all rights it seems like the use case that the dpdk
is mostly designed for) then you need locking one way or another, and you've
just made application coding harder, because the application now needs to know
which functions might have internal critical sections that they need to provide
locking for.
I agree that, in the single process case, there might be a slight performance
loss (though I contend it wouldn't be greatly significant). That said, I would
argue that the right approach is to do the locking internally to the DPDK, then
provide a configuration point which toggles the spinlock defintions to either do
proper locking, or just reduce to empty definitions, the same way the Linux and
BSD kernels do in the uniprocessor case. That way applications never have to
worry about internal locking, and you can still build for the optimal case when
you need to.
Neil
/Bruce