All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, ruediger.herbst@googlemail.com,
	bhamilton04@gmail.com
Subject: Re: [RFC/PATCH] sungem: Spring cleaning and GRO support
Date: Wed, 01 Jun 2011 13:45:07 +1000	[thread overview]
Message-ID: <1306899907.29297.12.camel@pasglop> (raw)
In-Reply-To: <20110531.194115.486383514.davem@davemloft.net>


> And I think I see what the problem is:
> 
> > +	if (unlikely(netif_queue_stopped(dev) &&
> > +		     TX_BUFFS_AVAIL(gp) > (MAX_SKB_FRAGS + 1))) {
> > +		netif_tx_lock(dev);
> > +		if (netif_queue_stopped(dev) &&
> > +		    TX_BUFFS_AVAIL(gp) > (MAX_SKB_FRAGS + 1))
> > +			netif_wake_queue(dev);
> > +		netif_tx_unlock(dev);
> > +	}
> >  }
> 
> Don't use netif_tx_lock(), that has a loop and multiple atomics :-)
> 
> It's going to grab a special global TX lock, and then grab a lock for
> TX queue zero, and finally set an atomic state bit in TX queue zero.
> 
> Take a look at the implementation in netdevice.h

Ah good point ! I think I stole that from another driver (or I just had
a brain fart), indeed, it's bad.

> It's a special "lock everything TX", a mechanism for multiqueue
> drivers to shut quiesce all TX queue activity safely in one operation.
> 
> Instead, do something like:
> 
> 	struct netdev_queue *txq = netdev_get_tx_queue(dev, 0);
> 
> 	__netif_tx_lock(txq, smp_processor_id();
> 	...
> 	__netif_tx_unlock(txq);
> 
> and I bet your TX numbers improve a bit.

Right, I'll give that a go. With the assistance of the other Ben H I've
been able to simplify the driver a lot more now too. mutex and remaining
lock are gone, rtnl lock does the job fine for synchronizing vs. reset
task and I cleared up a ton more of unused bits and pieces now that we
don't deal with link timer when the thing is off anymore.

I'll have a new patch later today hopefully with new numbers.

Cheers,
Ben.



  reply	other threads:[~2011-06-01  3:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-31  7:59 [RFC/PATCH] sungem: Spring cleaning and GRO support Benjamin Herrenschmidt
2011-05-31 20:59 ` Ben Hutchings
2011-05-31 21:58   ` Benjamin Herrenschmidt
2011-05-31 22:17     ` Ben Hutchings
2011-05-31 23:55       ` Benjamin Herrenschmidt
2011-06-01  0:04         ` Ben Hutchings
2011-06-01  2:41 ` David Miller
2011-06-01  3:45   ` Benjamin Herrenschmidt [this message]
2011-06-01  6:24   ` Benjamin Herrenschmidt
2011-06-01  6:35     ` David Miller

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=1306899907.29297.12.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=bhamilton04@gmail.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=ruediger.herbst@googlemail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.