[ovs-dev] [PATCH 08/10] dpif: Make dpif_flow_dump_next() thread-safe.

[Ben Pfaff]

On Fri, Jan 10, 2014 at 11:43:13AM -0800, Joe Stringer wrote:
> This patch makes it the caller's responsibility to allocate and pass a
> buffer down to the dpif_flow_dump_next() implementation, to act as
> storage for the next flow. The implementation can expect to be called
> from multiple threads with the same 'state' and different 'buffer's.
> 
> When flow_dump_next() returns non-zero, the implementation must ensure
> that subsequent calls with the same arguments also return non-zero.
> Subsequent calls with the same 'state' and different 'buffer' may return
> zero, but should make progress towards returning non-zero.
> 
> Furthermore, the 'stats' argument becomes a pointer, not a double
> pointer. If this argument is non-null, then the 'dpif' will populate it
> with the stats of the flow. This should make reallocation unnecessary.
> 
> Signed-off-by: Joe Stringer <joestringer at nicira.com>

dpif_flow_dump_next() deserves a comment update to explain what's
going on.

The "Thread-safety" comment at the top of dpif.h also needs an update.

I'm a little concerned that this could make life difficult for
out-of-tree dpif implementations.  The in-tree ones are OK with
maintaining all per-thread state in a single ofpbuf.  But I can
imagine dpifs that don't.  If you think so, too, then it might make
sense to force each thread to supply a more general form of state than
just a single ofpbuf.

Thanks,

Ben.