Re: [virtio-dev] [RFC] vsock: add vsock device

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

On Wed, Jun 03, 2015 at 04:30:26PM +0100, Stefan Hajnoczi wrote:
> On Wed, Jun 03, 2015 at 10:56:52AM +0100, Stefan Hajnoczi wrote:
> > On Tue, Jun 02, 2015 at 04:29:06PM +0200, Michael S. Tsirkin wrote:
> > > On Tue, Jun 02, 2015 at 03:17:39PM +0100, Stefan Hajnoczi wrote:
> > > > On Mon, Jun 01, 2015 at 05:39:15PM +0200, Michael S. Tsirkin wrote:
> > > > > On Thu, May 21, 2015 at 05:40:41PM +0100, Stefan Hajnoczi wrote:
> > > > Perhaps we should drop the buffer space mechanism for dgram flows and
> > > > make the counters per-flow for streams.  That way the denial-of-service
> > > > issue is avoided.  Does that sound good?
> > > 
> > > As I mentioned separately, I'm not sure what does buffer space mechanism
> > > mean for dgram flows, since a flow must track msg boundaries which
> > > has memory overhead (for stream flows, small messages can be packed
> > > into a single buffer if necessary).
> > 
> > The receiver has a finite buffer size.  If the receiving userspace
> > application doesn't read from the buffer fast enough it can become full.
> > I guess the idea of buffer space management for dgram was to avoid
> > dropping packets by letting the sender know they must wait.
> 
> Hmm...the problem is that a dgram sender cannot track tx_cnt and
> subtract peer_fwd_cnt since peer_fwd_cnt includes the number of bytes
> received from all senders to this dgram socket.
> 
> If we drop buffer space management for dgram flows then it's equivalent
> to UDP.  That should be fine.
> 
> Stefan

It will work at some level. Though we get a ton of packet drops with UDP
and it's a big problem.  Do you have apps in mind that need datagram?
If no and you are unsure how datagram will work, we can start with just
the stream one.

-- 
MST