From: dpreed@reed.com
To: "Robert Bradley" <robert.bradley1@gmail.com>
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] Fwd: [PATCH] ag71xx: Added support for baby-jumbo packets.
Date: Fri, 22 Jun 2012 16:11:15 -0400 (EDT) [thread overview]
Message-ID: <1340395875.353911244@apps.rackspace.com> (raw)
In-Reply-To: <CAA=Zby5D0z5X7cFA78gs0pOsLGyyss7erv8ABVG=ReO-=LDZCQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5117 bytes --]
Good step. Why not allow 9K byte jumbos when one's packets traverse a path that is internal to the local area, and all the 1 GigE links support 9K?
-----Original Message-----
From: "Robert Bradley" <robert.bradley1@gmail.com>
Sent: Friday, June 22, 2012 3:12pm
To: cerowrt-devel@lists.bufferbloat.net
Subject: [Cerowrt-devel] Fwd: [PATCH] ag71xx: Added support for baby-jumbo packets.
For those of you not following the openwrt-devel mailing list, this is
an updated version of the baby-jumbo patch I posted previously in
response to Alexander's post. This version is slightly less
conservative about extended frame lengths (up to 1518 octets), but
removes the awkward magic constant. The maximum MTU is now calculated
by subtracting header lengths from AG71XX_TX_MTU_LEN. I also use this
to calculate the maximum received packet size. Defining
AG71XX_MAX_DATA_LEN as 1500 (or ETH_DATA_LEN) restores the original
behaviour.
---------- Forwarded message ----------
From: Robert Bradley <robert.bradley1@gmail.com>
Date: 22 June 2012 13:50
Subject: [PATCH] ag71xx: Added support for baby-jumbo packets.
To: openwrt-devel@lists.openwrt.org
RFC 4638 support means that a full 1500-octet frame can be transmitted
through a PPPoE tunnel. For this to work, the network card must support
baby-jumbo frames of 1508 octets plus headers. This patch enables the use
of MTUs up to 1518 octets (derived from the existing AG71XX_TX_MTU_LEN
value by subtracting header sizes).
The default MTU size is unchanged; if large frames are desired, ifconfig
must be used to set the new MTU.
Signed-off-by: Robert Bradley <robert.bradley1@gmail.com>
---
.../files/drivers/net/ethernet/atheros/ag71xx/ag71xx.h | 17 ++++++++++++++++-
.../drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c | 18 +++++++++++++++++-
2 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx.h
b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx.h
index b9d95ad..7f77a59 100644
--- a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx.h
+++ b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx.h
@@ -51,8 +51,23 @@
#define AG71XX_INT_INIT (AG71XX_INT_ERR | AG71XX_INT_POLL)
#define AG71XX_TX_MTU_LEN 1540
+/*
+ * AG71XX_MAX_DATA_LEN equals the maximum possible MTU that a frame of length
+ * AG71XX_TX_MTU_LEN can have. This may be larger than ETH_DATA_LEN! This
+ * define is necessary for baby jumbo packet support (as per RFC 4638).
+ *
+ * Redefining this as ETH_DATA_LEN restores the 1500-octet MTU limit.
+ */
+#define AG71XX_MAX_DATA_LEN \
+ (AG71XX_TX_MTU_LEN - (ETH_FCS_LEN + VLAN_HLEN + ETH_HLEN))
+/*
+ * Define AG71XX_RX_PKT_SIZE using AG71XX_MAX_DATA_LEN + ETH_HLEN rather than
+ * ETH_FRAME_LEN so that baby jumbo frames can be used safely. This definition
+ * means that setting AG71XX_MAX_DATA_LEN to ETH_DATA_LEN restores the old
+ * values, which are safe for standard frames.
+ */
#define AG71XX_RX_PKT_SIZE \
- (ETH_FRAME_LEN + ETH_FCS_LEN + VLAN_HLEN)
+ (AG71XX_MAX_DATA_LEN + ETH_HLEN + ETH_FCS_LEN + VLAN_HLEN)
#define AG71XX_RX_BUF_SIZE (AG71XX_RX_PKT_SIZE + NET_SKB_PAD + NET_IP_ALIGN)
#define AG71XX_TX_RING_SIZE_DEFAULT 64
diff --git a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
index fb99d27..d3e850b 100644
--- a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
+++ b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
@@ -1042,13 +1042,29 @@ static void ag71xx_netpoll(struct net_device *dev)
}
#endif
+/*
+ * ag71xx_change_mtu: set interface MTU.
+ * A modified eth_change_mtu, changing the upper limit from ETH_DATA_LEN to
+ * AG71XX_MAX_DATA_LEN. This means that baby jumbo packets may be used by
+ * PPPoE users, assuming that AG71XX_MAX_DATA_LEN > ETH_DATA_LEN.
+ *
+ * Returns 0 on success, -EINVAL otherwise.
+ */
+static int ag71xx_change_mtu(struct net_device *dev, int new_mtu)
+{
+ if (new_mtu < 68 || new_mtu > AG71XX_MAX_DATA_LEN)
+ 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
--
Robert Bradley
--
Robert Bradley
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
[-- Attachment #2: Type: text/html, Size: 6300 bytes --]
next prev parent reply other threads:[~2012-06-22 20:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAA=Zby5dVYjQNbbwMcHQc7qKSSHnYTAonjRJYG1d6zdqPsZ0Rg@mail.gmail.com>
2012-06-22 19:12 ` Robert Bradley
2012-06-22 20:11 ` dpreed [this message]
2012-06-22 20:41 ` Robert Bradley
2012-06-23 19:29 ` dpreed
2012-06-23 20:10 ` Dave Taht
2012-06-23 21:47 ` Robert Bradley
2012-06-23 22:33 ` dpreed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1340395875.353911244@apps.rackspace.com \
--to=dpreed@reed.com \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=robert.bradley1@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox