On 13 July 2017 at 04:10, Roi Dayan <[email protected]> wrote: > Hi, > > We encountered an issue with deleting flows using dpctl del-flow and > del-flows that after deleting a flow it cannot be added again.
For what it's worth, we don't really try to support this case. OVS assumes that it has ownership over the kernel cache; users should really change OpenFlow flows if they want to change the behaviour. For instance, if someone adds a flow to the datapath that doesn't conform to the OpenFlow policy, then OVS will evict it. If someone comes and deletes a flow that OVS manages, then that's also a bit strange. It looks like OVS doesn't argue particularly hard about this. I don't think there's any legitimate use case where people should be doing this with any regularity. > My setup is one bridge with a single port and I'm doing a ping in the > background. > > output of dump flows? > > recirc_id(0),in_port(3),eth(src=2a:52:d7:9b:09:04,dst=f2:81:39:3b:5a:f7),eth_type(0x0800),ipv4(frag=no), > packets:0, bytes:0, used:never, actions:2 > recirc_id(0),in_port(2),eth(src=f2:81:39:3b:5a:f7,dst=2a:52:d7:9b:09:04),eth_type(0x0800),ipv4(frag=no), > packets:0, bytes:0, used:never, actions:3 > > > then I delete the first rule and the output of dump flows is: > > recirc_id(0),in_port(2),eth(src=f2:81:39:3b:5a:f7,dst=2a:52:d7:9b:09:04),eth_type(0x0800),ipv4(frag=no), > packets:2, bytes:196, used:0.500s, actions:3 > > > but ping still works. > > I can also delete the 2nd rule and then I don't have anything in > dump-flows but ping still works. If you put the dpif logs up to debug (ovs-appctl vlog/set dpif:file:dbg), do you see the packets being forwarded through userspace? > What we think is happening is we deleted a flow but its ukey is not > evicted/deleted and since the revalidator doesn't see the flow anymore > then aging doesn't happen and revalidator doesn't delete the ukey as > well. Interesting, I wonder if you run "ovs-appctl coverage/show" whether you see incrementing "revalidate_missed_dp_flow" counters. Each cycle, the revalidators will dump all of the flows from the kernel and update each corresponding ukey's 'dump_seq'. They will also call revalidator_sweep__(), which will sweep through the list of all ukeys, and if any of these have not been dumped this cycle then it will attempt to validate whether the flow should exist. All the way back in OVS 2.3, we used to have handle_missed_revalidation() fetch such flows from the datapath[0], but it seems that this was removed in v2.4, with commit bc2df54d2a41a1584fe2ae7a9bcfcc2ee7ccac57. [0] https://github.com/openvswitch/ovs/blob/v2.3/ofproto/ofproto-dpif-upcall.c#L1542 Overall I'm not convinced at this point that it's a problem worth solving, but if you were to try to solve it then you could either look at reintroducing the flow_get that was removed in the aforementioned patch, or alternatively look at adding a timestamp to the ukey so that in this corner case we guarantee to delete the ukey after some time. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
