Hi, > >> What if we have 2, 4, 10 HW NICs and a few different destinations for > >> traffic from VM? > >> What if we have 2, 4, 10 HW NICs added to balanced OVS bonding and just a > >> few different packet flows? > >> What if we have HW NICs with small number of TX queues (like VFs) and XPS > >> is working? > >> We may actually stuck with non-working virtual interface in all above > >> cases. > >> > >> IMHO, this feature should be marked as experimental until we don't have > >> proper solution > >> for that stuck mbufs in HW rings. > >> > >> Thoughts?
I definitely think this feature, if merged, should be declared experimental. As far as I can see there is no safe way to prevent vhostuser ports running out of descriptors and the negative impact on packet drop likelihood is so significant that it may not justify the small increase in saturation load. > >> > > > > How about using rte_eth_tx_done_cleanup() ? > > This API currently implemented only by igb driver. > This will not be much useful. > > > I guess a user would not > > want to combine this feature with sw tx batching though. Yes, tx batching with tx-flush-timer > 0 would not go well at all with zero-copy. We need to document that conflict in the final version. > > > > On a related note, I would like to ask Ciara/Jan the use case when this > > feature would likely be enabled. The RFC2544 test is very opaque but it > > seems there is at least some increased packet loss, so would it be just > > when the user knows it is vm-vm and large packets? (In which case you > > could argue, packets would not get stuck in HW NIC anyway) Given the current limitations I don't think zero-copy vhostuser is a viable option for Cloud deployments, where the bulk of the traffic is of type PVP. The VM-VM traffic case is unproblematic, but the issue I have is that at configuration time of the vhostuser port, the operator would have to make assumptions on whether the traffic remains local on the host or goes out to the physical network. But that depends on scheduling decisions by Nova, that the operator would typically not know in advance. All in all, I have no objections against merging zero copy as experimental feature, but from our perspective there is more value in the Tx batching patch series. BR, Jan _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
