[ovs-discuss] MTU considerations for OVN

Jesse Gross jesse at kernel.org
Wed May 4 23:09:04 UTC 2016


On Tue, May 3, 2016 at 3:50 PM, Matt Kassawara <mkassawara at gmail.com> wrote:
> Jesse,
>
> I'm resurrecting this thread after a fairly lengthy discussion of MTU with
> Ben at the recent OpenStack summit. Have you given the topic any further
> thought toward implementation in a reasonable way? Can you elaborate on the
> architectural limitations? At the moment, the OpenStack implementation of
> OVN doesn't use DPDK.

The issue that I alluded to before is that when OVS (and by extension
OVN) does L3 processing the packets aren't traversing the Linux IP
stack and so the usual MTU checks don't apply. Instead OVS just does a
single combined lookup for all flow processing and then applies some
actions like set SMAC/DMAC and decrement TTL. Not only is there no
code to check the outgoing MTU but there's no obvious outgoing device
to fetch the desired MTU from.

One possible solution is to introduce an action in the kernel that
would check packets flowing through the switch against a length
specified by the user (where the 'user' is OVS userspace/OVN in this
case). To use this, we would do a route lookup of the tunnel endpoint
to find the outgoing device, subtract the encapsulation overhead, and
install a flow that checks this length and punts the packet to OVN to
generate an ICMP message.

Although I think that would work, I have a couple of concerns. The
first is that it decouples the MTU check into several pieces and these
could get out of sync. For example, since the target MTU is calculated
separate from the datapath, we'd have to make sure that if routes/MTUs
or encapsulation header size change then the flows are updated as
well. The second issue is that this is starting to encroach on the
territory of the routing stack and that type of duplication might not
be well received by the upstream Linux community.

I'm also CC'ing Thomas who had interest in this area as well before.



More information about the discuss mailing list