| 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@xxxxxxxxxxx> (Roland Dreier's message of "Sat, 18 Dec 2004 07:35:49 -0800") |
| References: | <52llbwoaej.fsf@xxxxxxxxxxx> <20041217214432.07b7b21e.davem@xxxxxxxxxxxxx> <528y7vobze.fsf@xxxxxxxxxxx> |
| 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> |
|---|---|---|
| ||
| Previous by Date: | [PATCH] PKT_SCHED: dsmark must take care of shared/cloned skbs, Thomas Graf |
|---|---|
| Next by Date: | Re: [openib-general] Re: LLTX and netif_stop_queue, Roland Dreier |
| Previous by Thread: | Re: LLTX and netif_stop_queue, Roland Dreier |
| Next by Thread: | Re: [openib-general] Re: LLTX and netif_stop_queue, Roland Dreier |
| Indexes: | [Date] [Thread] [Top] [All Lists] |