public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Chris Leech <chris.leech@gmail.com>
To: "David S. Miller" <davem@redhat.com>,
	shane@hathawaymix.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] e1000 rx buffer allocation
Date: Fri, 27 Aug 2004 11:36:36 -0700	[thread overview]
Message-ID: <41b516cb04082711363a009dbc@mail.gmail.com> (raw)
In-Reply-To: <20040826181843.342da7a3.davem@redhat.com>

On Thu, 26 Aug 2004 18:18:43 -0700, David S. Miller <davem@redhat.com> wrote:
> On Thu, 26 Aug 2004 17:35:38 -0600 (MDT)
> shane@hathawaymix.org wrote:
> 
> > Independently of my patch, I'm a little concerned about what will happen
> > if the driver runs out of rx buffers.  Ideally, it will just drop packets,
> > but I wonder if the code will panic instead.
> 
> It is a good question.  Some chips are known to hang when
> the rx buffer has no entries in it and a packet arrives.

The e1000 driver and PRO/1000 hardware don't have a problem with that,
other than dropping packets until receive buffers become available. 
Packets that make it into the receive FIFO, but then stall because
there are no buffers available, cause the "receive no buffers" counter
to increment and sit in the FIFO until a buffer is available.  Packets
that are received once the FIFO is full cause the "missed packet"
counter to increment and are dropped.

As for moving the allocations out of the hard interrupt context, e1000
was one of several drivers that tried that a few years back by using
tasklets.  What I found is that if you split the allocation from the
receive processing, it's far to easy to generate an interrupt load
which starves the skb allocations.  The result is that you
continuously use all of the buffers then stall while they all get
replaced, and performance is horrible.  But if the patch works for
your network load ...

A better approach for improving jumbo frame allocations might be to
use multiple smaller buffers for each receive, something the PRO/1000
hardware can do but the e1000 driver has never taken advantage of.

Dave, you mentioned the possibility of drivers doing that in a
conversation with Harald about handling fragmented packets
(http://marc.theaimsgroup.com/?l=linux-netdev&m=109293677816177&w=2) 
What would be the more correct approach to this?  Putting all receive
data into page allocations and filling out the frags array, or
chaining together small skbs using the frag_list?

- Chris

  reply	other threads:[~2004-08-27 18:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-26 23:35 [PATCH] e1000 rx buffer allocation shane
2004-08-27  1:18 ` David S. Miller
2004-08-27  1:18 ` David S. Miller
2004-08-27 18:36   ` Chris Leech [this message]
2004-08-27 19:36     ` David S. Miller
2004-08-28  2:27     ` Shane Hathaway

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=41b516cb04082711363a009dbc@mail.gmail.com \
    --to=chris.leech@gmail.com \
    --cc=davem@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shane@hathawaymix.org \
    /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