Thread (1 message) 1 message, 1 author, 2016-06-17

Re: [PATCH net-next V2] tun: introduce tx skb ring

From: Jason Wang <hidden>
Date: 2016-06-17 07:22:27


On 2016年06月17日 08:41, Michael S. Tsirkin wrote:
On Wed, Jun 15, 2016 at 04:38:17PM +0800, Jason Wang wrote:
quoted
quoted
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<redacted>
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.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help