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  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:   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.




Powered by blists - more mailing lists