All of lore.kernel.org
 help / color / mirror / Atom feed
From: Si-Wei Liu <si-wei.liu@oracle.com>
To: Parav Pandit <parav@nvidia.com>, Jason Wang <jasowang@redhat.com>
Cc: Laurent Vivier <lvivier@redhat.com>, mst <mst@redhat.com>,
	virtualization <virtualization@lists.linux-foundation.org>,
	eperezma <eperezma@redhat.com>, Eli Cohen <elic@nvidia.com>
Subject: Re: [PATCH v7 03/14] vdpa: Sync calls set/get config/status with cf_mutex
Date: Tue, 11 Jan 2022 01:15:55 -0800	[thread overview]
Message-ID: <626d9dca-8361-55fd-54d2-f9edd91386a7@oracle.com> (raw)
In-Reply-To: <PH0PR12MB5481784AE87D6D563656A0CFDC519@PH0PR12MB5481.namprd12.prod.outlook.com>



On 1/10/2022 10:26 PM, Parav Pandit wrote:
>
>> From: Jason Wang <jasowang@redhat.com>
>> Sent: Tuesday, January 11, 2022 10:17 AM
>>> I guess in this situation it would be better defer to the future patch
>>> to add such locking or wrapper, although right now there are just two
>>> additional calls taking the lock needlessly when vhost_vdpa_get_status
>>> is called. Maybe it's just me but I'm worried some future patch may
>>> calls the locked API wrapper thousands of times unintendedly, then the
>>> overhead becomes quite obvious.
>> I'm fine to remove this if others agree on this.
>>
>>>>
>>>>> Ok, but IMHO it might be better to get some comment here, otherwise
>>>>> it's quite confusing why the lock needs to be held. vhost_vdpa had
>>>>> done its own serialization in vhost_vdpa_unlocked_ioctl() through
>>>>> vhost_dev`mutex.
>>>>
>>>> Right, but they are done for different levels, one is for vhost_dev
>>>> antoher is for vdpa_dev.
>>> The cf_mutex is introduced to serialize the command line configure
>>> thread (via netlink) and the upstream driver calls from either the
>>> vhost_dev or virtio_dev. I don't see a case, even in future, where the
>>> netlink thread needs to update the virtio status on the fly. Can you
>>> enlighten me why that is at all possible?
> Sorry for my late response.
>
> Netlink reads the whole space while it is not getting modified by vhost/virtio driver side.
> A better to convert cf_mutex to rw_sem that clarifies the code more and still ensure that netlink doesn't read bytes while it is getting modified.
I missed the best timing for asking why it was not a rw_sem in the first 
place, but I don't mind multi-reader's case too much, so it's not a 
hurry for me to make the convert.

-Siwei
> Given that config bytes can be updated anytime and not on each field boundary, it is anyway not atomic.
> It was added where we wanted to modify the fields post creation, but eventually drop that idea.
>
> So yes, cf_mutex removal is fine too.
>
>> After some thought I don't see a case. I can think of NEEDS_RESET but it should
>> come with a config interrupt so we're probably fine without the mutex here.

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

  reply	other threads:[~2022-01-11  9:16 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20220105114646.577224-1-elic@nvidia.com>
     [not found] ` <20220105114646.577224-4-elic@nvidia.com>
2022-01-07  0:33   ` [PATCH v7 03/14] vdpa: Sync calls set/get config/status with cf_mutex Si-Wei Liu
2022-01-07  5:08     ` Jason Wang
2022-01-08  1:23       ` Si-Wei Liu
2022-01-10  6:05         ` Jason Wang
2022-01-11  1:30           ` Si-Wei Liu
2022-01-11  4:46             ` Jason Wang
2022-01-11  6:26               ` Parav Pandit via Virtualization
2022-01-11  9:15                 ` Si-Wei Liu [this message]
2022-01-11  9:23               ` Si-Wei Liu
     [not found]     ` <20220109140956.GA70879@mtl-vdi-166.wap.labs.mlnx>
2022-01-11  1:14       ` Si-Wei Liu
     [not found] ` <20220105114646.577224-6-elic@nvidia.com>
2022-01-07  1:25   ` [PATCH v7 05/14] vdpa: Allow to configure max data virtqueues Si-Wei Liu
     [not found] ` <20220105114646.577224-8-elic@nvidia.com>
2022-01-07  1:27   ` [PATCH v7 07/14] vdpa/mlx5: Support configuring max data virtqueue Si-Wei Liu
2022-01-07  1:50     ` Si-Wei Liu
2022-01-07  5:43       ` Jason Wang
2022-01-08  1:38         ` Si-Wei Liu
     [not found]       ` <20220109141023.GB70879@mtl-vdi-166.wap.labs.mlnx>
2022-01-11  1:00         ` Si-Wei Liu
     [not found]           ` <20220111073416.GB149570@mtl-vdi-166.wap.labs.mlnx>
2022-01-11  8:28             ` Jason Wang
2022-01-11 12:05               ` Michael S. Tsirkin
2022-01-12  2:36                 ` Jason Wang
2022-01-11  8:52             ` Si-Wei Liu
     [not found]               ` <20220111152154.GA165838@mtl-vdi-166.wap.labs.mlnx>
2022-01-11 15:31                 ` Michael S. Tsirkin
2022-01-11 22:21                 ` Si-Wei Liu
2022-01-07 18:01     ` Nathan Chancellor
2022-01-08  1:43       ` Si-Wei Liu
2022-01-08  1:43         ` Si-Wei Liu
2022-01-10  6:53         ` Michael S. Tsirkin
2022-01-10  6:53           ` Michael S. Tsirkin
2022-01-10  6:58           ` Eli Cohen
     [not found] ` <20220105114646.577224-11-elic@nvidia.com>
2022-01-07  2:12   ` [PATCH v7 10/14] vdpa: Support reporting max device capabilities Si-Wei Liu
     [not found] ` <20220105114646.577224-12-elic@nvidia.com>
2022-01-07  2:12   ` [PATCH v7 11/14] vdpa/mlx5: Report " Si-Wei Liu
2022-01-07  5:49     ` Jason Wang
     [not found] ` <20220105114646.577224-5-elic@nvidia.com>
2022-01-07  5:14   ` [PATCH v7 04/14] vdpa: Read device configuration only if FEATURES_OK Jason Wang
     [not found] ` <20220105114646.577224-9-elic@nvidia.com>
2022-01-07  5:46   ` [PATCH v7 08/14] vdpa: Add support for returning device configuration information Jason Wang
     [not found] ` <20220105114646.577224-13-elic@nvidia.com>
2022-01-07  5:50   ` [PATCH v7 12/14] vdpa/vdpa_sim: Configure max supported virtqueues Jason Wang
     [not found] ` <20220105114646.577224-14-elic@nvidia.com>
2022-01-07  5:51   ` [PATCH v7 13/14] vdpa: Use BIT_ULL for bit operations Jason Wang
     [not found] ` <20220105114646.577224-15-elic@nvidia.com>
2022-01-07  5:51   ` [PATCH v7 14/14] vdpa/vdpa_sim_net: Report max device capabilities Jason Wang
2022-01-10  7:04 ` [PATCH v7 00/14] Allow for configuring max number of virtqueue pairs Michael S. Tsirkin
2022-01-10  7:09   ` Jason Wang
2022-01-11  1:59   ` Si-Wei Liu
     [not found]   ` <20220110074958.GA105688@mtl-vdi-166.wap.labs.mlnx>
2022-01-11  2:02     ` 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=626d9dca-8361-55fd-54d2-f9edd91386a7@oracle.com \
    --to=si-wei.liu@oracle.com \
    --cc=elic@nvidia.com \
    --cc=eperezma@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=mst@redhat.com \
    --cc=parav@nvidia.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.