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: <BN8PR11MB3795DABBB0D6A1E08585DF45F77E0@BN8PR11MB3795.namprd11.prod.outlook.com>
Date:   Wed, 15 Jul 2020 01:17:26 +0000
From:   "Wang, Haiyue" <haiyue.wang@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "nhorman@...hat.com" <nhorman@...hat.com>,
        "sassmann@...hat.com" <sassmann@...hat.com>,
        "Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
        "Lu, Nannan" <nannan.lu@...el.com>,
        "Bowers, AndrewX" <andrewx.bowers@...el.com>
Subject: RE: [net-next 1/5] ice: add the virtchnl handler for AdminQ command

> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Wednesday, July 15, 2020 02:24
> To: Wang, Haiyue <haiyue.wang@...el.com>
> Cc: Nguyen, Anthony L <anthony.l.nguyen@...el.com>; davem@...emloft.net; netdev@...r.kernel.org;
> nhorman@...hat.com; sassmann@...hat.com; Kirsher, Jeffrey T <jeffrey.t.kirsher@...el.com>; Lu, Nannan
> <nannan.lu@...el.com>; Bowers, AndrewX <andrewx.bowers@...el.com>
> Subject: Re: [net-next 1/5] ice: add the virtchnl handler for AdminQ command
> 
> On Tue, 14 Jul 2020 01:29:40 +0000 Wang, Haiyue wrote:
> > > On Mon, 13 Jul 2020 10:43:16 -0700 Tony Nguyen wrote:
> > > > From: Haiyue Wang <haiyue.wang@...el.com>
> > > >
> > > > The DCF (Device Config Function) is a named trust VF (always with ID 0,
> > > > single entity per PF port) that can act as a sole controlling entity to
> > > > exercise advance functionality such as adding switch rules for the rest
> > > > of VFs.
> > >
> > > But why? This looks like a bifurcated driver to me.
> >
> > Yes, like bifurcated about flow control. This expands Intel AVF virtual channel
> > commands, so that VF can talk to hardware indirectly, which is under control of
> > PF. Then VF can set up the flow control for other VFs. This enrich current PF's
> > Flow Director filter for PF itself only by ethtool.
> 
> 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.

As you know, with the help of vfio-pci kernel module, we can write the user space
driver for PCI devices, like DPDK. ;-)

We have
  1). user space iavf framework:
	http://git.dpdk.org/dpdk/tree/drivers/common/iavf

  2). user space iavf driver:
      http://git.dpdk.org/dpdk/tree/drivers/net/iavf

  3). user space ice driver with no SR-IOV support:
      http://git.dpdk.org/dpdk/tree/drivers/net/ice

Nowadays, the concept of control path and data path separation is popular, we tried
to design a software defined control path by the above software portfolio, and the
scenario is described in:
      http://doc.dpdk.org/guides/nics/ice.html 23.4.3. Device Config Function (DCF)

With the patch in user space ice driver:
      http://git.dpdk.org/dpdk/commit/?id=c5dccda9f2ae6ecc716892c233a0dadc94e013da

and this patch set in ice kernel driver, we can now promote the VF from iAVF (data
path we called) to DCF (control path) for each PF device.