netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephan von Krawczynski <skraw@ithnet.com>
To: "Brandeburg, Jesse" <jesse.brandeburg@intel.com>
Cc: e1000-devel@lists.sf.net, netdev@vger.kernel.org, w@1wt.eu
Subject: Re: e1000 and 802.1ad/stacked vlan tagging
Date: Tue, 29 Aug 2006 12:58:21 +0200	[thread overview]
Message-ID: <20060829125821.b953a646.skraw@ithnet.com> (raw)
In-Reply-To: <36D9DB17C6DE9E40B059440DB8D95F52866B22@orsmsx418.amr.corp.intel.com>

On Mon, 28 Aug 2006 13:53:36 -0700
"Brandeburg, Jesse" <jesse.brandeburg@intel.com> wrote:

> > I tried enlarging both real-device and first vlan interface mtu but
> > that does not work out. I really thought that the visible device
> > setting of mtu=1500 should have worked out and that the driver (or
> > some code in between) should have corrected the allowed frame size to
> > reflect the actual setup, not? 
> 
> unfortunately I believe that your hardware MTU on the base interface
> MUST be adjusted in order to do stacked vlans because the vlan code
> doesn't fragment packets, it just inserts tags.  The e1000 hardware is
> capable of inserting/stripping 1 level of tags without dropping overlong
> frames, but cannot seamlessly handle 1+n levels of inserted tags.
> Transmit, we don't care how long the frames are that are given to us
> (the driver doesn't enforce MTU on transmit) but on receive we have
> limited space so it is important that each frame fit into the allocated
> buffer (including CRC).
> 
> Please try MTU 1508 on eth0 (base interface only), as that configuration
> worked for me.

Hello Jesse,

I can confirm that the setup seems to work if enlarging the hw if mtu to 1508.
This is good.
Nevertheless I think that the receive buffer size of a physical device should
always be MAX(all virtual device mtu + tags and the like), you know what I
mean.
If I enlarge the basic mtu this may or may not have drawbacks concerning the
traffic routed directly via this interface.
Obviously the setup is somehow not consistent, as everything works well
without tuning mtus as long as you use only 1 tag. I always thought that the
driver uses at least hard_header_len + mtu as buffer size which should be
correct even in stacked setup. Only this information doesn't make it to the
driver level, right?

-- 
Regards,
Stephan von Krawczynski


  reply	other threads:[~2006-08-29 10:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-28 20:53 e1000 and 802.1ad/stacked vlan tagging Brandeburg, Jesse
2006-08-29 10:58 ` Stephan von Krawczynski [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-08-30  5:06 Brandeburg, Jesse
     [not found] <36D9DB17C6DE9E40B059440DB8D95F5286678F@orsmsx418.amr.corp.intel.com>
2006-08-28 17:38 ` Stephan von Krawczynski
2006-08-28 21:54   ` Ben Greear

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=20060829125821.b953a646.skraw@ithnet.com \
    --to=skraw@ithnet.com \
    --cc=e1000-devel@lists.sf.net \
    --cc=jesse.brandeburg@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=w@1wt.eu \
    /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;
as well as URLs for NNTP newsgroup(s).