All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kurz <groug@kaod.org>
To: linux-kernel@vger.kernel.org
Cc: v9fs-developer@lists.sourceforge.net,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [PATCH 0/2] 9p/trans_virtio: handle request cancellation
Date: Mon, 8 Jan 2018 10:18:09 +0100	[thread overview]
Message-ID: <20180108101809.664d1822@bahia.lan> (raw)
In-Reply-To: <151379198727.15509.2771563206512953068.stgit@bahia>

Hi Michael,

I wish you a happy new year, and I really need some feedback on this
series because it holds down some patches on the QEMU side.

Thanks,

--
Greg

On Wed, 20 Dec 2017 18:46:27 +0100
Greg Kurz <groug@kaod.org> wrote:

> The 9p protocol mostly relies on a request/reply dialog between the
> client and the server. A notable exception to this rule is request
> cancellation (ie, flush in 9p wording): when the client requests an
> in-flight request to be flushed, the server should only reply to the
> flush request and not to the flushed in-flight request (otherwise it
> considers the in-flight request to have completed just like it has
> never been flushed).
> 
> It is up to the client to inform the transport that the in-flight request
> has been flushed and won't receive a reply. This is achieved with the
> 'cancelled' operation of the struct p9_trans_module.
> 
> This operation isn't currently implemented with the virtio transport.
> As a consequence, flushed requests leave buffers in the used list
> forever and the virtqueue ends up in being able to process only one
> request at a time.
> 
> This issue never popped up because the 9p server in QEMU had a bug
> and would always reply to flushed requests. But this will be fixed
> soon, so it is time to implement the 'cancelled' operation in the
> 9p virtio transport.
> 
> --
> Greg
> 
> ---
> 
> Greg Kurz (2):
>       virtio: allow to detach a buffer from the virtqueue
>       9p/trans_virtio: implement cancelled callback
> 
> 
>  drivers/virtio/virtio_ring.c |   28 ++++++++++++++++++++++++++++
>  include/linux/virtio.h       |    1 +
>  net/9p/trans_virtio.c        |   18 ++++++++++++++++++
>  3 files changed, 47 insertions(+)
> 
> 

      parent reply	other threads:[~2018-01-08 15:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-20 17:46 [PATCH 0/2] 9p/trans_virtio: handle request cancellation Greg Kurz
2017-12-20 17:46 ` [PATCH 1/2] virtio: allow to detach a buffer from the virtqueue Greg Kurz
2018-01-19 19:49   ` Michael S. Tsirkin
2018-01-20  9:20     ` Greg Kurz
2017-12-20 17:46 ` [PATCH 2/2] 9p/trans_virtio: implement cancelled callback Greg Kurz
2018-01-08  9:18 ` Greg Kurz [this message]

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=20180108101809.664d1822@bahia.lan \
    --to=groug@kaod.org \
    --cc=jasowang@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=v9fs-developer@lists.sourceforge.net \
    --cc=viro@ZenIV.linux.org.uk \
    /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.