public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark McLoughlin <markmc@redhat.com>
To: jesse.brandeburg@intel.com
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	Herbert Xu <herbert@gondor.apana.org.au>
Subject: e1000: Problem with "disable CRC stripping workaround" patch
Date: Thu, 20 Jul 2006 17:11:08 +0100	[thread overview]
Message-ID: <1153411868.2758.34.camel@localhost.localdomain> (raw)

[-- Attachment #1: Type: text/plain, Size: 967 bytes --]

Hi Jesse,
	I just came across this:

  http://www.mail-archive.com/netdev@vger.kernel.org/msg14547.html

	I'm seeing a problem with this currently under Xen's bridging
configuration.

	Basically, with the patch, packets are being dropped at this point in
net/bridge/br_forward.c:

---
int br_dev_queue_push_xmit(struct sk_buff *skb)
{
        /* drop mtu oversized packets except gso */
	if (packet_length(skb) > skb->dev->mtu && !skb_is_gso(skb)) {
		kfree_skb(skb);
--

	What's happening that a 1500 byte packet comes in from e1000, onto the
bridge and is to be forwarded to a device whose mtu is 1500. Because the
CRC hasn't been stripped, skb->len is 1504 and the packet is dropped.

	One option is to fix this specific problem is to subtract the CRC
length from skb->len in e1000, another is to raise the MTU on the
receive side of Xen's loopback interface. I've attached a patch for the
latter, but I've no real opinion on which is more correct.

Cheers,
Mark.

[-- Attachment #2: xen-netback-jumbo-mtu-on-vif.patch --]
[-- Type: text/x-patch, Size: 1363 bytes --]

--- ./xen/netback/loopback.c.jumbo-mtu-on-vif	2006-07-20 16:21:52.000000000 +0100
+++ ./xen/netback/loopback.c	2006-07-20 16:23:08.000000000 +0100
@@ -161,16 +161,6 @@
 				NETIF_F_IP_CSUM);
 
 	SET_ETHTOOL_OPS(dev, &network_ethtool_ops);
-
-	/*
-	 * We do not set a jumbo MTU on the interface. Otherwise the network
-	 * stack will try to send large packets that will get dropped by the
-	 * Ethernet bridge (unless the physical Ethernet interface is
-	 * configured to transfer jumbo packets). If a larger MTU is desired
-	 * then the system administrator can specify it using the 'ifconfig'
-	 * command.
-	 */
-	/*dev->mtu             = 16*1024;*/
 }
 
 static int __init make_loopback(int i)
@@ -193,6 +183,16 @@
 	loopback_construct(dev2, dev1);
 
 	/*
+	 * We only set a jumbo MTU on vif0.0. Otherwise the network
+	 * stack will try to send large packets that will get dropped by the
+	 * Ethernet bridge (unless the physical Ethernet interface is
+	 * configured to transfer jumbo packets). If a larger MTU is desired
+	 * then the system administrator can specify it using the 'ifconfig'
+	 * command.
+	 */
+	dev1->mtu = 16*1024;
+
+	/*
 	 * Initialise a dummy MAC address for the 'dummy backend' interface. We
 	 * choose the numerically largest non-broadcast address to prevent the
 	 * address getting stolen by an Ethernet bridge for STP purposes.

             reply	other threads:[~2006-07-20 16:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-20 16:11 Mark McLoughlin [this message]
2006-07-20 16:42 ` e1000: Problem with "disable CRC stripping workaround" patch Auke Kok
2006-07-20 20:04   ` Herbert Xu
2006-07-21  8:51   ` Mark McLoughlin

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1153411868.2758.34.camel@localhost.localdomain \
    --to=markmc@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=jesse.brandeburg@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xen-devel@lists.xensource.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