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 <joestrin...@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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
