From: Wolfgang Grandegger <wg@grandegger•com>
To: Grant Likely <grant.likely@secretlab•ca>
Cc: linuxppc-dev <Linuxppc-dev@ozlabs•org>
Subject: Re: Bestcomm trouble with NAPI for MPC5200 FEC
Date: Fri, 10 Jul 2009 09:37:25 +0200 [thread overview]
Message-ID: <4A56EFB5.1020309@grandegger.com> (raw)
In-Reply-To: <fa686aa40907091422v3e93fc50j5fc30f99077a8df6@mail.gmail.com>
Grant Likely wrote:
> On Thu, Jul 9, 2009 at 2:33 PM, Wolfgang Grandegger<wg@grandegger•com> wrote:
>> Hello,
>>
>> I'm currently trying to implement NAPI for the FEC on the MPC5200 to
>> solve the well known problem, that network packet storms can cause
>> interrupt flooding, which may totally block the system.
>
> Good to hear it! Thanks for this work.
>
>> The NAPI
>> implementation, in principle, is straight forward and works
>> well under normal and moderate network load. It just calls disable_irq()
>> in the receive interrupt handler to defer packet processing to the NAPI
>> poll callback, which calls enable_irq() when it has processed all
>> packets. Unfortunately, under heavy network load (packet storm),
>> problems show up:
>>
>> - With DENX 2.4.25, the Bestcomm RX task gets and remains stopped after
>> a while under additional system load. I have no idea how and when
>> Bestcom tasks are stopped. In the auto-start mode, the firmware should
>> poll forever for the next free descriptor block.
Do you know when the Bestcomm firmware does stop the task? I have the
impression that it happens when all buffer descriptors are used (RX
queue full).
>> - With 2.6.31-rc2, the RFIFO error occurs quickly which does reset the
>> FEC and Bestcomm (unfortunately, this does trigger an oops because
>> it's called from the interrupt context, but that's another issue).
>>
>> I'm realized that working with Bestcomm is a pain :-( but so far I have
>> little knowledge of the Bestcomm limitations and quirks. Any idea what
>> might go wrong or how to implement NAPI for that FEC properly.
>
> Yes, I have a few ideas. First, I suspect that the FEC rx queue isn't
> big enough and I wouldn't be surprised if the RFIFO error is occurring
> because Bestcomm gets overrun. This scenario needs to be handled more
> gracefully.
The RFIFO error does not show up with DENX 2.4.25 and therefore I'm not
sure if overruns are a real problem.
> Second, I think resetting the PHY should be removed from the reset
> path. The phy doesn't at all need to be reset and doing this would
> avoid the OOPS condition. Also, in the RFIFO error path needs to be
> audited to make sure that all the good received packets are processed
> correctly before resetting the BCOM engine and to make sure that
> skbufs are not getting leaked.
Agreed, the manual says: "When this occurs, software must ensure both
the FIFO Controller and BestComm are soft-reset."
> Essentially, I think that the RFIFO error condition is currently
> handled in far too heavy handed a manner and it should not be
> expensive to recover from.
Yep, it looks like.
Wolfgang.
next prev parent reply other threads:[~2009-07-10 7:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-09 20:33 Bestcomm trouble with NAPI for MPC5200 FEC Wolfgang Grandegger
2009-07-09 21:22 ` Grant Likely
2009-07-10 7:37 ` Wolfgang Grandegger [this message]
2009-07-10 9:16 ` Wolfgang Grandegger
2009-07-10 8:08 ` Wolfram Sang
2009-07-10 8:26 ` Wolfgang Grandegger
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=4A56EFB5.1020309@grandegger.com \
--to=wg@grandegger$(echo .)com \
--cc=Linuxppc-dev@ozlabs$(echo .)org \
--cc=grant.likely@secretlab$(echo .)ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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