search for: netdev_tx_locked

...USY. + * Returns NETDEV_TX_OK. Can return NETDEV_TX_BUSY, but you should stop + * the queue before that can happen; it's for obsolete devices and weird + * corner cases, but the stack really does a non-trivial amount + * of useless work if you return NETDEV_TX_BUSY. * (can also return NETDEV_TX_LOCKED iff NETIF_F_LLTX) * Required can not be NULL. *

commit d631b94e7a15277858ec5f88d674d93080506999 virtio: change comment in transmit started clarifying the logic behind queue state management, but introduced an inaccuracy: TX_BUSY does not cause a BUG message. Clean this up some more, explaining the tradeoffs in detail. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- diff --git a/drivers/net/virtio_net.c

commit d631b94e7a15277858ec5f88d674d93080506999 virtio: change comment in transmit started clarifying the logic behind queue state management, but introduced an inaccuracy: TX_BUSY does not cause a BUG message. Clean this up some more, explaining the tradeoffs in detail. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- diff --git a/drivers/net/virtio_net.c

This patch series resurrects the earlier multiple TX/RX queues functionality for virtio_net, and addresses the issues pointed out. It also includes an API to share irq's, f.e. amongst the TX vqs. I plan to run TCP/UDP STREAM and RR tests for local->host and local->remote, and send the results in the next couple of days. patch #1: Introduce VIRTIO_NET_F_MULTIQUEUE patch #2: Move

This patch series resurrects the earlier multiple TX/RX queues functionality for virtio_net, and addresses the issues pointed out. It also includes an API to share irq's, f.e. amongst the TX vqs. I plan to run TCP/UDP STREAM and RR tests for local->host and local->remote, and send the results in the next couple of days. patch #1: Introduce VIRTIO_NET_F_MULTIQUEUE patch #2: Move