On Tue, May 3, 2016 at 3:50 PM, Matt Kassawara <[email protected]> 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. _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
