[dpdk-dev] [PATCH 2/2] kni: fix rtnl deadlocks and race conditions v4
stephen at networkplumber.org
Fri Feb 26 16:48:17 CET 2021
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
> 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?
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.
More information about the dev