> 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
Fully agree, I'm almost finished reviewing the tx_batching, it's the priority feature, I expect it to be in the next pull request. After that I would like to see this reviewed with the required changes and merged as experimental. Ian > > Thanks Jan. > > > BR, Jan > > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
