On Fri, Jan 10, 2014 at 11:43:14AM -0800, Joe Stringer wrote:
> In an earlier incarnation of dpif, the interface specified that if
> flow_dump_next() returned an error code, then the function must not be
> called again in the same dump operation. As such, the dpif itself needed
> to cache the error status to ensure that it did not make such calls.
> Recent changes have relaxed this restriction, making it the
> responsibility of the dpif implementation to track flow dump error
> status.
>
> This patch ensures that dpif_flow_dump_next() does not attempt to finish
> the flow dump, as it will be the responsibility of just one thread to do
> this. Furthermore, we no longer update 'dump->status' in this function,
> so that even if one thread finishes processing flows in its buffer (and
> handles the final flow), it will not prevent other callers from
> processing the remaining flows in their buffers.
>
> After this patch, the error code that dpif_flow_dump_next() returns is
> only significant for the current state and buffer. As before, the status
> of the entire flow dump operation can be obtained by calling
> dpif_flow_dump_done().
>
> Signed-off-by: Joe Stringer <[email protected]>
Doesn't think cause errors generated by flow_dump_next implementations
to be lost? e.g. dpif_linux_flow_dump_next() can return errors
produced by dpif_linux_flow_from_ofpbuf().
By the way, somewhere along the line we ended up with a really silly
loop in dpif_linux_flow_from_ofpbuf() (the "while" condition can never
be true):
do {
if (!nl_dump_next(&state->dump, &buf, buffer)) {
return EOF;
}
error = dpif_linux_flow_from_ofpbuf(&flow, &buf);
if (error) {
return error;
}
} while (error);
_______________________________________________
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev
