All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Garzarella <sgarzare@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: virtualization@lists.linux-foundation.org,
	Stefan Hajnoczi <stefanha@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Oren Duer <oren@nvidia.com>, Laurent Vivier <lvivier@redhat.com>,
	linux-kernel@vger.kernel.org, Max Gurtovoy <mgurtovoy@nvidia.com>,
	Shahaf Shuler <shahafs@nvidia.com>, Eli Cohen <elic@nvidia.com>
Subject: Re: [PATCH v3 05/19] vdpa_sim: remove the limit of IOTLB entries
Date: Wed, 9 Dec 2020 11:58:29 +0100	[thread overview]
Message-ID: <20201209105829.6l6ie7xqp2eycds6@steredhat> (raw)
In-Reply-To: <d7b00b70-9785-db1f-1e42-7b9172b7ad90@redhat.com>

On Mon, Dec 07, 2020 at 12:00:07PM +0800, Jason Wang wrote:
>
>On 2020/12/4 上午1:04, Stefano Garzarella wrote:
>>The simulated devices can support multiple queues, so this limit
>>should be defined according to the number of queues supported by
>>the device.
>>
>>Since we are in a simulator, let's simply remove that limit.
>>
>>Suggested-by: Jason Wang <jasowang@redhat.com>
>>Acked-by: Jason Wang <jasowang@redhat.com>
>>Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
>
>
>Rethink about this, since simulator can be used by VM, so the 
>allocation is actually guest trigger-able when vIOMMU is enabled.
>
>This means we need a limit somehow, (e.g I remember swiotlb is about 
>64MB by default). Or having a module parameter for this.
>
>Btw, have you met any issue when using 2048, I guess it can happen 
>when we run several processes in parallel?
>

No, I didn't try with the limit.
This came from the reviews to Max's patches.

Anyway I can add a module parameter to control that limit, do you think 
is better to set a limit per queue (the parameter per number of queues), 
or just a value for the entire device?

Thanks,
Stefano


WARNING: multiple messages have this Message-ID (diff)
From: Stefano Garzarella <sgarzare@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: Laurent Vivier <lvivier@redhat.com>,
	Max Gurtovoy <mgurtovoy@nvidia.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Shahaf Shuler <shahafs@nvidia.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Eli Cohen <elic@nvidia.com>, Oren Duer <oren@nvidia.com>
Subject: Re: [PATCH v3 05/19] vdpa_sim: remove the limit of IOTLB entries
Date: Wed, 9 Dec 2020 11:58:29 +0100	[thread overview]
Message-ID: <20201209105829.6l6ie7xqp2eycds6@steredhat> (raw)
In-Reply-To: <d7b00b70-9785-db1f-1e42-7b9172b7ad90@redhat.com>

On Mon, Dec 07, 2020 at 12:00:07PM +0800, Jason Wang wrote:
>
>On 2020/12/4 上午1:04, Stefano Garzarella wrote:
>>The simulated devices can support multiple queues, so this limit
>>should be defined according to the number of queues supported by
>>the device.
>>
>>Since we are in a simulator, let's simply remove that limit.
>>
>>Suggested-by: Jason Wang <jasowang@redhat.com>
>>Acked-by: Jason Wang <jasowang@redhat.com>
>>Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
>
>
>Rethink about this, since simulator can be used by VM, so the 
>allocation is actually guest trigger-able when vIOMMU is enabled.
>
>This means we need a limit somehow, (e.g I remember swiotlb is about 
>64MB by default). Or having a module parameter for this.
>
>Btw, have you met any issue when using 2048, I guess it can happen 
>when we run several processes in parallel?
>

No, I didn't try with the limit.
This came from the reviews to Max's patches.

Anyway I can add a module parameter to control that limit, do you think 
is better to set a limit per queue (the parameter per number of queues), 
or just a value for the entire device?

Thanks,
Stefano

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

  reply	other threads:[~2020-12-09 11:00 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-03 17:04 [PATCH v3 00/19] vdpa: generalize vdpa simulator Stefano Garzarella
2020-12-03 17:04 ` Stefano Garzarella
2020-12-03 17:04 ` [PATCH v3 01/19] vdpa: remove unnecessary 'default n' in Kconfig entries Stefano Garzarella
2020-12-03 17:04   ` Stefano Garzarella
2020-12-03 17:04 ` [PATCH v3 02/19] vdpa_sim: remove unnecessary headers inclusion Stefano Garzarella
2020-12-03 17:04   ` Stefano Garzarella
2020-12-03 17:37   ` Randy Dunlap
2020-12-03 17:37     ` Randy Dunlap
2020-12-04  7:57     ` Stefano Garzarella
2020-12-04  7:57       ` Stefano Garzarella
2020-12-03 17:04 ` [PATCH v3 03/19] vdpa_sim: remove hard-coded virtq count Stefano Garzarella
2020-12-03 17:04   ` Stefano Garzarella
2020-12-03 17:04 ` [PATCH v3 04/19] vhost/iotlb: add VHOST_IOTLB_UNLIMITED macro Stefano Garzarella
2020-12-03 17:04   ` Stefano Garzarella
2020-12-07  3:55   ` Jason Wang
2020-12-07  3:55     ` Jason Wang
2020-12-03 17:04 ` [PATCH v3 05/19] vdpa_sim: remove the limit of IOTLB entries Stefano Garzarella
2020-12-03 17:04   ` Stefano Garzarella
2020-12-07  4:00   ` Jason Wang
2020-12-07  4:00     ` Jason Wang
2020-12-09 10:58     ` Stefano Garzarella [this message]
2020-12-09 10:58       ` Stefano Garzarella
2020-12-10  4:03       ` Jason Wang
2020-12-10  4:03         ` Jason Wang
2020-12-03 17:04 ` [PATCH v3 06/19] vdpa_sim: rename vdpasim_config_ops variables Stefano Garzarella
2020-12-03 17:04   ` Stefano Garzarella
2020-12-03 17:04 ` [PATCH v3 07/19] vdpa_sim: add struct vdpasim_dev_attr for device attributes Stefano Garzarella
2020-12-03 17:04   ` Stefano Garzarella
2020-12-03 17:05 ` [PATCH v3 08/19] vdpa_sim: add device id field in vdpasim_dev_attr Stefano Garzarella
2020-12-03 17:05   ` Stefano Garzarella
2020-12-03 17:05 ` [PATCH v3 09/19] vdpa_sim: add supported_features " Stefano Garzarella
2020-12-03 17:05   ` Stefano Garzarella
2020-12-03 17:05 ` [PATCH v3 10/19] vdpa_sim: add work_fn " Stefano Garzarella
2020-12-03 17:05   ` Stefano Garzarella
2020-12-03 17:05 ` [PATCH v3 11/19] vdpa_sim: store parsed MAC address in a buffer Stefano Garzarella
2020-12-03 17:05   ` Stefano Garzarella
2020-12-03 17:05 ` [PATCH v3 12/19] vdpa_sim: make 'config' generic and usable for any device type Stefano Garzarella
2020-12-03 17:05   ` Stefano Garzarella
2020-12-07  5:22   ` Jason Wang
2020-12-07  5:22     ` Jason Wang
2020-12-03 17:05 ` [PATCH v3 13/19] vdpa_sim: add get_config callback in vdpasim_dev_attr Stefano Garzarella
2020-12-03 17:05   ` Stefano Garzarella
2020-12-07  5:29   ` Jason Wang
2020-12-07  5:29     ` Jason Wang
2020-12-09 11:07     ` Stefano Garzarella
2020-12-09 11:07       ` Stefano Garzarella
2020-12-15 11:43       ` Stefano Garzarella
2020-12-15 11:43         ` Stefano Garzarella
2020-12-03 17:05 ` [PATCH v3 14/19] vdpa_sim: add set_config " Stefano Garzarella
2020-12-03 17:05   ` Stefano Garzarella
2020-12-07  5:30   ` Jason Wang
2020-12-07  5:30     ` Jason Wang
2020-12-03 17:05 ` [PATCH v3 15/19] vdpa_sim: set vringh notify callback Stefano Garzarella
2020-12-03 17:05   ` Stefano Garzarella
2020-12-07  5:30   ` Jason Wang
2020-12-07  5:30     ` Jason Wang
2020-12-03 17:05 ` [PATCH v3 16/19] vdpa_sim: use kvmalloc to allocate vdpasim->buffer Stefano Garzarella
2020-12-03 17:05   ` Stefano Garzarella
2020-12-03 17:05 ` [PATCH v3 17/19] vdpa_sim: make vdpasim->buffer size configurable Stefano Garzarella
2020-12-03 17:05   ` Stefano Garzarella
2020-12-03 17:05 ` [PATCH v3 18/19] vdpa_sim: split vdpasim_virtqueue's iov field in out_iov and in_iov Stefano Garzarella
2020-12-03 17:05   ` Stefano Garzarella
2020-12-03 17:05 ` [PATCH v3 19/19] vdpa: split vdpasim to core and net modules Stefano Garzarella
2020-12-03 17:05   ` Stefano Garzarella
2020-12-03 17:25   ` Randy Dunlap
2020-12-03 17:25     ` Randy Dunlap
2020-12-04  7:48     ` Stefano Garzarella
2020-12-04  7:48       ` Stefano Garzarella
2020-12-07  5:33   ` Jason Wang
2020-12-07  5:33     ` Jason Wang

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=20201209105829.6l6ie7xqp2eycds6@steredhat \
    --to=sgarzare@redhat.com \
    --cc=elic@nvidia.com \
    --cc=jasowang@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lvivier@redhat.com \
    --cc=mgurtovoy@nvidia.com \
    --cc=mst@redhat.com \
    --cc=oren@nvidia.com \
    --cc=shahafs@nvidia.com \
    --cc=stefanha@redhat.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.