On Fri, Jun 19, 2009 at 11:20:44PM +0930, Rusty Russell wrote:
>
> Your use of the word guarantee here indicates an idealized concept of QoS
> which cannot exist on any NIC which has a queue. We should try to approach
> the ideal, but understand we cannot reach it.
I'm just pointing out that it's better to not have to do this.
Since TX_BUSY and requeueing the packet is unnecessary in the
first place because we can avoid it by managing the stop-queue
action properly, there is no reason to do this because of its
downsides.
> On the other hand, we're underutilizing the queue to avoid it. I find that a
> little embarrassing.
Here's why I think this is not an issue. If your NIC is high
bandwidth then your ring is going to have to be huge so the
amount that is underutilised (a 64K packet) is tiny. If your
NIC is low bandwidth then this is where you often need QoS and
in that case you do *NOT* want to fully utilise the HW queue.
> I feel we're being horribly deceptive by giving them a nice API, and upon
> review, telling them "don't use that". And it's been ongoing for far too
> long.
If you look at our API documentation it actually says:
Return codes:
o NETDEV_TX_OK everything ok.
o NETDEV_TX_BUSY Cannot transmit packet, try later
Usually a bug, means queue start/stop flow control is broken in
the driver. Note: the driver must NOT put the skb in its DMA ring.
o NETDEV_TX_LOCKED Locking failed, please retry quickly.
Only valid when NETIF_F_LLTX is set.
So I don't feel too bad :)
> > In fact queueing it in the driver is just as bad as return TX_BUSY!
>
> Agreed (modulo the tcpdump issue). And worse, because it's ugly and complex!
The right solution is to stop the queue properly.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
