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

[Bobby Eshleman <beshleman.devbox@gmail.com>]

On Thu, Mar 03, 2022 at 06:41:11AM -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.
> 
> 
> With respect to datagram, there is actually another issue which also
> exists for stream but is smaller there - per message overhead is not
> accounted for.  For stream we can work around that by copying payload
> data.  For datagram we can't as we need to preserve message boundaries.
> One way to address that is to add config for host/guest per-message
> overhead, and have sender decrement fwd counter by that value for
> each message sent.
> 

As I'm just becoming acquainted with the code excuse me if this question is
naive: is the overhead not knowable by the implementation, and that is why a
configuration would be required? My naive assumption was that overhead is
coming from headers (and maybe other packet metadata?) which are known by the
implementation?

Thanks,
Bobby