On 12/15/2017 12:32 PM, Jan Scheurich wrote: > 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. >
+1 Thanks Jan. > BR, Jan > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
