From: jamal <hadi@cyberus.ca>
To: David Miller <davem@davemloft.net>
Cc: herbert@gondor.apana.org.au, netdev@vger.kernel.org,
kaber@trash.net, dada1@cosmosbay.com, johnpol@2ka.mipt.ru
Subject: Re: [RFC][NET_SCHED] explict hold dev tx lock
Date: Sun, 16 Sep 2007 17:10:00 -0400 [thread overview]
Message-ID: <1189977000.4230.25.camel@localhost> (raw)
In-Reply-To: <1189975939.4230.19.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 331 bytes --]
On Sun, 2007-16-09 at 16:52 -0400, jamal wrote:
> What i should say is
> if i grabbed the lock explicitly without disabling irqs it wont be much
> different than what is done today and should always work.
> No?
And to be more explicit, heres a patch using the macros from previous
patch. So far tested on 3 NICs.
cheers,
jamal
[-- Attachment #2: nsqr2 --]
[-- Type: text/x-patch, Size: 1204 bytes --]
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index e970e8e..1ae905e 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -134,34 +134,18 @@ static inline int qdisc_restart(struct net_device *dev)
{
struct Qdisc *q = dev->qdisc;
struct sk_buff *skb;
- unsigned lockless;
int ret;
/* Dequeue packet */
if (unlikely((skb = dev_dequeue_skb(dev, q)) == NULL))
return 0;
- /*
- * When the driver has LLTX set, it does its own locking in
- * start_xmit. These checks are worth it because even uncongested
- * locks can be quite expensive. The driver can do a trylock, as
- * is being done here; in case of lock contention it should return
- * NETDEV_TX_LOCKED and the packet will be requeued.
- */
- lockless = (dev->features & NETIF_F_LLTX);
-
- if (!lockless && !netif_tx_trylock(dev)) {
- /* Another CPU grabbed the driver tx lock */
- return handle_dev_cpu_collision(skb, dev, q);
- }
-
/* And release queue */
spin_unlock(&dev->queue_lock);
+ HARD_TX_LOCK(dev, smp_processor_id());
ret = dev_hard_start_xmit(skb, dev);
-
- if (!lockless)
- netif_tx_unlock(dev);
+ HARD_TX_UNLOCK(dev);
spin_lock(&dev->queue_lock);
q = dev->qdisc;
next prev parent reply other threads:[~2007-09-16 21:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-16 16:14 [RFC][NET_SCHED] explict hold dev tx lock jamal
2007-09-16 19:31 ` David Miller
2007-09-16 20:41 ` jamal
2007-09-16 20:52 ` jamal
2007-09-16 21:10 ` jamal [this message]
2007-09-17 10:27 ` Evgeniy Polyakov
2007-09-17 13:03 ` jamal
2007-09-17 13:58 ` Evgeniy Polyakov
2007-09-18 2:01 ` David Miller
2007-09-18 2:48 ` jamal
2007-09-19 13:33 ` jamal
2007-09-19 16:09 ` David Miller
2007-09-20 2:33 ` jamal
2007-09-20 2:43 ` jamal
2007-09-26 2:28 ` David Miller
2007-09-26 13:11 ` jamal
2007-10-09 4:00 ` Herbert Xu
2007-10-09 13:43 ` jamal
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=1189977000.4230.25.camel@localhost \
--to=hadi@cyberus.ca \
--cc=dada1@cosmosbay.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=johnpol@2ka.mipt.ru \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).