Messages in this thread | | | Subject | Re: [PATCH net-next V2] tun: introduce tx skb ring | From | Jason Wang <> | Date | Fri, 17 Jun 2016 15:22:27 +0800 |
| |
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@redhat.com> > 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.
| |