[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071213102233.3727e9a0@freepuppy.rosehill>
Date: Thu, 13 Dec 2007 10:22:33 -0800
From: Stephen Hemminger <shemminger@...ux-foundation.org>
To: David Miller <davem@...emloft.net>
Cc: gallatin@...i.com, joonwpark81@...il.com, auke-jan.h.kok@...el.com,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
jgarzik@...ox.com, jesse.brandeburg@...el.com
Subject: Re: [RFC] net: napi fix
On Thu, 13 Dec 2007 06:19:38 -0800 (PST)
David Miller <davem@...emloft.net> wrote:
> From: Andrew Gallatin <gallatin@...i.com>
> Date: Thu, 13 Dec 2007 09:13:54 -0500
>
> > If the netif_running() check is indeed required to make a device break
> > out of napi polling and respond to an ifconfig down, then I think the
> > netif_running() check should be moved up into net_rx_action() to avoid
> > potential for driver complexity and bugs like the ones you found.
>
> That, or something like it, definitely sounds reasonable and much
> better than putting the check into every driver :-)
> --
> 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
It is not possible to do netif_running() check in generic code as currently
written because of the case of devices where a single NAPI object is
being used to handle two devices. The association between napi and netdevice
is M to N. There are cases like niu that have multiple NAPI's and one
netdevice; and devices like sky2 that can have one NAPI and 2 netdevice's.
The existing pointer from napi to netdevice is only used by netconsole
now. For devices like sky2 it means that netconsole can't work on the the
second port which is a not a big problem. But adding a netif_running()
check would be a big issue.
--
Stephen Hemminger <shemminger@...ux-foundation.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists