On Tue, Apr 25, 2023 at 10:09 PM Stefan Hajnoczi <stefa...@redhat.com> wrote: > > On Mon, Apr 24, 2023 at 11:40:02AM +0800, Jason Wang wrote: > > On Sun, Apr 23, 2023 at 7:31 PM zhenwei pi <pizhen...@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.
That's my understanding. Btw, I'm also ok if we start with vring and optimize on top. Thanks > > Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org