[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140329201939.GX7528@n2100.arm.linux.org.uk>
Date:	Sat, 29 Mar 2014 20:19:39 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Ben Hutchings <ben@...adent.org.uk>
Cc:	netdev@...r.kernel.org
Subject: Re: Proper suspend/resume flow
On Sat, Mar 29, 2014 at 08:08:14PM +0000, Ben Hutchings wrote:
> On Sat, 2014-03-29 at 18:03 +0000, Russell King - ARM Linux wrote:
> [...]
> > That said, for the case where a network driver does all it's packet
> > processing in the NAPI poll function, I think calling napi_disable()
> > is a good way to ensure that the poll function is not running, and
> > therefore there are can be no netif_wake_queue() calls - or anything
> > other than the ndo_start_xmit touching the rings or the device.  This
> > is needed anyway to stop receive packet processing looking at its
> > ring.
> > 
> > So, I've now come to this sequence:
> > 
> > suspend()
> > {
> > 	if (netif_running()) {
> > 		napi_disable();
> > 		netif_tx_lock();
> > 		netif_device_detach();
> > 		netif_tx_unlock();
> > 	}
> > 	... suspend device ...
> > }
> [...]
> 
> This is missing netif_stop_queue(), but I assume you do that somewhere
> after netif_device_detach().  I think this should work.
Ah, that's covered by netif_device_detach():
        if (test_and_clear_bit(__LINK_STATE_PRESENT, &dev->state) &&
            netif_running(dev)) {
                netif_tx_stop_all_queues(dev);
        }
provided __LINK_STATE_PRESENT was previously set, and the interface
was running.
netif_tx_stop_all_queues() is:
        for (i = 0; i < dev->num_tx_queues; i++) {
                struct netdev_queue *txq = netdev_get_tx_queue(dev, i);
                netif_tx_stop_queue(txq);
        }
so with the above sequence, we end up stopping all queues under the
xmit lock.
-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists
 
