Date: Thu, 09 Sep 2004 19:05:16 +0200 From: Andre Oppermann <andre@freebsd.org> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: freebsd-arch@FreeBSD.org Subject: Re: better MTU support... Message-ID: <41408D4C.E33B6F98@freebsd.org> References: <20040906050435.GA72089@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John-Mark Gurney wrote: > > In a recent experiment w/ Jumbo frames, I found out that sending ip > frames completely ignores the MTU set on host routes. This makes it > difficult (or next to impossible) to support a network that has both > regular and jumbo frames on it as you can't restrict some hosts to the > smaller frames. What you should do instead is to set the MTU on the interface to 9018 or so and then have a default route with MTU 1500 for everything else. Now you can specify larger MTUs for hosts that support it. Otherwise you are opening a can of worms... > I now have a patch to ip_output that makes it obay the MTU set on the > route instead of that of the interface. Your patch corrects a problem in ip_output where a smaller MTU on an rtentry was ignored but that is only for the non-TCP cases. When you open a TCP session the MTU will be honored (see tcp_subr.c:tcp_maxmtu). If not it would be a bug. Could you try your large MTU setup again using the procedure I desribed above? That should solve your immediate problem. For the general 'bug' in ip_output that it doesn't honour a smaller MTU on a route I'd like to do a more throughout fix. Routes should be created with MTU 0 if the MTU is not different from the if_mtu. Only in those cases where you want to have a lower MTU you set it. For cloned routes the MTU would be cloned from the parent. This range of changes is more intrusive. On top of that comes the new ARP code which will have a MTU field as well. This one is supposed to store different MTUs for mixed MTU L2 networks. How to transport the MTU information is a separate discussion. If the fix above works for you I'd like to do the real fix later (< end of year) and not change the current behaviour in ip_output at the moment. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41408D4C.E33B6F98>