On Fri, May 16, 2014 at 04:17:34PM -0700, Daniele Di Proietto wrote: > On May 16, 2014, at 9:26 AM, Ben Pfaff <[email protected]> wrote: > > I don't think that it is safe to use a cls_cursor to iterate flows in > > the flow dump path. The classifier isn't locked from one > > dpif_netdev_flow_dump_next() to the next, which means that any given > > flow might get deleted from the classifier from one to the next. That > > includes both the most recently returned flow and the next one that will > > be returned. Basically, we have to either somehow prevent at least one > > of those flows from being deleted, or use some other means for > > iteration. That's why the hmap iteration used the indirect > > hmap_at_position() call for iteration: it's always safe, even if it's > > otherwise undesirable > > I didn?t think of that. I assumed that a cls_cursor_next() had the same > requirements as hmap_at_position(). > I?ve implemented classifier_at_position() to address the issue. I?ll post it > along with a new version of the patch.
Great, thanks. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
