| To: | herbert@xxxxxxxxxxxxxxxxxxx |
|---|---|
| Subject: | Re: [PATCH]: Tigon3 new NAPI locking v2 |
| From: | "David S. Miller" <davem@xxxxxxxxxxxxx> |
| Date: | Thu, 16 Jun 2005 13:04:17 -0700 (PDT) |
| Cc: | netdev@xxxxxxxxxxx, mchan@xxxxxxxxxxxx |
| In-reply-to: | <20050616130453.GA23682@gondor.apana.org.au> |
| References: | <20050616113732.GA22367@gondor.apana.org.au> <20050616115945.GA23064@gondor.apana.org.au> <20050616130453.GA23682@gondor.apana.org.au> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Subject: Re: [PATCH]: Tigon3 new NAPI locking v2 Date: Thu, 16 Jun 2005 23:04:53 +1000 > On Thu, Jun 16, 2005 at 09:59:45PM +1000, herbert wrote: > > > > Actually, why don't we utilise the existing synchronize_irq mechanism? > > Here is what we could do. > > Oops, I should've left the smp_mb() in tg3_irq_quiesce since > synchronize_irq isn't a memory barrier. Wow, that's a very cool idea. :-) In fact, I think it will eliminate some (but definitely not all) of the races that the new locking code has. When you posted the patch with the atomic bitop added to the interrupt handler, I was going to tell you that the whole idea was to make it near zero cost to the interrupt fast path. :) |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | [PATCH] sk98lin: fix ethtool stats, Stephen Hemminger |
|---|---|
| Next by Date: | Re: [PATCH] uninitialized variable in prism54 isl38xx_trigger_device, Luis R. Rodriguez |
| Previous by Thread: | Re: [PATCH]: Tigon3 new NAPI locking v2, Herbert Xu |
| Next by Thread: | [PATCH 0/2] ieee80211: Update generic definitions to latest specs - take #2, Gertjan van Wingerde |
| Indexes: | [Date] [Thread] [Top] [All Lists] |