Minor update: Iperf was using different source port when re-initiated, so this is why it became again part of fast path.
If I send packets that matches the allow rule and all header fields are the same, then it won't be cached again once it has been deleted. On Tue, 2019-06-18 at 10:38 +0800, Levente Csikor wrote: > Hi fellow OVS users and gurus, > > I am playing with ovs-dpctl del-flow command to manually remove > entries > from the cache. > > I have a following entry in the cache which let's incoming traffic to > a > destination IP with udp port 80 to a service: > > recirc_id(0),in_port(4),eth(),eth_type(0x0800),ipv4(dst=10.0.0.2,prot > o= > 17,frag=no),udp(dst=80), packets:247279, bytes:14836740, used:0.000s, > actions:2 > > However, if I want to delete the flow and use the syntax off directly > adding a flow to the datapath described in the manual, i.e., using > syntax like this: > ovs-dpctl del-flow > "in_port(4),eth(),eth_type(0x0800),ipv4(dst=10.0.0.2,proto=17,frag=no > ), > udp(dst=80) > > it gives me an error that it does not find a corresponding flow rule: > ovs-dpctl: deleting flow (No such file or directory) > Perhaps you need to specify a UFID? > > > Then, I realized that if dpctl dump-flows is called with parameter '- > m', it prints out the ufid (unique flow identifiers) for the datapath > entries. > Using a command like this accordingly does the job: > ovs-dpctl del-flow ufid:5cc7e599-7050-4b4a-83d6-8a8fe8e8a975 > > What is the difference? and can someone let me know an example of > del- > flow command to show what to include in/exlude of the command? > > > On the other hand, when I finally remove an entry via ufid, then it > seems that it is permanently removed! > Traffic is still on, but no new entries are spawned in the datapath > letting me think that now everything is going through the slow path > (especially that an experiment of iperf between two VMs, the > throughput > dropped down below 1Gbps from 35-40Gbps. > > I also tried to stop the traffic, wait more than 10 sec to let the > megaflow cache entries expire, and restarted the traffic. > Then, the traffic is cached again and everything is back to its > normal > operation. > > > For curiosity, I have tried the same thing for a drop-rule instead of > an allow rule. > (This means that the entry I am deleting is not represented in both > the > slow path and fast path in the same way, i.e., there can be many > entries in the cache that matches a drop rule.) > Anyway, if I remove a (drop) entry from the fast path then the > corresponding entry will never ever be there again: > > - Packets matching on the drop rule are still coming in -> processed > by > slow path > - Wait again more than 10 sec, still won't be cached again -> > processed > by slow path > > I did even try this with removing all entries in the fast path that > correspond to a drop rule in the flow table. I still have the same > case. > > > What am I doing wrong? Is there any timeout for these deletions? > > Thanks, > lev > _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
