In general, we don't pay much attention to OVS behavior here, because this isn't something users should do.
On Tue, Jun 18, 2019 at 11:10:40AM +0800, Levente Csikor wrote: > 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 > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
