[ovs-discuss] failure to modify flow

Ilya Maximets i.maximets at ovn.org
Fri Apr 9 21:34:44 UTC 2021


> Ping.
> 
> From: Salem Sol
> Sent: Wednesday, January 13, 2021 4:37 PM
> To: ovs-discuss <ovs-discuss at openvswitch.org>
> Subject: failure to modify flow
> 
> Hi,
> 
> While I was running OVS-DPDK with Geneve traffic I hit a problem where in the first flow OVS does not know which port to forward the packet to, so it sends it to all the ports on the bridge leading to the creation of this datapath rule:
> 
> skb_priority(0/0),tunnel(tun_id=0x5,src=101.11.7.1,dst=101.11.8.1,ttl=64/0,tp_src=43419/0,tp_dst=6081/0,flags(-df-csum+key)),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),recirc_id(0),dp_hash(0/0),in_port(genev_sys_6081),packet_type(ns=0,id=0),eth(src=e4:0b:07:08:00:03,dst=e4:0b:08:08:00:02),eth_type(0x0800),ipv4(src=11.11.7.2/0.0.0.0,dst=11.11.8.1,proto=6,tos=0/0,ttl=64/0,frag=no),tcp(src=19016/0,dst=19016/0),tcp_flags(0/0), packets:208, bytes:23738, used:4.756s, flags:SFPR., dp:ovs, actions: enp8s0f0_0,ovs-sriov1,enp8s0f0_0, dp-extra-info:miniflow_bits(10,2)
> 
> after OVS learns the correct port to forward to it issues a flow modification that fails:
> 
> 2021-01-12T11:41:42.733Z|00001|dpif(revalidator13)|WARN|netdev at ovs-netdev: failed to put[modify] (No such file or directory) ufid:9844be55-8c6d-4ef0-9bb8-622b13aa0c7b skb_priority(0/0),tunnel(tun_id=0x5,src=101.11.8.1,dst=101.11.7.1,ttl=64/0,tp_src=50367/0,tp_dst=6081/0,flags(-df-csum+key)),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),recirc_id(0),dp_hash(0/0),in_port(3),packet_type(ns=0,id=0),eth(src=e4:0b:08:08:00:02,dst=e4:0b:07:08:00:03),eth_type(0x0800),ipv4(src=11.11.8.1/0.0.0.0,dst=11.11.7.2,proto=1,tos=0/0,ttl=64/0,frag=no),icmp(type=8/0,code=0/0), actions:4

This flow and the one above are different flows as they have different mtches,
e.g. different ip addresses and ports.  So, the second should not modify the
first one.

Is there flow with exact same matches as in the second one, but with different
list of actions?

> 
> This behavior was already discussed in [1]
> There is a proposed fix the this discussion that was never applied, in the discussion they mention that the fix is not complete "(The following patch is not actually the real fix because the code should still look at the key if no ufid was provided.)"
> 
> So my questions are:
> 
>   1.  What are the risks of changing the procedure of searching for the flows moving to look for the flow using UFID and not netdev_key?

In current OVS there is always a key in the flow_put operation.  If we can't
find by the key, it should not be possible to find by the ufid.  If it happens,
it means that there is a bug somewhere else.  For example, here is the fix
for the bug reported in [1]:
   35fe9efb2f02 ("dpif-netdev: Add vlan to mask for flow_put operation.")

If we will allow searching by UFID, this will likely just hide other bugs and
it will be much harder to find them.

I think, we can try searching by the key, and if it fails - try again with ufid.
In case of success the error should be logged anyway, because this should never
happen, but we can continue operation and modify the flow.   OTOH, we will
modify the actions of the flow that doesn't match with the key from the request
and that might be even worse.  So, I'm not sure if we need to implement this,
at least we should not silently ignore the key if it is specified.

I guess, the best option is to search by the key, if it fails - try to serach
by ufid, if it succeedes - log an error with the requested key and the key of
a flow that was found by ufid.  And we need to fail the operation anyway,
because something clearly went wrong and we don't know if it's an error in the
caller or it's a bug inside the datapath.

And we can definitely implement search by the ufid, if key is not specified,
but there are no such cases in current code, IIUC.

>   2.  Why this fix was not applied or merged to the master branch?

Because it's not a real fix.

> 
> [1] https://lists.linuxfoundation.org/pipermail/ovs-dev/2018-September/352579.html


Best regards, Ilya Maximets.


More information about the discuss mailing list