All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: Lege Wang <lege.wang@jaguarmicro.com>,
	"virtio-comment@lists.linux.dev" <virtio-comment@lists.linux.dev>,
	"vattunuru@marvell.com" <vattunuru@marvell.com>,
	"ndabilpuram@marvell.com" <ndabilpuram@marvell.com>,
	"parav@nvidia.com" <parav@nvidia.com>,
	Leo Liu <leo.liu@jaguarmicro.com>,
	Angus Chen <angus.chen@jaguarmicro.com>
Subject: Re: [PATCH] VIRTIO_F_USED_EVENT_AUTO_DISABLE: add new used buffer notification suppression mechanism
Date: Thu, 4 Jul 2024 04:30:57 -0400	[thread overview]
Message-ID: <20240704042308-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CACGkMEtgAD4mPLpf4fLAsVzzUGvbx1+XTxyGLtMSOJzHp-JtGA@mail.gmail.com>

On Thu, Jul 04, 2024 at 01:37:44PM +0800, Jason Wang wrote:
> On Wed, Jul 3, 2024 at 5:09 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Wed, Jul 03, 2024 at 04:47:41PM +0800, Jason Wang wrote:
> > > On Wed, Jul 3, 2024 at 4:36 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > >
> > > > On Wed, Jul 03, 2024 at 03:59:11PM +0800, Jason Wang wrote:
> > > > > On Wed, Jul 3, 2024 at 3:37 PM Lege Wang <lege.wang@jaguarmicro.com> wrote:
> > > > > >
> > > > > > hi,
> > > > > >
> > > > > > > > >
> > > > > > > > > 1) With the event index, as long as the used index doesn't pass used
> > > > > > > > > events you don't need to fetch even index every time
> > > > > > > > Yeah, I agree VIRTIO_F_EVENT_IDX could help here, but I think it's a relatively
> > > > > > > > crude mechanism, I have two questions below:
> > > > > > > >   1. Used event notification suppression structure is still located in
> > > > > > > >   host memory(in dpu case), I'm not sure whether used_event would
> > > > > > > >   be allowed to update in the running of one virtio device,
> > > > > > >
> > > > > > > What did you mean by "update" here?
> > > > > > I mean "modify".
> > > > > >
> > > > > > >
> > > > > > > >   If it's allowed,
> > > > > > > >   seems devices still need to fetch newest used_event info timely.
> > > > > > >
> > > > > > > It depends on how you define "timely", I mean unless the used event is
> > > > > > > not crossed, you don't need to fetch it from the main memory?
> > > > > > Yes, I got your point here.
> > > > > > >
> > > > > > > But basically, I meant putting used_event in a cap/register other than
> > > > > > > inventing something completely new.
> > > > > > Sorry, I don't get your point here. What does " cap/register " mean, used_event
> > > > > > Is located in main memory, right?
> > > > >
> > > > > I meant something like this.
> > > > >
> > > > > Introduce a capability to allow the driver to duplicate used_event in
> > > > > the register. And say when the feature is negotiated, the driver MUST
> > > > > update both used_event in the memory and the register.
> > > > >
> > > > > Not saying it can work, but we need to know why it can't work like this.
> > > >
> > > > Well I feel if you are proposing a mechanism it's up to you to
> > > > explain how it works without races.
> > >
> > > I agree, that's why I'm saying "Not saying it can work". But what I
> > > meant is really to find a way to reuse the event index instead of
> > > introducing something completely new.
> > >
> > > > The current notification suppression works because the read
> > > > of the notification by the device flushes out used buffer writes by
> > > > the device.
> > >
> > > You meant read after write is ordered by PCI?
> >
> > pci read responses do not bypass writes, yes.
> >
> > > > If you move it to a separate domain (such as the pci bar of the device)
> > > > this no longer holds.
> > >
> > > Would this be implementation specific details or could it be done by PCI?
> >
> > what do you want done by PCI? Generally if things are in one place
> > they are easier to synchronize, if you spread them around you
> > need to synchronize them.
> 
> I meant the synchronization looks more like an implementation detail
> in the device.  Synchronizing with device internal logic should be
> simpler than with PCI/memory.
> 
> For example, did you mean the synchronization between driver write to
> register (PCI write) and device read from that (internal logic). If
> needed, an implementation needs to serialize those two, then we are
> probably fine.
> 
> Thanks

I mean synchronization between driver write to device and
device write to memory.



What I see working, is something I proposed a long time ago:
notify devices about changes to the notification suppression
area. This adds more overhead
driver notify -> device read -> memory read response
but I think it works.

What I couldn't decide, is whether it's worth sending a notification
when switching from enable to disable with packed ring.



-- 
MST


  reply	other threads:[~2024-07-04  8:31 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-01  3:44 [PATCH] VIRTIO_F_USED_EVENT_AUTO_DISABLE: add new used buffer notification suppression mechanism Xiaoguang Wang
2024-07-01  8:24 ` Lege Wang
2024-07-02  1:15 ` Xuan Zhuo
2024-07-02  5:30   ` [EXTERNAL] " Vamsi Krishna Attunuru
2024-07-02  7:40 ` Jason Wang
2024-07-03  4:32   ` Lege Wang
2024-07-03  5:10     ` Jason Wang
2024-07-03  7:37       ` Lege Wang
2024-07-03  7:59         ` Jason Wang
2024-07-03  8:36           ` Michael S. Tsirkin
2024-07-03  8:47             ` Jason Wang
2024-07-03  9:08               ` Michael S. Tsirkin
2024-07-04  5:37                 ` Jason Wang
2024-07-04  8:30                   ` Michael S. Tsirkin [this message]
2024-07-05  5:48                     ` Jason Wang
2024-07-05  7:48                       ` Michael S. Tsirkin
2024-07-08  1:39                         ` Jason Wang
2024-07-02 12:00 ` Michael S. Tsirkin
2024-07-03  6:52   ` Lege Wang
2024-07-03  8:28     ` Michael S. Tsirkin
2024-07-03 12:14       ` Lege Wang
2024-07-03 12:34         ` Michael S. Tsirkin
2024-07-04  2:27           ` Lege Wang
2024-07-05  7:57             ` Michael S. Tsirkin
2024-07-05 11:12               ` Lege Wang
2024-07-05 11:29                 ` Michael S. Tsirkin
2024-07-05  3:35 ` Lege Wang
2024-07-05  4:42   ` Parav Pandit
2024-07-05  7:52     ` Michael S. Tsirkin
2024-07-08  2:37       ` Parav Pandit
2024-07-05  8:25     ` Michael S. Tsirkin
2024-07-08  2:33       ` Parav Pandit
2024-07-05  8:00   ` Michael S. Tsirkin
2024-11-05 16:23     ` [EXTERNAL] " Vamsi Krishna Attunuru
2024-11-06  4:33       ` Jason Wang
2024-11-06 11:11         ` Vamsi Krishna Attunuru
2024-11-06  7:40       ` Michael S. Tsirkin

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=20240704042308-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=angus.chen@jaguarmicro.com \
    --cc=jasowang@redhat.com \
    --cc=lege.wang@jaguarmicro.com \
    --cc=leo.liu@jaguarmicro.com \
    --cc=ndabilpuram@marvell.com \
    --cc=parav@nvidia.com \
    --cc=vattunuru@marvell.com \
    --cc=virtio-comment@lists.linux.dev \
    /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.