Thanks Herbert. I thought lesser processing is required for those skbs queued at the driver (avoid qdisc_restart, and repeated calls to dequeue_skb where skb from the cached 'gso_skb' is checked if send'able and put back till the queue is re-enabled) and hence some gains is possible. So far, my testing of queueing in the driver shows good results for some test cases and bad results for others, hence my question on the topic as I am not able to figure out why some cases test worse. - KK Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote on 06/22/2009 01:04:17 PM: > Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> > 06/22/2009 01:04 PM > > To > > Krishna Kumar2/India/IBM@IBMIN > > cc > > David Miller <davem@xxxxxxxxxxxxx>, Matt Carlson <mcarlson@xxxxxxxxxxxx>, > netdev@xxxxxxxxxxxxxxx, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, > virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx > > Subject > > Re: [PATCH 2/4] virtio_net: return NETDEV_TX_BUSY instead of queueing an extra skb. > > On Mon, Jun 22, 2009 at 11:16:03AM +0530, Krishna Kumar2 wrote: > > > > I was curious about "queueing it in the driver" part: why is this bad? Do > > you > > anticipate any performance problems, or does it break QoS, or something > > else I > > have missed? > > Queueing it in the driver is bad because it is no different than > queueing it at the upper layer, which is what will happen when > you return TX_BUSY. > > Because we've ripped out the qdisc requeueing logic (which is > horribly complex and only existed because of TX_BUSY), it means > that higher priority packets cannot preempt a packet that is queued > in this way. > > 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
