On Thu, May 24, 2012 at 07:34:39PM -0700, Jesse Gross wrote: > 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.
Ok, I think that would cover the corner case I was worrying about. > > * 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. Thanks, I will take a look at that. > > 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. Good point, I had not thought about the implication that in-tree code would be doing the route lookup. However, as MSS clamp is only applied to the first packet of a TCP connection (SYN set, no data) it might not be too bad to duplicate the route lookup when needed. > 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. Yes, that is why I wanted to have this discussion. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
