On Fri, Aug 04, 2006 at 04:31:11PM -0700, David Miller wrote:
> Yes, it's meant to catch unintented races.
>
> The queueing layer that calls ->hard_start_xmit() technically has no
> need to support NETDEV_TX_BUSY as a return value, since the device
> is able to prevent this.
>
> If we could avoid NETDEV_TX_BUSY et al. from happening, the idea is
> that we could eliminate all of the requeueing logic in the packet
> scheduler layer. It is a pipe dream from many years ago.
Maybe the way NETDEV_TX_BUSY is implemented is wrong -- that is, it should
be possible to return a result saying "we sent the packet, but the queue is
now full". That would eliminate the atomic op that netif_queue_stop()
performs and allow higher layers to merge the necessary barrier on the full
case with the op on the tx lock. That way we could have lockless queue
handling within the driver. This might need start/stop sequence counters,
though.
-ben
--
"Time is of no importance, Mr. President, only life is important."
Don't Email: <[EMAIL PROTECTED]>.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
