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]

Message-ID: <8026dce002758d509b310afa330823be0c8191ec.camel@intel.com>
Date:   Thu, 23 Jul 2020 00:37:29 +0000
From:   "Venkataramanan, Anirudh" <anirudh.venkataramanan@...el.com>
To:     "kuba@...nel.org" <kuba@...nel.org>,
        "Wang, Haiyue" <haiyue.wang@...el.com>
CC:     "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 Wed, 2020-07-15 at 11:03 -0700, Jakub Kicinski wrote:
> On Wed, 15 Jul 2020 01:17:26 +0000 Wang, Haiyue wrote:
> > > Could you say a little more about the application and motivation
> > > for
> > > this?
> > 
> > Sure, I will try to describe the whole story.
> > 
> > > We are talking about a single control domain here, correct?  
> > 
> > Correct.
> 
> We have a long standing policy of not supporting or helping
> bifurcated
> drivers.

Jakub,

From what I understand, a bifurcated driver carves out the host
interface netdev's queues (resources if you want to further generalize
this) and allows another entity to control/use them. If this is the
definition, then DCF is not bifurcating the driver.

DCF is on top of SR-IOV VFs and the device resources required for the
DCF VF are made available by the device through the PCI configuration
space during SR-IOV init. This part isn't anything different from the
usual SR-IOV VF instantiation. The DCF feature adds the ability for a
trusted VF to add flow rules. So this is really just an extension of
the VF-PF interface that allows advanced flow/switch rules programming.
Additionally, the driver also has a list of operations that the DCF VF
is allowed to execute.

Can you please clarify how you (and the community) define bifurcated
driver?

Thanks,
Ani