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

Michael S. Tsirkin mst at redhat.com
Thu Oct 1 15:14:33 CEST 2015


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.

Device vendors and dpdk developers are probably the best people to
figure out what's the best thing to do here.

But it looks like it's not going to happen unless security is made
a requirement for upstreaming code.

-- 
MST


More information about the dev mailing list