From: Eric Dumazet <eric.dumazet@gmail.com>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: David Miller <davem@davemloft.net>,
sergei.shtylyov@cogentembedded.com, netdev@vger.kernel.org,
nobuhiro.iwamatsu.yj@renesas.com, linux-sh@vger.kernel.org
Subject: Re: [PATCH] sh_eth: NAPI requires netif_receive_skb()
Date: Thu, 26 Sep 2013 09:59:19 -0700 [thread overview]
Message-ID: <1380214759.3165.201.camel@edumazet-glaptop> (raw)
In-Reply-To: <Pine.LNX.4.64.1309261751200.11968@axis700.grange>
On Thu, 2013-09-26 at 18:12 +0200, Guennadi Liakhovetski wrote:
> Hi
>
> On Wed, 4 Sep 2013, David Miller wrote:
>
> > From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> > Date: Tue, 3 Sep 2013 03:03:10 +0400
> >
> > > Driver supporting NAPI should use NAPI-specific function for receiving packets,
> > > so netif_rx() should be changed to netif_receive_skb().
> > >
> > > Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> This patch breaks NFS boot on Armadillo800eva for me. Network
> communication slows down to a crawl with
>
> net eth0: Receive FIFO Overflow
> nfs: server 192.168.x.y not responding, still trying
>
> With this patch reverted (e.g. in today's Linus tree snapshot) boot is
> restored.
RX_RING_SIZE is 64
This driver refills the Rx ring buffers only _after_ the loop to drain
ready buffers. This was OK with the previous behavior (netif_rx() is
damn fast)
With this low amount of buffers, underrun can happen with the new code,
as netif_receive_skb() adds delay during the drain.
Most likely driver needs to refill buffers one by one (or small batches)
instead of in one go after the drain.
next prev parent reply other threads:[~2013-09-26 16:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-02 23:03 [PATCH] sh_eth: NAPI requires netif_receive_skb() Sergei Shtylyov
2013-09-04 18:12 ` David Miller
2013-09-26 16:12 ` Guennadi Liakhovetski
2013-09-26 16:59 ` Eric Dumazet [this message]
2013-10-08 21:52 ` Sergei Shtylyov
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=1380214759.3165.201.camel@edumazet-glaptop \
--to=eric.dumazet@gmail.com \
--cc=davem@davemloft.net \
--cc=g.liakhovetski@gmx.de \
--cc=linux-sh@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nobuhiro.iwamatsu.yj@renesas.com \
--cc=sergei.shtylyov@cogentembedded.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