jamal wrote:

I beginuing to think thats the simplest way to achieve this: i.e not to
stop the queue but rather to let the packets continue showing up and
drop them at the driver when the link is down . The netlink async
carrier signal to the app is to be used to reroute instead of being a
signal to flush buffers. In other words the other Thomas got it right
(with the exception of setting the IFF_RUNNIGN flags)

Jeff? 

I haven't heard anything to convince me that the same change should be 
deployed across NNN drivers.  The drivers already signal the net core 
that the link is down; to me, that implies there should be code in _one_ 
place that handles this condition, not NNN places.

Further,
* if this policy ("drop them in the driver") ever changes, we must again 
touch NNN drivers

* dropping them in the driver but not stopping the queue means that the 
system is allowed to continue to stream data into the driver, only for 
the driver to free it.  That will scale -- right up to (worst case) 100% 
CPU, with userland sending packets as fast as it can, and the driver 
dropping packets as fast as it can.  The only places the net stack 
currently checks carrier is dev_get_flags() and dev_watchdog().

* If you need a hook to flush the in-hardware buffers, add such a hook. 
  Don't hack it in like this.  Yeah, adding a hook touches NNN drivers 
but at least the hook is far more self-contained, it's semantics will be 
more clear, and it will increase the likelihood that the driver changes 
do not affect the hot path nor current netif_{start,stop}_queue() logic.

	Jeff