> -----Original Message-----
> From: Wang, Haiyue <haiyue.w...@intel.com>
> Sent: Wednesday, August 5, 2020 9:06 AM
> To: Jakub Kicinski <k...@kernel.org>
> Cc: Tom Herbert <t...@herbertland.com>; Venkataramanan, Anirudh
> <anirudh.venkatarama...@intel.com>; da...@davemloft.net;
> nhor...@redhat.com; sassm...@redhat.com; Bowers, AndrewX
> <andrewx.bow...@intel.com>; Kirsher, Jeffrey T <jeffrey.t.kirs...@intel.com>;
> netdev@vger.kernel.org; Nguyen, Anthony L <anthony.l.ngu...@intel.com>; Lu,
> Nannan <nannan...@intel.com>; Liang, Cunming <cunming.li...@intel.com>
> Subject: RE: [net-next 1/5] ice: add the virtchnl handler for AdminQ command
>
> > -----Original Message-----
> > From: Jakub Kicinski <k...@kernel.org>
> > Sent: Tuesday, August 4, 2020 04:46
> > To: Wang, Haiyue <haiyue.w...@intel.com>
> > Cc: Tom Herbert <t...@herbertland.com>; Venkataramanan, Anirudh
> > <anirudh.venkatarama...@intel.com>;
> > da...@davemloft.net; nhor...@redhat.com; sassm...@redhat.com;
> Bowers,
> > AndrewX <andrewx.bow...@intel.com>; Kirsher, Jeffrey T
> > <jeffrey.t.kirs...@intel.com>; netdev@vger.kernel.org; Nguyen, Anthony
> > L <anthony.l.ngu...@intel.com>; Lu, Nannan <nannan...@intel.com>;
> > Liang, Cunming <cunming.li...@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!
