From: David Gibson <david@gibson.dropbear.id.au>
To: Wolfgang Wegner <ww@kt.e-technik.uni-dortmund.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.4.18 orinoco.c __orinoco_ev_rx question
Date: Mon, 3 Jun 2002 16:24:18 +1000 [thread overview]
Message-ID: <20020603062418.GG6765@zax> (raw)
In-Reply-To: <20020528160135.D24097@bigmac.e-technik.uni-dortmund.de> <20020529032822.GA16537@zax> <20020529090613.B28699@bigmac.e-technik.uni-dortmund.de>
On Wed, May 29, 2002 at 09:06:13AM +0200, Wolfgang Wegner wrote:
> Hi David,
> On Wed, May 29, 2002 at 01:28:22PM +1000, David Gibson wrote:
> > No it doesn't have to be done in the interrupt handler, it could be
> > done in a bottom half. However essentially every other network driver
> > does all the Rx work (up to netif_rx()) in the hard irq, so I'm
> > disinclined to do it otherwise.
> well, you have a point here.
> However, my observation shows that this blocks interrupts for quite a
> long time (800us, compared to the 700us which i remember being shouted
> at in another discussion some days ago), which is quite a lot. (IMHO)
> Furthermore, airo.c either has a faster way of doing so or the Cisco
> PCM-352 are faster by themselves. (Did not look into airo.c as close
> as orinoco.c...)
Yes, that is quite a long time. How long does it take in the airo
driver? If it's possible to speed up the orinoco.c interrupt handler,
rather than moving stuff into a BH I'd prefer to do that.
It's possible the Cisco cards are just faster, although I would have
thought it a bit unlikely, since I beleive the recent Cisco's are
based on the same MAC controller as the Lucent and Intersil cards (but
different firmware).
> It was just a question if it could be done.
>
> I would like to try it, so another question (the rxfid stuff...):
>
> Could I leave just getting the rxfid (rxfid = hermes_read_regn(hw, RXFID);)
> in the interrupt handler and let the bottom half process something like
> a list of FIDs filled by the interrupt handler, or is there any caveat
> in doing so? Would it be better (if at all possible) to leave reading
> in the head in the interrupt handler, such that the status could be
> evaluated and do just the copying of data (which i suspect to be the most
> time-consuming) from the bottom half?
Yes, it's possible. It adds significant complexity though, so I'd
really prefer not to.
--
David Gibson | For every complex problem there is a
david@gibson.dropbear.id.au | solution which is simple, neat and
| wrong. -- H.L. Mencken
http://www.ozlabs.org/people/dgibson
prev parent reply other threads:[~2002-06-03 6:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-28 14:01 2.4.18 orinoco.c __orinoco_ev_rx question Wolfgang Wegner
2002-05-29 3:28 ` David Gibson
2002-05-29 7:06 ` Wolfgang Wegner
2002-06-03 6:24 ` David Gibson [this message]
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=20020603062418.GG6765@zax \
--to=david@gibson.dropbear.id.au \
--cc=linux-kernel@vger.kernel.org \
--cc=ww@kt.e-technik.uni-dortmund.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.