On Mon, Dec 28, 2020 at 7:47 PM Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > On Mon, Dec 28, 2020 at 02:51:09PM -0500, Willem de Bruijn wrote: > > On Mon, Dec 28, 2020 at 12:29 PM Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > > > > > On Mon, Dec 28, 2020 at 11:22:30AM -0500, Willem de Bruijn wrote: > > > > From: Willem de Bruijn <willemb@xxxxxxxxxx> > > > > > > > > RFC for three new features to the virtio network device: > > > > > > > > 1. pass tx flow hash and state to host, for routing + telemetry > > > > 2. pass rx tstamp to guest, for better RTT estimation > > > > 3. pass tx tstamp to host, for accurate pacing > > > > > > > > All three would introduce an extension to the virtio spec. > > > > I assume this would require opening three ballots against v1.2 at > > > > https://www.oasis-open.org/committees/ballots.php?wg_abbrev=virtio > > > > > > > > This RFC is to informally discuss the proposals first. > > > > > > > > The patchset is against v5.10. Evaluation additionally requires > > > > changes to qemu and at least one back-end. I implemented preliminary > > > > support in Linux vhost-net. Both patches available through github at > > > > > > > > https://github.com/wdebruij/linux/tree/virtio-net-txhash-1 > > > > https://github.com/wdebruij/qemu/tree/virtio-net-txhash-1 > > > > > > Any data on what the benefits are? > > > > For the general method, yes. For this specific implementation, not yet. > > > > Swift congestion control is delay based. It won the best paper award > > at SIGCOMM this year. That paper has a lot of data: > > https://dl.acm.org/doi/pdf/10.1145/3387514.3406591 . Section 3.1 talks > > about the different components that contribute to delay and how to > > isolate them. > > And for the hashing part? A few concrete examples of error conditions that can be resolved are mentioned in the commits that add sk_rethink_txhash calls. Such as commit 7788174e8726 ("tcp: change IPv6 flow-label upon receiving spurious retransmission"): " Currently a Linux IPv6 TCP sender will change the flow label upon timeouts to potentially steer away from a data path that has gone bad. However this does not help if the problem is on the ACK path and the data path is healthy. In this case the receiver is likely to receive repeated spurious retransmission because the sender couldn't get the ACKs in time and has recurring timeouts. This patch adds another feature to mitigate this problem. It leverages the DSACK states in the receiver to change the flow label of the ACKs to speculatively re-route the ACK packets. In order to allow triggering on the second consecutive spurious RTO, the receiver changes the flow label upon sending a second consecutive DSACK for a sequence number below RCV.NXT. " I don't have quantitative data on the efficacy at scale at hand. Let me see what I can find. This will probably take some time, at least until people are back after the holidays. I didn't want to delay the patch, as the merge window was a nice time for RFC. But agreed that it deserves stronger justification. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
