From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id A3B7E2013A1 for ; Thu, 21 Jun 2012 06:33:14 -0700 (PDT) Received: by pbcwz7 with SMTP id wz7so3267421pbc.16 for ; Thu, 21 Jun 2012 06:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Wf37azyPd2tyMhcNmRiaiaJZPdKb5hykm/auZwPPSjw=; b=lBrxEPKGWFBL8+zGWC/yCGQttBplX2bajtySz0WvYMtsf4uAbf3BlkMWG/JTA7vp4f 55KYAF0BPM5BybYjVWdFBqUj9mK/1FPOYs/u0lOYDDrQK9uGh2KjD8/JTTBDlB3xL0J3 fok4fG7ZqqaShF2dZJvo0Eu1iQRncSZWDhAuiFBHzBfEWrhElR41D/Q2zRuBICw0gWjG yfqxb2xEqqhbIQOGyn6IbK7IrlN0InS7DGlfNLGYr4zQ/BG8Fj2ENHsRaB416Dwko2cW ZIMRaMDCLKH84GvURMSozcIvqsNUF3RJl1UQjvIbJtD8Qmg/7jVKj2PBj2Ouz9HcLmpK tnGA== MIME-Version: 1.0 Received: by 10.68.138.169 with SMTP id qr9mr23660152pbb.27.1340285593228; Thu, 21 Jun 2012 06:33:13 -0700 (PDT) Received: by 10.143.148.14 with HTTP; Thu, 21 Jun 2012 06:33:13 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 Jun 2012 14:33:13 +0100 Message-ID: From: Robert Bradley To: cerowrt-devel@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Subject: Re: [Cerowrt-devel] Baby jumbo frames support? X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 13:33:15 -0000 On 21 June 2012 01:58, Dave Taht wrote: > As for PPoE with a size 1508... um... one or the other device is going > to get in your way here. I presume that 1500 works? You would do > better to contact the author of the driver (juhosg) to get your > question answered as I'm under the impression he is under the right > NDAs. > I think the point here is that MTU=1500 works, but once you add in the PPPoE header, you end up with an effective MTU of 1492 for outbound packets: http://aa.net.uk/kb-broadband-mtu.html http://tools.ietf.org/html/rfc4638 The short answer is that without baby-jumbo support, you either end up fragmenting packets or you need to somehow restrict the MTU manually. You can do that either through MSS clamping or simply configuring each internal machine to use MTU=1492. To get around this, the BT ADSL modems started to support MTU=1508. This means that the MTU within the PPPoE tunnel remains at Ethernet-standard 1500, and avoids the fragmentation or reconfiguration issues. As for supporting it in CeroWRT ... the ag71xx driver defines AG71XX_TX_MTU_LEN=1540, so it looks safe enough to use MTU 1508, especially if you know that no vlans or other additions to the standard header will be used. To enable that, you need to reimplement the eth_change_mtu function for the driver. The current code uses the kernel's implementation, which restricts the MTU to 1500. An initial, naive patch would look something like: ---- --- C:/Users/robert/AppData/Local/Temp/ag71x-revBASE.svn000.tmp.c Mon May 28 03:55:59 2012 +++ C:/Users/robert/Desktop/ag71xx/ag71xx_main.c Thu Jun 21 13:58:44 2012 @@ -1042,13 +1042,25 @@ } #endif +/* + * Copied from eth_change_mtu and modified so that baby jumbo packets + * may be used. This has not been tested! + */ +int ag71xx_change_mtu(struct net_device *dev, int new_mtu) +{ + if (new_mtu < 68 || new_mtu > (ETH_DATA_LEN + 8)) + return -EINVAL; + dev->mtu = new_mtu; + return 0; +} + static const struct net_device_ops ag71xx_netdev_ops = { .ndo_open = ag71xx_open, .ndo_stop = ag71xx_stop, .ndo_start_xmit = ag71xx_hard_start_xmit, .ndo_do_ioctl = ag71xx_do_ioctl, .ndo_tx_timeout = ag71xx_tx_timeout, - .ndo_change_mtu = eth_change_mtu, + .ndo_change_mtu = ag71xx_change_mtu, .ndo_set_mac_address = eth_mac_addr, .ndo_validate_addr = eth_validate_addr, #ifdef CONFIG_NET_POLL_CONTROLLER ---- where I've copied the original function and changed the upper limit to ETH_DATA_LEN+8, then set up the netdev_ops structure to call the new version. In reality, you probably want to add some better checks (testing for MTU+all possible headers<1540?) and remove the magic constant - in the worst case, something closer to the e1000 driver's implementation. I wouldn't recommend using the present version on anything other than an experimental build, but the default MTU would be 1500 anyway so should avoid causing too much damage. Those on BT ADSL lines can change the MTU on ge00 themselves and see what breaks. -- Robert Bradley