netdev - Re: [net-next 1/5] ice: add the virtchnl handler for AdminQ command

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 27 Jul 2020 16:04:06 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Tom Herbert <tom@...bertland.com>
Cc:     "Venkataramanan, Anirudh" <anirudh.venkataramanan@...el.com>,
        "Wang, Haiyue" <haiyue.wang@...el.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "nhorman@...hat.com" <nhorman@...hat.com>,
        "sassmann@...hat.com" <sassmann@...hat.com>,
        "Bowers, AndrewX" <andrewx.bowers@...el.com>,
        "Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
        "Lu, Nannan" <nannan.lu@...el.com>
Subject: Re: [net-next 1/5] ice: add the virtchnl handler for AdminQ command

On Sat, 25 Jul 2020 09:39:07 -0700 Tom Herbert wrote:
> Jakub,
> 
> The fundamental problem we have wrt DPDK is that they are not just
> satisfied to just bypass the kernel datapath, they are endeavouring to
> bypass the kernel control path as well with things like RTE flow API.
> The purpose of this patch set, AFAICT, is to keep the kernel in the
> control plane path so that we can maintain one consistent management
> view of device resources. The unpleasant alternative is that DPDK will
> send control messages directly to the device thereby bypassing the
> kernel control plane and thus resulting in two independent entities
> managing the same device and forcing a bifurcated control plane in the
> device (which of course results in a complete mess!).

Sorry for a late reply.

I try to do my best to predict what effect the community pushing back
on merging features will have. It does appear that the unpleasant
alternative you mention is becoming more and more prevalent. I believe
this is a result of multiple factors - convenience of the single point
of control, backward/forward compat, the growing size of the driver SW
stack, relative SW vs Si development cost in a NIC project, software
distribution models..

My day to day experience working with NICs shows that FW has already
taken over high perf NICs, and I hate it. I'd take DPDK over closed
source FW any time of the day, but I will not fool myself into thinking
that expansion of FW control can be stopped by the kernel opening the
floodgates to anything the vendors want to throw at us. 

Ergo the lesser evil argument does not apply.

In this case, I'm guessing, Intel can reuse RTE flow -> AQ code written
to run on PFs on the special VF.

This community has selected switchdev + flower for programming flows.
I believe implementing flower offloads would solve your use case, and
at the same time be most beneficial to the netdev community.