> -----Original Message-----
> From: netdev-ow...@vger.kernel.org <netdev-ow...@vger.kernel.org> On Behalf
> Of Jakub Kicinski
> Sent: Thursday, July 16, 2020 02:04
> To: Wang, Haiyue <haiyue.w...@intel.com>
> Cc: Nguyen, Anthony L <anthony.l.ngu...@intel.com>; da...@davemloft.net;
> netdev@vger.kernel.org;
> nhor...@redhat.com; sassm...@redhat.com; Kirsher, Jeffrey T
> <jeffrey.t.kirs...@intel.com>; Lu, Nannan
> <nannan...@intel.com>; Bowers, AndrewX <andrewx.bow...@intel.com>
> Subject: Re: [net-next 1/5] ice: add the virtchnl handler for AdminQ command
>
> 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.
I searched the concept about 'Bifurcated', not sure the below is the corret:
"Queue Splitting (Bifurcated Driver) is a design that allows for directing
some traffic to user space, while keeping the remaining traffic in the
traditional Linux networking stack."
What we did is some path finding about how to partition the hardware function
in real world to meet customer's requirement flexibly.
>
> I'm tossing this from patchwork.
Thanks for your time, I understand your concern from another point. We fix the
real world issue by our limited wisdom, and it is nice to open source our design
to get the feedback of the net community.
Problems
- User app expects to take advantage of a few SR-IOV PF capabilities (e.g.
binary/ternary classify) in raw manner
- It doesn't expect to take control of entire SR-IOV PF device from user
space
Motivation
- Single control domain is always managed by kernel SR-IOV PF driver
- It allows app to issue access intent for raw capabilities via named
trust virtchnl
