[ovs-dev] [ovs-dev, v5, 2/2] netdev-dpdk: Enable optional dequeue zero copy for vHost User

Stokes, Ian ian.stokes at intel.com
Fri Dec 15 18:52:31 UTC 2017


> 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
> >



More information about the dev mailing list