[dpdk-dev] [PATCH 2/2] kni: fix rtnl deadlocks and race conditions v4

[Stephen Hemminger]

On Fri, 26 Feb 2021 00:01:01 +0300
Igor Ryzhov <iryzhov at nfware.com> wrote:

> Hi Elad,
> 
> Thanks for the patch, but this is still NACK from me.
> 
> The only real advantage of KNI over other exceptional-path techniques
> like virtio-user is the ability to configure DPDK-managed interfaces
> directly
> from the kernel using well-known utils like iproute2. A very important part
> of this is getting responses from the DPDK app and knowing the actual
> result of command execution.
> If you're making async requests to the application and you don't know
> the result, then what's the point of using KNI at all?
> 
> Igor

Do you have a better proposal that keeps the request result but does not
call userspace with lock held.

PS: I also have strong dislike of KNI, as designed it would have been rejected
by Linux kernel developers.  A better solution would be userspace version of
something like devlink devices. But doing control operations by proxy is
a locking nightmare.