[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance
Alexander Duyck
alexander.duyck at gmail.com
Fri Oct 2 18:57:18 CEST 2015
On 10/02/2015 07:00 AM, Michael S. Tsirkin wrote:
> On Thu, Oct 01, 2015 at 02:02:24PM -0700, Alexander Duyck wrote:
>> validation and translation would add 10s if not 100s of nanoseconds to the
>> time needed to process each packet. In addition we are talking about doing
>> this in kernel space which means we wouldn't really be able to take
>> advantage of things like SSE or AVX instructions.
> Yes. But the nice thing is that it's rearming so it can happen on
> a separate core, in parallel with packet processing.
> It does not need to add to latency.
Moving it to another core is automatically going to add extra latency.
You will have to evict the data out of the L1 cache for one core and
into the L1 cache for another when you update it, and then reading it
will force it to have to transition back out. If you are lucky it is
only evicted to L2, if not then to L3, or possibly even back to memory.
Odds are that alone will add tens of nanoseconds to the process, and you
would need three or more cores to do the same workload as running the
process over multiple threads means having to add synchronization
primitives to the whole mess. Then there is the NUMA factor on top of that.
> You will burn up more CPU, but again, all this for boxes/hypervisors
> without an IOMMU.
There are use cases this will completely make useless. If for example
you are running a workload that needs three cores with DPDK bumping it
to nine or more will likely push you out of being able to do the
workload on some systems.
> I'm sure people can come up with even better approaches, once enough
> people get it that kernel absolutely needs to be protected from
> userspace.
I don't see that happening. Many people don't care about kernel
security that much. If they did something like DPDK wouldn't have
gotten off of the ground. Once someone has the ability to load kernel
modules any protection of the kernel from userspace pretty much goes
right out the window. You are just as much at risk from a buggy driver
in userspace as you are from one that can be added to the kernel.
> Long term, the right thing to do is to focus on IOMMU support. This
> gives you hardware-based memory protection without need to burn up CPU
> cycles.
We have a solution that makes use of IOMMU support with vfio. The
problem is there are multiple cases where that support is either not
available, or using the IOMMU provides excess overhead.
- Alex
More information about the dev
mailing list