> Please let me make sure if I understand it correctly: > * always do copy with skb_orphan_frags_rx as Willem mentioned in the earlier > post, before the xmit_skb as opposed to my original patch, is safe but too > costly so cannot be adopted. One more point about msg_zerocopy in the guest. This does add new allocation limits on optmem and locked pages rlimit. Hitting these should be extremely rare. The tcp small queues limit normally throttles well before this. Virtio-net is an exception because it breaks the tsq signal by calling skb_orphan before transmission. As a result hitting these limits is more likely here. But, in this edge case the sendmsg call will not block, either, but fail with -ENOBUFS. The caller can send without zerocopy to make forward progress and trigger free_old_xmit_skbs from start_xmit. > * as a generic solution, if we were to somehow overcome the safety issue, track > the delay and do copy if some threshold is reached could be an answer, but it's > hard for now.> * so things like the current vhost-net implementation of deciding whether or not > to do zerocopy beforehand referring the zerocopy tx error ratio is a point of > practical compromise. The fragility of this mechanism is another argument for switching to tx napi as default. Is there any more data about the windows guest issues when completions are not queued within a reasonable timeframe? What is this timescale and do we really need to work around this. That is the only thing keeping us from removing the HoL blocking in vhost-net zerocopy. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
