On Fri, Aug 25, 2017 at 06:44:36PM -0400, Willem de Bruijn wrote: > >> >> > We don't enable network watchdog on virtio but we could and maybe > >> >> > should. > >> >> > >> >> Can you elaborate? > >> > > >> > The issue is that holding onto buffers for very long times makes guests > >> > think they are stuck. This is funamentally because from guest point of > >> > view this is a NIC, so it is supposed to transmit things out in > >> > a timely manner. If host backs the virtual NIC by something that is not > >> > a NIC, with traffic shaping etc introducing unbounded latencies, > >> > guest will be confused. > >> > >> That assumes that guests are fragile in this regard. A linux guest > >> does not make such assumptions. > > > > Yes it does. Examples above: > > > > - a single slow flow can occupy the whole ring, you will not > > > > be able to make any new buffers available for the fast flow > > Oh, right. Though those are due to vring_desc pool exhaustion > rather than an upper bound on latency of any single packet. > > Limiting the number of zerocopy packets in flight to some fraction > of the ring ensures that fast flows can always grab a slot. > Running > out of ubuf_info slots reverts to copy, so indirectly does this. But > I read it correclty the zerocopy pool may be equal to or larger than > the descriptor pool. Should we refine the zcopy_used test > > (nvq->upend_idx + 1) % UIO_MAXIOV != nvq->done_idx > > to also return false if the number of outstanding ubuf_info is greater > than, say, vq->num >> 1? We'll need to think about where to put the threshold, but I think it's a good idea. Maybe even a fixed number, e.g. max(vq->num >> 1, X) to limit host resources. In a sense it still means once you run out of slots zcopt gets disabled possibly permanently. Need to experiment with some numbers. -- MST _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
