From: Jeff Garzik <jgarzik@pobox.com>
To: "David S. Miller" <davem@davemloft.net>
Cc: netdev@oss.sgi.com, mchan@broadcom.com
Subject: Re: [PATCH]: Tigon3 new NAPI locking v2
Date: Fri, 03 Jun 2005 16:23:07 -0400 [thread overview]
Message-ID: <42A0BC2B.4020409@pobox.com> (raw)
In-Reply-To: <20050603.122558.88474819.davem@davemloft.net>
David S. Miller wrote:
> [TG3]: Eliminate all hw IRQ handler spinlocks.
>
> Move all driver spinlocks to be taken at sw IRQ
> context only.
>
> This fixes the skb_copy() we were doing with hw
> IRQs disabled (which is illegal and triggers a
> BUG() with HIGHMEM enabled). It also simplifies
> the locking all over the driver tremendously.
>
> We accomplish this feat by creating a special
> sequence to synchronize with the hw IRQ handler
> using a 2-bit atomic state.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
overall, pretty spiffy :)
As further work, I would like to see how much (alot? all?) of the timer
code could be moved into a workqueue, where we could kill the last of
the horrible-udelay loops in the driver. Particularly awful is
while (++tick < 195000) {
status = tg3_fiber_aneg_smachine(tp, &aninfo);
if (status == ANEG_DONE || status == ANEG_FAILED)
break;
udelay(1);
}
where you could freeze a uniprocess box (lock out everything but
interrupts) for over 1 second. IOW, the slower the phy, the more these
slow-path delays can affect the overall system.
This is a MINOR, low priority issue; but long delays are uglies that
should be fixed, if its relatively painless.
> +static void tg3_irq_quiesce(struct tg3 *tp)
> +{
> + BUG_ON(test_bit(TG3_IRQSTATE_SYNC, &tp->irq_state));
> +
> + set_bit(TG3_IRQSTATE_SYNC, &tp->irq_state);
> + smp_mb();
> + tw32(GRC_LOCAL_CTRL,
> + tp->grc_local_ctrl | GRC_LCLCTRL_SETINT);
> +
> + while (!test_bit(TG3_IRQSTATE_COMPLETE, &tp->irq_state)) {
> + u32 val = tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW);
> +
> + if (val == 0x00000001)
> + break;
> +
> + cpu_relax();
> + }
> +}
* This loop makes me nervous... If there's a fault on the PCI bus or
the hardware is unplugged, val will equal 0xffffffff.
* A few comments for normal humans like "force an interrupt" and "wait
for interrupt handler to complete" might be nice.
* a BUG_ON(if-interrupts-are-disabled) line might be nice
> +static inline int tg3_irq_sync(struct tg3 *tp)
> +{
> + if (test_bit(TG3_IRQSTATE_SYNC, &tp->irq_state)) {
> + set_bit(TG3_IRQSTATE_COMPLETE, &tp->irq_state);
> + return 1;
> + }
> + return 0;
> +}
> +
> +/* Fully shutdown all tg3 driver activity elsewhere in the system.
> + * If irq_sync is non-zero, then the IRQ handler must be synchronized
> + * with as well. Most of the time, this is not necessary except when
> + * shutting down the device.
> + */
> +static inline void tg3_full_lock(struct tg3 *tp, int irq_sync)
> +{
> + if (irq_sync)
> + tg3_irq_quiesce(tp);
> + spin_lock_bh(&tp->lock);
> + spin_lock(&tp->tx_lock);
> +}
Rather than an 'irq_sync' arg, my instinct would have been to create
tg3_full_lock() and tg3_full_lock_sync(). This makes the action -much-
more obvious to the reader, and since its inline doesn't cost anything
(compiler's optimizer even does a tiny bit less work my way).
Jeff
next prev parent reply other threads:[~2005-06-03 20:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-03 19:25 [PATCH]: Tigon3 new NAPI locking v2 David S. Miller
2005-06-03 20:23 ` Jeff Garzik [this message]
2005-06-06 6:01 ` David S. Miller
2005-06-07 10:11 ` Greg Banks
2005-06-21 20:21 ` David S. Miller
2005-06-16 11:37 ` Herbert Xu
2005-06-16 11:59 ` Herbert Xu
2005-06-16 13:04 ` Herbert Xu
2005-06-16 20:04 ` David S. Miller
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=42A0BC2B.4020409@pobox.com \
--to=jgarzik@pobox.com \
--cc=davem@davemloft.net \
--cc=mchan@broadcom.com \
--cc=netdev@oss.sgi.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 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.