Re: workaround large MTU and N-order allocation failures

On Mon, Sep 19, 2005 at 01:08:22AM +0200, Francois Romieu wrote:
> Dan Aloni <[email protected]> :
> [...]
> > The problem with large MTU is external memory fragmentation in
> > the buddy system following high workload, causing alloc_skb() to 
> > fail.
> 
> If the issue hits the Rx path, it is probably the responsibility of
> the device driver. Which kind of hardware do you use ?

We are using a SuperMicro board and the network driver is e1000. The
revision of the chipset is 82546GB-copper (maps to e1000_82546_rev_3).

This particular chipset does not support packet splitting, so we
are looking for a hack on the skb layer.

-- 
Dan Aloni
[email protected], [email protected], [email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

---

• Follow-Ups:
  • Re: workaround large MTU and N-order allocation failures
    • From: Ganesh Venkatesan <[email protected]>

• References:
  • workaround large MTU and N-order allocation failures
    • From: Dan Aloni <[email protected]>
  • Re: workaround large MTU and N-order allocation failures
    • From: Francois Romieu <[email protected]>

• Prev by Date: Re: PATCH: Fix race in cpu_down (hotplug cpu)
• Next by Date: Re: Why don't we separate menuconfig from the kernel?
• Previous by thread: Re: workaround large MTU and N-order allocation failures
• Next by thread: Re: workaround large MTU and N-order allocation failures
• Index(es):
  • Date
  • Thread

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]