From: Benjamin Herrenschmidt <benh@kernel•crashing.org>
To: Eric Lemoine <eric.lemoine@gmail•com>
Cc: "David S. Miller" <davem@davemloft•net>, netdev@vger•kernel.org
Subject: Re: [sungem] proposal for a new locking strategy
Date: Mon, 06 Nov 2006 00:05:39 +1100 [thread overview]
Message-ID: <1162731940.28571.245.camel@localhost.localdomain> (raw)
In-Reply-To: <5cac192f0611050500m19f72209vc349f235680023a1@mail.gmail.com>
On Sun, 2006-11-05 at 14:00 +0100, Eric Lemoine wrote:
> Hi!
>
> Some (long) time ago benh wrote a blaming comment in sungem.c about
> that driver's locking strategy. That comment basically says that we
> probably don't need two spinlocks.
Yeah :) Note that I mostly blamed myself there ... Just never found the
time to sit down a figure out a proper locking.
> I agree!
>
> Proposal:
>
> Today's sungem effectively uses two spinlock's: "lock" and "tx_lock".
>
> "tx_lock" is held by the xmit function when sending out a packet. Lots
> of functions grab "tx_lock" not to mess up with xmit (gem_stop_phy(),
> gem_change_mtu(), etc.).
>
> All of these funcs also take "lock"!
>
> What we could do is remove "lx_lock", have the above functions take
> only "lock", and rely on dev->_xmit_lock to protect the xmit func from
> reentrance. In that case, obviously, the driver wouldn't feature LLTX
> anymore.
We could probably do even better but yeah, a single lock is a good
start. Overall, I'm unhappy with the infrastructure provided by the
network stack though. (Might be better nowadays, but last I looked, for
example, I couldn't properly do things like stopping MAPI poll from
set_multicast etc... due to locks held by the upper level).
> When (re-)configuring we'd now quiesce the device, with the new
> functions gem_netif_stop() and gem_full_lock(), in the same way as tg3
> does.
>
> gem_interrupt(), gem_poll(), and gem_start_xmit() could become lockless. Fast!
>
> Basically this proposal makes the data path faster, the control path
> slower, and simplifies the code by using one single spinlock within
> the driver.
>
> If the idea seems reasonable to you guys I can go ahead and cook up something...
I certainly does. Bring on the patch ! :-)
Ben.
next prev parent reply other threads:[~2006-11-05 13:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-05 13:00 [sungem] proposal for a new locking strategy Eric Lemoine
2006-11-05 13:05 ` Benjamin Herrenschmidt [this message]
2006-11-05 13:17 ` Eric Lemoine
2006-11-05 17:02 ` Stephen Hemminger
2006-11-05 17:28 ` Eric Lemoine
2006-11-05 17:41 ` Stephen Hemminger
2006-11-05 17:52 ` Eric Lemoine
2006-11-05 18:49 ` Stephen Hemminger
2006-11-05 20:11 ` Eric Lemoine
2006-11-06 17:55 ` Stephen Hemminger
2006-11-06 20:55 ` Eric Lemoine
2006-11-06 20:57 ` Stephen Hemminger
2006-11-06 21:10 ` Eric Lemoine
2006-11-06 21:49 ` Stephen Hemminger
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=1162731940.28571.245.camel@localhost.localdomain \
--to=benh@kernel$(echo .)crashing.org \
--cc=davem@davemloft$(echo .)net \
--cc=eric.lemoine@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/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