From: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
To: Erik Waling <erik.waling@konftel.se>
Cc: Erik Waling <Erik.Waling@konftel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] macb: RLE and BNA handling
Date: Wed, 14 Jan 2009 13:03:22 +0100 [thread overview]
Message-ID: <20090114130322.483a7830@hskinnemoen-d830> (raw)
In-Reply-To: <1231928868.10152.31.camel@konftel>
Erik Waling wrote:
> > > @@ -527,18 +529,31 @@ static int macb_poll(struct napi_struct
> > > dev_dbg(&bp->pdev->dev, "poll: status = %08lx, budget = %d\n",
> > > (unsigned long)status, budget);
> > >
> > > - if (!(status & MACB_BIT(REC))) {
> > > + if (status & MACB_BIT(REC)) {
> > > + work_done = macb_rx(bp, budget);
> > > + if (work_done < budget)
> > > + netif_rx_complete(dev, napi);
> > > + } else if (status & MACB_BIT(BNA)) {
> > > + /* No slots available in RX ring. Mark all slots
> > > + * as unused.
> > > + */
> > > + int i;
> > > +
> > > + dev_warn(&bp->pdev->dev,
> > > + "No free RX buffers. Marking all as unused.\n");
> > > +
> > > + for (i = 0; i < RX_RING_SIZE; i++)
> > > + bp->rx_ring[i].addr &= ~MACB_BIT(RX_USED);
> > > +
> > > + wmb();
> > > + netif_rx_complete(dev, napi);
> >
> > I'm not sure if nuking all the buffers that were received successfully
> > is the right thing to do here...?
> >
>
> This was the only solution I could think of since all slots are marked
> as used and we are not able to assemble a complete frame. Do you think
> there is a better solution?
No, I guess that might be a good fallback solution if we really can't
seem to make any progress...
However, I'm wondering if there might be a different bug in the code
above: Suppose that we receive lots of frames, start processing them,
but exhaust our budget so that we return before we had a chance to look
at all of them.
Then, when the network layer calls us again, we will only continue
processing the buffers if the REC bit was set in the mean time, which
it might not be if there was a brief pause in the flow of packets. If
this happens, we'll simply display a warning and call
netif_rx_complete() with potentially lots of unprocessed packets in the
RX ring...
So I'm wondering if the right thing to do is to just call macb_rx()
regardless of the state of the REC bit. If it exhausts the budget, and
the BNA bit is set, we could flush the ring in order to sort of relieve
the pressure a bit...
Btw, I suspect you'll need to update rx_tail when you do that, or it
might not point to where the next used buffer will be.
Haavard
next prev parent reply other threads:[~2009-01-14 12:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-13 16:21 [PATCH] macb: RLE and BNA handling Erik Waling
2009-01-14 7:47 ` Erik Waling
2009-01-14 10:15 ` Haavard Skinnemoen
2009-01-14 10:27 ` Erik Waling
2009-01-14 12:03 ` Haavard Skinnemoen [this message]
2009-01-15 13:37 ` Erik Waling
2009-03-26 9:38 ` Erik Waling
2009-03-30 12:04 ` Haavard Skinnemoen
2009-03-31 14:50 ` Erik Waling
2009-04-01 9:31 ` Haavard Skinnemoen
2009-04-01 13:05 ` Erik Waling
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=20090114130322.483a7830@hskinnemoen-d830 \
--to=haavard.skinnemoen@atmel.com \
--cc=Erik.Waling@konftel.com \
--cc=erik.waling@konftel.se \
--cc=linux-kernel@vger.kernel.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