Re: [virtio-comment] [PATCH v5 1/2] virtio-vsock: add description for datagram type

["Michael S. Tsirkin" <mst@redhat.com>]

On Sat, Mar 05, 2022 at 01:25:44AM +0000, Bobby Eshleman wrote:
> On Thu, Mar 03, 2022 at 02:15:24AM -0500, Michael S. Tsirkin wrote:
> > On Thu, Mar 03, 2022 at 03:29:31AM +0000, Bobby Eshleman wrote:
> > > On Wed, Mar 02, 2022 at 05:09:58PM +0100, Stefano Garzarella wrote:
> > > > Hi Bobby,
> > > > Sorry for the delay, but I saw these patches today.
> > > > Please, can you keep me in CC?
> > > > 
> > > 
> > > Hey Stefano, sorry about that. I'm not sure how I lost your CC on this
> > > one. I'll make sure you are there moving forward.
> > > 
> > > I want to mention that I'm taking a look at
> > > https://gitlab.com/vsock/vsock/-/issues/1 in parallel with my dgram work
> > > here. After sending out this series we noticed potential overlap between
> > > the two issues. The additional dgram queues may become redundant if a
> > > fairness mechanism that solves issue #1 above also applies to
> > > connection-less protocols (similar to how the TC subsystem works). I've
> > > just begun sorting out potential solutions so no hard results yet. Just
> > > putting on your radar that the proposal here in v5 may be impacted if my
> > > investigation into issue #1 yields something adequate.
> > 
> > 
> > Well not mergeable, but datagram is upstream in Linux, is it not?
> > So we do want it in the spec IMHO, even if in the future there
> > will be a better protocol.
> > 
> 
> As of right now, it is not upstream in Linux. The virtio transport just passes
> -EOPNOTSUPP up the stack when the sock invokes it.
> 
> I think what you're thinking of is the vsock dgram in VMWare's vmci and
> Hyper-V. They support dgrams, but are not compatible with virtio (e.g., don't
> use virtqueues).
> 
> -Bobby

Oh no, I was thinking about SEQPACKET actually. Which has the same issue
I noted on another thread with memory accounting as datagram by the way.

-- 
MST