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 18:18:53 +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>,
        "Liang, Cunming" <cunming.liang@...el.com>
Subject: RE: [net-next 1/5] ice: add the virtchnl handler for AdminQ command

> -----Original Message-----
> From: netdev-owner@...r.kernel.org <netdev-owner@...r.kernel.org> On Behalf Of Jakub Kicinski
> Sent: Thursday, July 16, 2020 02:04
> 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 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

Powered by blists - more mailing lists