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

[Avi Kivity <avi@scylladb.com>]

On 10/01/2015 06:01 PM, Stephen Hemminger wrote:
> On Thu, 1 Oct 2015 14:32:19 +0300
> Avi Kivity <avi@scylladb.com> wrote:
>
>> On 10/01/2015 02:27 PM, Michael S. Tsirkin wrote:
>>> On Thu, Oct 01, 2015 at 02:20:37PM +0300, Avi Kivity wrote:
>>>> People will just use out of tree drivers (dpdk has several already).  It's a
>>>> pain, but nowhere near what you are proposing.
>>> What's the issue with that?
>> Out of tree drivers have to be compiled on the target system (cannot
>> ship a binary package), and occasionally break.
>>
>> dkms helps with that, as do distributions that promise binary
>> compatibility, but it is still a pain, compared to just shipping a
>> userspace package.
>>
>>>    We already agreed this kernel
>>> is going to be tainted, and unsupportable.
>> Yes.  So your only motivation in rejecting the patch is to get the
>> author to write the ring translation patch and port it to all relevant
>> drivers instead?
> The per-driver ring method is what netmap did.
> The problem with that is that it forces infrastructure into already
> complex network driver. It never was accepted. There were also still
> security issues like time of check/time of use with the ring.

There would have to be two rings, with the driver picking up descriptors 
from the software ring, translating virtual addresses, and pushing them 
into the hardware ring.

I'm not familiar enough with the truly high performance dpdk 
applications to estimate the performance impact.  Seastar/scylla gets a 
huge benefit from dpdk, but is still nowhere near line rate.