On 2016年06月17日 08:41, Michael S. Tsirkin wrote:
On Wed, Jun 15, 2016 at 04:38:17PM +0800, Jason Wang wrote:
>We used to queue tx packets in sk_receive_queue, this is less
>efficient since it requires spinlocks to synchronize between producer
>and consumer.
>
>This patch tries to address this by:
>
>- introduce a new mode which will be only enabled with IFF_TX_ARRAY
> set and switch from sk_receive_queue to a fixed size of skb
> array with 256 entries in this mode.
>- introduce a new proto_ops peek_len which was used for peeking the
> skb length.
>- implement a tun version of peek_len for vhost_net to use and convert
> vhost_net to use peek_len if possible.
>
>Pktgen test shows about 18% improvement on guest receiving pps for small
>buffers:
>
>Before: ~1220000pps
>After : ~1440000pps
>
>The reason why I stick to new mode is because:
>
>- though resize is supported by skb array, in multiqueue mode, it's
> not easy to recover from a partial success of queue resizing.
>- tx_queue_len is a user visible feature.
>
>Signed-off-by: Jason Wang<jasowang@xxxxxxxxxx>
I still think it's wrong to add a new feature for this.
For example, why 256 entries?
It's the value of virtqueue size supported by qemu.
Queue len is user visible but it's there precisely for this
reason so people can tune queue for workload.
Right.
Would it help to have ptr_ring_resize that gets an array of
rings and resizes them both to same length?
Yes, that would be very helpful.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
