[ovs-discuss] ovs-dpctl del-flow works strange

[Levente Csikor]

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