From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59403) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bV80P-0001RN-EA for qemu-devel@nongnu.org; Wed, 03 Aug 2016 22:03:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bV80L-0005h6-5R for qemu-devel@nongnu.org; Wed, 03 Aug 2016 22:03:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49634) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bV80K-0005gR-TR for qemu-devel@nongnu.org; Wed, 03 Aug 2016 22:03:25 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AEF6BC03070B for ; Thu, 4 Aug 2016 02:03:23 +0000 (UTC) References: <1470266160-17896-1-git-send-email-mst@redhat.com> From: Jason Wang Message-ID: <3baae66c-f04b-6e78-3ce1-3cd599fc913e@redhat.com> Date: Thu, 4 Aug 2016 10:03:19 +0800 MIME-Version: 1.0 In-Reply-To: <1470266160-17896-1-git-send-email-mst@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] virtio-net: allow increasing rx queue size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" , qemu-devel@nongnu.org On 2016=E5=B9=B408=E6=9C=8804=E6=97=A5 07:16, Michael S. Tsirkin wrote: > This allows increasing the rx queue size up to 1024: unlike with tx, > guests don't put in huge S/G lists into RX so the risk of running into > the max 1024 limitation due to some off-by-one seems small. > > It's helpful for users like OVS-DPDK which don't do any buffering on th= e > host - 1K roughly matches 500 entries in tun + 256 in the current rx > queue, which seems to work reasonably well. We could probably make do > with ~750 entries but virtio spec limits us to powers of two. > It might be a good idea to specify an s/g size limit in a future > version. > > It also might be possible to make the queue size smaller down the road,= 64 > seems like the minimal value which will still work (as guests seem to > assume a queue full of 1.5K buffers is enough to process the largest > incoming packet, which is ~64K). No one actually asked for this, and > with virtio 1 guests can reduce ring size without need for host > configuration, so don't bother with this for now. > > Signed-off-by: Michael S. Tsirkin > --- > include/hw/virtio/virtio-net.h | 1 + > hw/net/virtio-net.c | 22 +++++++++++++++++++++- > 2 files changed, 22 insertions(+), 1 deletion(-) > > diff --git a/include/hw/virtio/virtio-net.h b/include/hw/virtio/virtio-= net.h > index 91ed97c..0ced975 100644 > --- a/include/hw/virtio/virtio-net.h > +++ b/include/hw/virtio/virtio-net.h > @@ -35,6 +35,7 @@ typedef struct virtio_net_conf > uint32_t txtimer; > int32_t txburst; > char *tx; > + uint16_t rx_queue_size; > } virtio_net_conf; > =20 > /* Maximum packet size we can receive from tap device: header + 64k *= / > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c > index 01f1351..4e595e9 100644 > --- a/hw/net/virtio-net.c > +++ b/hw/net/virtio-net.c > @@ -1412,7 +1412,8 @@ static void virtio_net_add_queue(VirtIONet *n, in= t index) > { > VirtIODevice *vdev =3D VIRTIO_DEVICE(n); > =20 > - n->vqs[index].rx_vq =3D virtio_add_queue(vdev, 256, virtio_net_han= dle_rx); > + n->vqs[index].rx_vq =3D virtio_add_queue(vdev, n->net_conf.rx_queu= e_size, > + virtio_net_handle_rx); > if (n->net_conf.tx && !strcmp(n->net_conf.tx, "timer")) { > n->vqs[index].tx_vq =3D > virtio_add_queue(vdev, 256, virtio_net_handle_tx_timer); > @@ -1716,10 +1717,28 @@ static void virtio_net_device_realize(DeviceSta= te *dev, Error **errp) > VirtIONet *n =3D VIRTIO_NET(dev); > NetClientState *nc; > int i; > + int min_rx_queue_size; > =20 > virtio_net_set_config_size(n, n->host_features); > virtio_init(vdev, "virtio-net", VIRTIO_ID_NET, n->config_size); > =20 > + /* > + * We set a lower limit on RX queue size to what it always was. > + * Guests that want a smaller ring can always resize it without > + * help from us (using virtio 1 and up). > + */ > + min_rx_queue_size =3D 256; > + if (n->net_conf.rx_queue_size < min_rx_queue_size || > + n->net_conf.rx_queue_size > VIRTQUEUE_MAX_SIZE || > + (n->net_conf.rx_queue_size & (n->net_conf.rx_queue_size - 1)))= { > + error_setg(errp, "Invalid rx_queue_size (=3D %" PRIu16 "), " > + "must be a power of 2 between %d and %d.", > + n->net_conf.rx_queue_size, min_rx_queue_size, > + VIRTQUEUE_MAX_SIZE); > + virtio_cleanup(vdev); > + return; > + } > + > n->max_queues =3D MAX(n->nic_conf.peers.queues, 1); > if (n->max_queues * 2 + 1 > VIRTIO_QUEUE_MAX) { > error_setg(errp, "Invalid number of queues (=3D %" PRIu32 "),= " > @@ -1880,6 +1899,7 @@ static Property virtio_net_properties[] =3D { > TX_TIMER_INTERVAL), > DEFINE_PROP_INT32("x-txburst", VirtIONet, net_conf.txburst, TX_BU= RST), > DEFINE_PROP_STRING("tx", VirtIONet, net_conf.tx), > + DEFINE_PROP_UINT16("rx_queue_size", VirtIONet, net_conf.rx_queue_s= ize, 256), > DEFINE_PROP_END_OF_LIST(), > }; > =20 Reviewed-by: Jason Wang