From: Vivek Goyal <vgoyal@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: virtio-fs@redhat.com, miklos@szeredi.hu, qemu-devel@nongnu.org,
dgilbert@redhat.com
Subject: Re: [PATCH 2/4] virtiofd: Create a notification queue
Date: Fri, 22 Nov 2019 09:47:21 -0500 [thread overview]
Message-ID: <20191122144721.GD8636@redhat.com> (raw)
In-Reply-To: <20191122101903.GC464656@stefanha-x1.localdomain>
On Fri, Nov 22, 2019 at 10:19:03AM +0000, Stefan Hajnoczi wrote:
> On Fri, Nov 15, 2019 at 03:55:41PM -0500, Vivek Goyal wrote:
> > /* Callback from libvhost-user */
> > static void fv_set_features(VuDev *dev, uint64_t features)
> > {
> > + struct fv_VuDev *vud = container_of(dev, struct fv_VuDev, dev);
> > + struct fuse_session *se = vud->se;
> > +
> > + if ((1 << VIRTIO_FS_F_NOTIFICATION) & features) {
>
> For consistency 1ull should be used. That way the reader does not have
> to check the bit position to verify that the bitmap isn't truncated at
> 32 bits.
Ok, will do.
>
> > + vud->notify_enabled = true;
> > + se->notify_enabled = true;
>
> Only one copy of this field is needed. vud has a pointer to se.
I need to access ->notify_enabled in passthrough_ll.c to determine if
notification queue is enabled or not. That determines if async locks are
supported or not. And based on that either -EOPNOTSUPP is returned or
a response to wait is returned.
I did not see passthrough_ll.c accessing vud. I did see it having access
to session object though. So I created a copy there.
But I am open to suggestions on what's the best way to access this
information in passthrough_ll.c
>
> > + }
> > }
> >
> > /*
> > @@ -662,6 +671,65 @@ static void fv_queue_worker(gpointer data, gpointer user_data)
> > free(req);
> > }
> >
> > +static void *fv_queue_notify_thread(void *opaque)
> > +{
> > + struct fv_QueueInfo *qi = opaque;
> > +
> > + fuse_log(FUSE_LOG_INFO, "%s: Start for queue %d kick_fd %d\n", __func__,
> > + qi->qidx, qi->kick_fd);
> > +
> > + while (1) {
> > + struct pollfd pf[2];
> > +
> > + pf[0].fd = qi->kick_fd;
> > + pf[0].events = POLLIN;
> > + pf[0].revents = 0;
> > + pf[1].fd = qi->kill_fd;
> > + pf[1].events = POLLIN;
> > + pf[1].revents = 0;
> > +
> > + fuse_log(FUSE_LOG_DEBUG, "%s: Waiting for Queue %d event\n", __func__,
> > + qi->qidx);
> > + int poll_res = ppoll(pf, 2, NULL, NULL);
> > +
> > + if (poll_res == -1) {
> > + if (errno == EINTR) {
> > + fuse_log(FUSE_LOG_INFO, "%s: ppoll interrupted, going around\n",
> > + __func__);
> > + continue;
> > + }
> > + fuse_log(FUSE_LOG_ERR, "fv_queue_thread ppoll: %m\n");
> > + break;
> > + }
> > + assert(poll_res >= 1);
> > + if (pf[0].revents & (POLLERR | POLLHUP | POLLNVAL)) {
> > + fuse_log(FUSE_LOG_ERR, "%s: Unexpected poll revents %x Queue %d\n",
> > + __func__, pf[0].revents, qi->qidx);
> > + break;
> > + }
> > + if (pf[1].revents & (POLLERR | POLLHUP | POLLNVAL)) {
> > + fuse_log(FUSE_LOG_ERR, "%s: Unexpected poll revents %x Queue %d"
> > + "killfd\n", __func__, pf[1].revents, qi->qidx);
> > + break;
> > + }
> > + if (pf[1].revents) {
> > + fuse_log(FUSE_LOG_INFO, "%s: kill event on queue %d - quitting\n",
> > + __func__, qi->qidx);
> > + break;
> > + }
> > + assert(pf[0].revents & POLLIN);
> > + fuse_log(FUSE_LOG_DEBUG, "%s: Got queue event on Queue %d\n", __func__,
> > + qi->qidx);
> > +
> > + eventfd_t evalue;
> > + if (eventfd_read(qi->kick_fd, &evalue)) {
> > + fuse_log(FUSE_LOG_ERR, "Eventfd_read for queue: %m\n");
> > + break;
> > + }
> > + }
> > + return NULL;
> > +}
>
> It's difficult to review function without any actual functionality using
> the virtqueue. I'm not sure a thread is even needed since the device
> only needs to get a buffer when it has a notification for the driver.
> I'll have to wait for the following patches to see what happens here...
This might very well be redundant. I am not sure. Can get rid of
this thread if not needed at all. So we don't need to monitor even
kill_fd and take any special action?
>
> > @@ -378,12 +382,23 @@ static void vuf_set_status(VirtIODevice *vdev, uint8_t status)
> > }
> > }
> >
> > -static uint64_t vuf_get_features(VirtIODevice *vdev,
> > - uint64_t requested_features,
> > - Error **errp)
> > +static uint64_t vuf_get_features(VirtIODevice *vdev, uint64_t features,
> > + Error **errp)
> > {
> > - /* No feature bits used yet */
> > - return requested_features;
> > + VHostUserFS *fs = VHOST_USER_FS(vdev);
> > +
> > + virtio_add_feature(&features, VIRTIO_FS_F_NOTIFICATION);
> > +
> > + return vhost_get_features(&fs->vhost_dev, user_feature_bits, features);
> > +}
> > +
> > +static void vuf_set_features(VirtIODevice *vdev, uint64_t features)
> > +{
> > + VHostUserFS *fs = VHOST_USER_FS(vdev);
> > +
> > + if (virtio_has_feature(features, VIRTIO_FS_F_NOTIFICATION)) {
> > + fs->notify_enabled = true;
>
> This field is unused, please remove it.
vuf_get_config() uses it.
Thanks
Vivek
next prev parent reply other threads:[~2019-11-22 14:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-15 20:55 [PATCH 0/4] [RFC] virtiofsd, vhost-user-fs: Add support for notification queue Vivek Goyal
2019-11-15 20:55 ` [PATCH 1/4] virtiofsd: Release file locks using F_UNLCK Vivek Goyal
2019-11-22 10:07 ` Stefan Hajnoczi
2019-11-22 13:45 ` Vivek Goyal
2019-11-15 20:55 ` [PATCH 2/4] virtiofd: Create a notification queue Vivek Goyal
2019-11-22 10:19 ` Stefan Hajnoczi
2019-11-22 14:47 ` Vivek Goyal [this message]
2019-11-22 17:29 ` Dr. David Alan Gilbert
2019-11-15 20:55 ` [PATCH 3/4] virtiofsd: Specify size of notification buffer using config space Vivek Goyal
2019-11-22 10:33 ` Stefan Hajnoczi
2019-11-25 14:57 ` Vivek Goyal
2019-11-15 20:55 ` [PATCH 4/4] virtiofsd: Implement blocking posix locks Vivek Goyal
2019-11-22 10:53 ` Stefan Hajnoczi
2019-11-25 15:38 ` [Virtio-fs] " Vivek Goyal
2019-11-22 17:47 ` Dr. David Alan Gilbert
2019-11-25 15:44 ` [Virtio-fs] " Vivek Goyal
2019-11-26 13:02 ` Dr. David Alan Gilbert
2019-11-27 19:08 ` Vivek Goyal
2019-12-09 11:06 ` Dr. David Alan Gilbert
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=20191122144721.GD8636@redhat.com \
--to=vgoyal@redhat.com \
--cc=dgilbert@redhat.com \
--cc=miklos@szeredi.hu \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=virtio-fs@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).