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

["Liang, Cunming" <cunming.liang@intel.com>]

> -----Original Message-----
> From: Wang, Haiyue <haiyue.wang@intel.com>
> Sent: Wednesday, August 5, 2020 9:06 AM
> To: Jakub Kicinski <kuba@kernel.org>
> Cc: Tom Herbert <tom@herbertland.com>; Venkataramanan, Anirudh
> <anirudh.venkataramanan@intel.com>; davem@davemloft.net;
> nhorman@redhat.com; sassmann@redhat.com; Bowers, AndrewX
> <andrewx.bowers@intel.com>; Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>;
> netdev@vger.kernel.org; Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Lu,
> Nannan <nannan.lu@intel.com>; Liang, Cunming <cunming.liang@intel.com>
> Subject: RE: [net-next 1/5] ice: add the virtchnl handler for AdminQ command
> 
> > -----Original Message-----
> > From: Jakub Kicinski <kuba@kernel.org>
> > Sent: Tuesday, August 4, 2020 04:46
> > To: Wang, Haiyue <haiyue.wang@intel.com>
> > Cc: Tom Herbert <tom@herbertland.com>; Venkataramanan, Anirudh
> > <anirudh.venkataramanan@intel.com>;
> > davem@davemloft.net; nhorman@redhat.com; sassmann@redhat.com;
> Bowers,
> > AndrewX <andrewx.bowers@intel.com>; Kirsher, Jeffrey T
> > <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; Nguyen, Anthony
> > L <anthony.l.nguyen@intel.com>; Lu, Nannan <nannan.lu@intel.com>;
> > Liang, Cunming <cunming.liang@intel.com>
> > Subject: Re: [net-next 1/5] ice: add the virtchnl handler for AdminQ
> > command
> >
> > On Mon, 3 Aug 2020 10:39:52 +0000 Wang, Haiyue wrote:
> > > > 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.

Jakub, thanks for the feedback. We proposed the previous solution in our eagerness to satisfy customers who were using mature, and validated (for their data centers) host kernels and still enable rapid adaption to new network control planes.

When revisiting the real problems we were facing, basically we're looking for a rapid self-iteration control plane independent of a mature deployed host kernel. Definitely kernel is the most suitable path for a control plane and we need to enhance the kernel to add the missing piece required for this solution. Best way to achieve this is allow such use cases is to deploy control plane on latest kernel running as virtual machine. We shared some thoughts on netdev 0x14 workshop, attached link as https://github.com/seaturn/switchdev-trust-vf/blob/master/netconf-workshop.pdf.

As a follow-up, we'll continue work on tc-generic proposal and look for programming rate improvement. As an independent effort of enhancing tc-generic/switchdev on trusted VF, delegating device specific capabilities (e.g. eswitch) to an assignable trusted VF brings all the benefit of a separated kernel to upgrade up-to-date features in the pace of applications, and always prevent host stack from any connectivity (e.g. stable access) issues.

Will be happy to answer any queries...and thank you for guiding us in the right path.

> > >
> > > Jakub,
> > >
> > > Thanks, I deep into the switchdev, it is kernel software bridge for
> > > hardware offload, and each port is registered with register_netdev.
> > > So this solution is not suitable for current case: VF can be assigned to VMs.
> >
> > You may be missing the concept of a representor.
> >
> 
> I found the concept, thanks, missed it!