Re: [Cerowrt-devel] Baby jumbo frames support?

[Robert Bradley <robert.bradley1@gmail.com>]

On 21 June 2012 01:58, Dave Taht <dave.taht@gmail.com> 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