Re: better MTU support...

From: Andre Oppermann (andre_at_freebsd.org)
Date: 09/09/04

  • Next message: John-Mark Gurney: "Re: better MTU support..." 
    Date: Thu, 09 Sep 2004 19:05:16 +0200
To: John-Mark Gurney <gurney_j@resnet.uoregon.edu>

    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
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: John-Mark Gurney: "Re: better MTU support..."

    Relevant Pages

    • Re: better MTU support...
      ... > frames completely ignores the MTU set on host routes. ... > regular and jumbo frames on it as you can't restrict some hosts to the ... What you should do instead is to set the MTU on the interface to 9018 ... Now you can specify larger MTUs for hosts that support it. ...
      (freebsd-net)
    • Re: better MTU support...
      ... > Ok, finally got a switch (and gige cards, if_re needs work) capable of ... > smaller mtu... ... >> on a route I'd like to do a more throughout fix. ... >> routes the MTU would be cloned from the parent. ...
      (freebsd-arch)
    • Re: better MTU support...
      ... > Ok, finally got a switch (and gige cards, if_re needs work) capable of ... > smaller mtu... ... >> on a route I'd like to do a more throughout fix. ... >> routes the MTU would be cloned from the parent. ...
      (freebsd-net)
    • Re: Getting Jumbo Frames to work on a p630
      ... Did you also increase the MTU size from 1500 to 9000 for your Gbit adapter ... you will have to bring the interface down to change the max MTU size and ... Getting Jumbo Frames to work on a p630 ...
      (AIX-L)
    • Re: FreeBSD discarding received packets > MTU
      ... I've found that the bce driver seems to be throwingaway packets ... When this RX MTU size issue was being discussed previously I ... Support for jumbo frames is ... though the memory requirements are 5x larger for jumbo frames ...
      (freebsd-net)