All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Si-Wei Liu <si-wei.liu@oracle.com>
Cc: "eperezma@redhat.com" <eperezma@redhat.com>,
	Eli Cohen <elic@nvidia.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>
Subject: Re: RFC: control virtqueue size by the vdpa tool
Date: Tue, 30 Aug 2022 18:01:53 -0400	[thread overview]
Message-ID: <20220830180119-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <7460d7c7-5b44-661f-7763-3e7a6a15f138@oracle.com>

On Tue, Aug 30, 2022 at 02:04:55PM -0700, Si-Wei Liu wrote:
> 
> 
> On 8/30/2022 12:58 PM, Michael S. Tsirkin wrote:
> > On Tue, Aug 30, 2022 at 06:22:31AM +0000, Eli Cohen wrote:
> > > 
> > > Hi,
> > > 
> > > 
> > > I have been experimenting with different queue sizes with mlx5_vdpa and noticed
> > > that queue size can affect performance.
> > > 
> > > I would like to propose an extension to vdpa tool to allow to specify the queue
> > > size. Valid values will conform to the max of 32768 specified by the spec.
> > > 
> > > 
> > > “vdpa mgmtdev show” will have another line specifying the valid range for a
> > > management device which could be narrower than the spec allows. This range will
> > > be valid for data queues only (not for control VQ).
> > > 
> > > Another line will display the default queue size
> > > 
> > > 
> > > Example:
> > > 
> > > $ vdpa mgmtdev show
> > > 
> > > auxiliary/mlx5_core.sf.6:
> > > 
> > >    supported_classes net
> > > 
> > >    max_supported_vqs 65
> > > 
> > >    dev_features CSUM GUEST_CSUM MTU HOST_TSO4 HOST_TSO6 STATUS CTRL_VQ CTRL_VLAN
> > > MQ CTRL_MAC_ADDR VERSION_1 ACCESS_PLATFORM
> > > 
> > >    data queue range 256-4096
> > > 
> > >    default queue size 256
> > > 
> > > 
> > > When you create the vdpa device you can specify the requested value:
> > > 
> > > $ vdpa dev add name vdpa-a mgmtdev auxiliary/mlx5_core.sf.6 max_vqp 1 mtu 9000
> > > queue_size 1024
> > > 
> > 
> > A follow up question: isn't it enough to control the size
> > from qemu? do we need ability to control it at the kernel level?
> > 
> Right, I think today we can optionally control the queue size from qemu via
> rx_queue_size or tx_queue_size, but it has a limit of 1024 (btw why it has
> such limit, which is relatively lower in my opinion). I think what was
> missing for QEMU is to query the max number of queue size that the hardware
> can support from the backend.
> 
> -Siwei
> 

okay sure. my question is how important is it to control it in the
kernel?

-- 
MST

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2022-08-30 22:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <DM8PR12MB5400FEB0322A9FD6B3271D45AB799@DM8PR12MB5400.namprd12.prod.outlook.com>
2022-08-30  8:21 ` RFC: control virtqueue size by the vdpa tool Michael S. Tsirkin
2022-08-30 19:58 ` Michael S. Tsirkin
2022-08-30 21:04   ` Si-Wei Liu
2022-08-30 22:01     ` Michael S. Tsirkin [this message]
2022-08-30 23:22       ` Si-Wei Liu
     [not found]         ` <DM8PR12MB54006D58A2ACA88CC786B9A8AB789@DM8PR12MB5400.namprd12.prod.outlook.com>
2022-08-31 22:22           ` Si-Wei Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220830180119-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=elic@nvidia.com \
    --cc=eperezma@redhat.com \
    --cc=si-wei.liu@oracle.com \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.