Guess this is a known issue, please check out this patch:
https://patchwork.ozlabs.org/project/openvswitch/patch/[email protected]/
Aaron any update on the v5 patch?
//Eelco
On 20 Apr 2022, at 16:21, Reshma Sreekumar wrote:
> Hi All,
>
> We encountered a dramatic drop of bandwidth on some OVS ports, and
> discovered that it was caused by overly broad slow_path flow that does not
> disappear as long as there is any traffic on the port. The flow looks like
> this:
>
> recirc_id(0),in_port(3),*eth()*,eth_type(0x0800),ipv4(frag=no), packets:1,
> bytes:54, used:0.928s, *actions:userspace(pid=4294967295,slow_path(match)) *
>
> Note that it intercepts _all_ IP traffic from a port.
>
> It looks like this situation is triggered when an IGMP packet arrives on
> the port in the presence of user-installed openflow rules that prevent it
> from being processed by the flow "priority=0 table=0 actions=NORMAL" that
> is created in any bridge by default.
>
> The following script reproduces this situation by installing a flow that
> redirects traffic, but any other user defined flow will do, if it diverts
> or drops the packet before it can reach the default flow.
>
> ```
> #!/usr/bin/sudo /bin/sh
>
> ip link del veth0 2>/dev/null
> ip link del lnxbr 2>/dev/null
> ovs-vsctl del-br ovsbr 2>/dev/null
>
> # cleanup done
>
> ovs-vsctl add-br ovsbr
> ip link add lnxbr type bridge
>
> ip link add veth0 type veth peer veth1
> ip link set veth1 master lnxbr
> ovs-vsctl add-port ovsbr veth0
>
> ofport=`ovs-dpctl show | awk '/veth0/{gsub(":","",$2); print $2}'`
> ovs-ofctl add-flow ovsbr cookie=0x1,priority=10,actions=${ofport}
> ip link set veth0 up
> ip link set veth1 up
> ip link set lnxbr up # This triggers some multicast packets
>
> sleep 1 # Give OVS time to install kernel flows
> echo ==== userspace flows:
> ovs-ofctl dump-flows ovsbr
> echo ==== kernel flows:
> ovs-appctl dpctl/dump-flows
> ```
>
> ( In the above config, one end of a veth pair is enslaved to the ovs bridge
> while the other is part of a linux bridge. This is for the ease of
> generating IGMP traffic. )
>
> After running this, there is a kernel flow similar to the one shown above.
> Particular kernel flow depends on the contents of the user- defined flow;
> if user-defined flow had actions "output" or "resubmit", the kernel flow
> will be slow_path.
>
> This looks like a problem in the way OVS handles IGMP traffic? Maybe there
> is some way to mitigate it?
>
> Something worth noting is that, if the IGMP traffic hits the rule with
> "actions=NORMAL" (in the absence of any other matching rule of higher
> prio), then the userpath rule is installed with a filter
> *eth(src=xx:xx:xx:xx:xx,
> dst=**01:00:5e:00:00:16), *which looks like the right approach.
>
> Would be great if this could be fixed to behave the same even in the
> presence of other user-defined openflow rules matching the traffic, or if
> you could share some workaround for the same. Thanks in advance!
>
> Thanks,
> Reshma
> _______________________________________________
> dev mailing list
> [email protected]
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
