[ovs-dev] MSS Clamp in User-Space

Jesse Gross jesse at nicira.com
Fri May 25 02:34:39 UTC 2012


Hi Simon,

Sorry I haven't responded to your patches yet.  I'm not ignoring them
- I've just been very busy lately.  Your high level descriptions all
sounds good so far though.  I'm hoping to have a chance to look at
them this weekend.

On Wed, May 23, 2012 at 5:26 PM, Simon Horman <horms at verge.net.au> wrote:
> Hi Jesse,
>
> as part of our discussion on flow-based tunneling a few weeks ago
> you mentioned that you would like to see an implementation of MSS Clamping
> in user-space in order to eliminate the need for gre_err().
>
> I made a start on implementing this, and I have a non-configurable
> version working. Its pretty crude and just adjust the MSS on all TCP
> SYN packets with no payload that are seen in handle_flow_miss_common().
>
> That much seems to work. But I am unsure about a few things.
> * Should it be configurable per-output port?
>  If so that may be problematic if there are multiple outputs as
>  the packet data is mangled.

I think it probably needs to be configurable per output port but
doesn't need to be optimized for the case where there are different
configurations or MTUs.  We could potentially just send multiple
copies of the packet to the kernel, for example.

> * I am unsure how to automatically calculate the desired
>  Clamp size. In particular, in for GRE it would be nice
>  to allow it to be automatically clamped to the underlying MTU less
>  the header size. But I'm unsure of a sane way to obtain the MTU.

There's some code already in lib/route-table.c that can lookup the
device and from there you could get the MTU.  That said, it doesn't
really take into account any path MTU information that the kernel
might have or multipathing.

> Perhaps I am on the wrong track?
>
> It does seem to me that this might be easier implemented in the datapath
> as ovs_tnl_send() already has access to skb, the MTU and could leverage
> the existing netfilter MMS clamp code.

Do you have an idea of what this would look like?  I'm not sure how it
would fit in with using the in-tree tunneling code, since that would
presumably do the route lookup.

The flexibility of doing it in userspace is certainly nice but it may
not work or we may be able to get it anyways in the kernel.



More information about the dev mailing list