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
|