Re: problems with e1000 and jumboframes

["Chris Leech" <chris.leech@gmail.com>]

On 8/3/06, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:

> > Strange, why this skb_shared_info cannon be added before first alignment?
> > And what about smaller frames like 1500, does this driver behave similar
> > (first align then add)?
>
> It can be.
> Could attached  (completely untested) patch help?

Note that e1000 uses power of two buffers because that's what the
hardware supports.  Also, there's no program able MTU - only a single
bit for "long packet enable" that disables frame length checks when
using jumbo frames.  That means that if you tell the e1000 it has a
16k buffer, and a 16k frame shows up on the wire, it's going to write
to the entire 16k regardless of your 9k MTU setting.  If a 32k frame
shows up, two full 16k buffers get written to (OK, assuming the frame
can fit into the receive FIFO)

That's why I've always been against trying to optimize the allocation
sizes in the driver, even with your small change the skb_shinfo area
can get corrupted.  It may be unlikely, because the frame still has to
be valid, but some switches aren't real picky about what sized frame
they'll forward on if you enable jumbo support either.  So any box on
the LAN could send you larger than MTU frames in an attempt to corrupt
memory.

I believe that if you tell a hardware device it has a buffer of a
certain size, you need to be prepared for that entire buffer to get
written to.  Unfortunately that means wasteful allocations for e1000
if a single buffer per frame is going to be used.

- Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/