From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755207AbcFQHWf (ORCPT ); Fri, 17 Jun 2016 03:22:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35004 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754006AbcFQHWe (ORCPT ); Fri, 17 Jun 2016 03:22:34 -0400 Subject: Re: [PATCH net-next V2] tun: introduce tx skb ring To: "Michael S. Tsirkin" References: <1465979897-4445-1-git-send-email-jasowang@redhat.com> <20160617033218-mutt-send-email-mst@redhat.com> Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org, davem@davemloft.net, eric.dumazet@gmail.com, brouer@redhat.com From: Jason Wang Message-ID: <5763A533.8030206@redhat.com> Date: Fri, 17 Jun 2016 15:22:27 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160617033218-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 17 Jun 2016 07:22:33 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > 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.