Re: [dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Oct 01, 2015 at 04:14:33PM +0300, Michael S. Tsirkin wrote:
> On Thu, Oct 01, 2015 at 01:07:13PM +0100, Bruce Richardson wrote:
> > > > This in itself is going to use up
> > > > a good proportion of the processing time, as well as that we have to spend cycles
> > > > copying the descriptors from one ring in memory to another. Given that right now
> > > > with the vector ixgbe driver, the cycle cost per packet of RX is just a few dozen
> > > > cycles on modern cores, every additional cycle (fraction of a nanosecond) has
> > > > an impact.
> > > > 
> > > > Regards,
> > > > /Bruce
> > > 
> > > See above.  There is no need for that on data path. Only re-adding
> > > buffers requires a system call.
> > > 
> > 
> > Re-adding buffers is a key part of the data path! Ok, the fact that its only on
> > descriptor rearm does allow somewhat bigger batches,
> 
> That was the point, yes.
> 
> > but the whole point of having
> > the kernel do this extra work you propose is to allow the kernel to scan and
> > sanitize the physical addresses - and that will take a lot of cycles, especially
> > if it has to handle all the different descriptor formats of all the different NICs,
> > as has already been pointed out.
> > 
> > /Bruce
> 
> Well the driver would be per NIC, so there's only need to support
> specific formats supported by a given NIC.
> 
> An alternative is to format the descriptors in kernel, based
> on just the list of addresses. This seems cleaner, but I don't
> know how efficient it would be.


Additionally. rearming descriptors can happen on another
core in parallel with processing packets on the first one.

This will use more CPU but help you stay within your PPS limits.

-- 
MST