netdev
[Top] [All Lists]

Re: [openib-general] Re: LLTX and netif_stop_queue

To: "David S. Miller" <davem@xxxxxxxxxxxxx>
Subject: Re: [openib-general] Re: LLTX and netif_stop_queue
From: Roland Dreier <roland@xxxxxxxxxxx>
Date: Sat, 18 Dec 2004 09:58:15 -0800
Cc: netdev@xxxxxxxxxxx, openib-general@xxxxxxxxxx
In-reply-to: <528y7vobze.fsf@topspin.com> (Roland Dreier's message of "Sat, 18 Dec 2004 07:35:49 -0800")
References: <52llbwoaej.fsf@topspin.com> <20041217214432.07b7b21e.davem@davemloft.net> <528y7vobze.fsf@topspin.com>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux)
    Roland> I may be missing something, but it seems to me that we get
    Roland> all of the benefits of LLTX by just documenting that
    Roland> device drivers can use the xmit_lock member of struct
    Roland> net_device to synchronize other parts of the driver
    Roland> against hard_start_xmit.  I guess the driver also should
    Roland> set xmit_lock_owner to -1 after it acquires xmit_lock.

Thinking about this a little more, I realize that there's no reason
for the driver to set xmit_lock_owner -- if the driver is able to
acquire the lock, then xmit_lock_owner will already be -1.

So it seems LLTX can be replaced by just having drivers use
net_device.xmit_lock instead of their own private tx_lock.  Assuming
this works (and I don't see anything wrong with it) then this seems
like a pretty nice solution: we remove some code from the networking
core and get rid of all the "trylock" logic in driver's hard_start_xmit.

 - Roland

<Prev in Thread] Current Thread [Next in Thread>