On Tue, Feb 2, 2016 at 6:03 PM, Matt Kassawara <mkassaw...@gmail.com> wrote:
> Jesse,
>
> We can raise the MTU of the underlying network until it reaches the maximum
> value for the physical equipment, a common situation for 10+ Gbps data
> center networks. For example, if the physical equipment supports a maximum
> 9000 MTU, we can't further increase it to account for overlay protocol
> overhead. We can easily reduce the VM MTU to account for outbound traffic,
> but inbound traffic assumes it can use 9000 bytes and therefore requires
> PMTUD... or (grudgingly) reducing the MTU of all hosts on the physical
> network... effectively moving the problem rather than solving it.
>
> I think we need to solve this problem sooner than later to prevent the
> current loathing by operators using conventional OpenStack neutron drivers
> from seeping into OVN before it has a chance at success. Right now, the
> ability to eliminate (often obscure) problems for any underlying network MTU
> provides a huge selling point, at least for OpenStack.

The architectural limitations that I was referring to earlier are
mostly in the Linux kernel and since the DPDK datapath will be the
preferred software gateway for OVN, perhaps they don't really apply.
I'm a little hesitant to introduce actions that can only be handled in
one place but since this would be purely internal to OVS it might not
matter since we could change the implementation in the future if
necessary. That would potentially allow us to handle this in an
cleaner way in the near future.
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Reply via email to