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,proto= 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 disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss