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 <ho...@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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
