All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: zhenwei pi <pizhenwei@bytedance.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	parav@nvidia.com, virtio-dev@lists.oasis-open.org,
	"virtio-comment@lists.oasis-open.org"
	<virtio-comment@lists.oasis-open.org>,
	"helei.sig11@bytedance.com" <helei.sig11@bytedance.com>,
	houp@yusur.tech
Subject: Re: [virtio-comment] [PROPOSAL] Virtio Over Fabrics(TCP/RDMA)
Date: Tue, 25 Apr 2023 10:09:42 -0400	[thread overview]
Message-ID: <20230425140942.GB697094@fedora> (raw)
In-Reply-To: <CACGkMEvh+G2Tm=WDTOK3K2GO8c2dQ4y=UiKAk_kvsid2MGzbGg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]

On Mon, Apr 24, 2023 at 11:40:02AM +0800, Jason Wang wrote:
> On Sun, Apr 23, 2023 at 7:31 PM zhenwei pi <pizhenwei@bytedance.com> wrote:
> > I develop an kernel initiator(unstable, WIP version, currently TCP/RDMA
> > supported):
> > https://github.com/pizhenwei/linux/tree/virtio-of-github
> 
> A quick glance at the code told me it's a mediation layer that convert
> descriptors in the vring to the fabric specific packet. This is the
> vDPA way.
>
> If we agree virtio of fabic is useful, we need invent facilities to
> allow building packet directly without bothering the virtqueue (the
> API is layout independent anyhow).

I agree. vrings makes sense for RDMA, but I think virtio_fabrics.c
should not be dependent on vrings.

Linux struct virtqueue is independent of vrings but the implementation
currently lives in virtio_ring.c because there has never been a
non-vring transport before.

It would be nice to implement virtqueue_add_sgs() specifically for
virtio_tcp.c without the use of vrings. Is a new struct
virtqueue_ops needed with with .add_sgs() and related callbacks?

Luckily the <linux/virtio.h> API already supports this abstraction and
changes to existing device drivers should be unnecessary or minimal.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: zhenwei pi <pizhenwei@bytedance.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	parav@nvidia.com, virtio-dev@lists.oasis-open.org,
	"virtio-comment@lists.oasis-open.org"
	<virtio-comment@lists.oasis-open.org>,
	"helei.sig11@bytedance.com" <helei.sig11@bytedance.com>,
	houp@yusur.tech
Subject: [virtio-dev] Re: [virtio-comment] [PROPOSAL] Virtio Over Fabrics(TCP/RDMA)
Date: Tue, 25 Apr 2023 10:09:42 -0400	[thread overview]
Message-ID: <20230425140942.GB697094@fedora> (raw)
In-Reply-To: <CACGkMEvh+G2Tm=WDTOK3K2GO8c2dQ4y=UiKAk_kvsid2MGzbGg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]

On Mon, Apr 24, 2023 at 11:40:02AM +0800, Jason Wang wrote:
> On Sun, Apr 23, 2023 at 7:31 PM zhenwei pi <pizhenwei@bytedance.com> wrote:
> > I develop an kernel initiator(unstable, WIP version, currently TCP/RDMA
> > supported):
> > https://github.com/pizhenwei/linux/tree/virtio-of-github
> 
> A quick glance at the code told me it's a mediation layer that convert
> descriptors in the vring to the fabric specific packet. This is the
> vDPA way.
>
> If we agree virtio of fabic is useful, we need invent facilities to
> allow building packet directly without bothering the virtqueue (the
> API is layout independent anyhow).

I agree. vrings makes sense for RDMA, but I think virtio_fabrics.c
should not be dependent on vrings.

Linux struct virtqueue is independent of vrings but the implementation
currently lives in virtio_ring.c because there has never been a
non-vring transport before.

It would be nice to implement virtqueue_add_sgs() specifically for
virtio_tcp.c without the use of vrings. Is a new struct
virtqueue_ops needed with with .add_sgs() and related callbacks?

Luckily the <linux/virtio.h> API already supports this abstraction and
changes to existing device drivers should be unnecessary or minimal.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2023-04-25 14:10 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-23 11:29 [virtio-comment] [PROPOSAL] Virtio Over Fabrics(TCP/RDMA) zhenwei pi
2023-04-24  3:40 ` Jason Wang
2023-04-24  3:40   ` [virtio-dev] " Jason Wang
2023-04-24 13:38   ` zhenwei pi
2023-04-25  5:03     ` Parav Pandit
2023-04-25  5:03       ` [virtio-dev] " Parav Pandit
2023-04-25  6:31       ` Jason Wang
2023-04-25  6:31         ` [virtio-dev] " Jason Wang
2023-04-25 13:27         ` Parav Pandit
2023-04-25 13:27           ` [virtio-dev] " Parav Pandit
2023-04-25  7:02       ` zhenwei pi
2023-04-27  8:20       ` zhenwei pi
2023-04-27  8:20         ` [virtio-dev] " zhenwei pi
2023-04-27 20:31         ` Parav Pandit
2023-04-27 20:31           ` [virtio-dev] " Parav Pandit
2023-04-28  7:53           ` zhenwei pi
2023-04-25  6:36     ` Jason Wang
2023-04-25  6:36       ` [virtio-dev] " Jason Wang
2023-04-25  7:21       ` zhenwei pi
2023-04-26  9:29       ` [virtio-comment] Re: [virtio-dev] " Xuan Zhuo
2023-04-26  9:29         ` Xuan Zhuo
2023-04-25 13:55   ` Stefan Hajnoczi
2023-04-25 13:55     ` [virtio-dev] " Stefan Hajnoczi
2023-04-26  1:08     ` zhenwei pi
2023-04-26  1:08       ` [virtio-dev] " zhenwei pi
2023-04-25 14:09   ` Stefan Hajnoczi [this message]
2023-04-25 14:09     ` [virtio-dev] " Stefan Hajnoczi
2023-04-26  3:03     ` Jason Wang
2023-04-26  3:03       ` [virtio-dev] " 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=20230425140942.GB697094@fedora \
    --to=stefanha@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=helei.sig11@bytedance.com \
    --cc=houp@yusur.tech \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=parav@nvidia.com \
    --cc=pizhenwei@bytedance.com \
    --cc=virtio-comment@lists.oasis-open.org \
    --cc=virtio-dev@lists.oasis-open.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.