netdev - Re: [PATCH net-next 00/12] nfp: add flower app with representors

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20170622225014.59d673c6@cakuba.netronome.com>
Date:   Thu, 22 Jun 2017 22:50:14 -0700
From:   Jakub Kicinski <kubakici@...pl>
To:     Or Gerlitz <gerlitz.or@...il.com>
Cc:     Simon Horman <simon.horman@...ronome.com>,
        David Miller <davem@...emloft.net>,
        Linux Netdev List <netdev@...r.kernel.org>,
        oss-drivers@...ronome.com
Subject: Re: [PATCH net-next 00/12] nfp: add flower app with representors

On Thu, 22 Jun 2017 17:28:25 +0300, Or Gerlitz wrote:
> On Wed, Jun 21, 2017 at 12:42 PM, Jakub Kicinski <kubakici@...pl> wrote:
> 
> > Let me try to describe it a bit more instead.  Sorry but I'm not great
> > at ASCII art at this level of complexity and while having to stay
> > within 80 chars ;)
> >
> > Driver communicates with the Management FW via a mailbox.
> >
> > Driver loads, it gets the Application FW from disk.  It pushes the
> > entire FW to the mailbox and tells the Management FW to load it.  At
> > this point the PCIe datapath is loaded and driver discovers what
> > other communication channels are available.
> >
> > Driver checks which FW is loaded and finds appropriate nfp_app callbacks
> > for that FW.  If the nfp_app requires control message channel it will
> > map the control message queue/vNIC.  Driver spawn netdevs for
> > data vNICs.  Flower nfp_app may upon init spawn physical port
> > representors (single NFP chip supports tens of ports so they are not
> > all guaranteed a full vNIC in many designs).  Whenever representor is
> > spawned Application FW is notified with a control message.
> >
> > When user enables SR-IOV nfp_app sriov callback will be invoked and
> > flower nfp_app will respond by spawning VF reprs.  First version of the
> > Flower APP targets only the switchdev mode.  We plan to add legacy mode
> > and automatically pre-populate the rules if there is user interest.
> > Although I personally hope that people interested in legacy SR-IOV will
> > use our simpler CoreNIC app FW...  Flower APP will initially come up in
> > switchdev mode, no rules installed, all traffic will simply end up at
> > representors.  
> 
> This is much clearer now, thanks for explaining that over. Will be happy
> if you can elaborate a bit on the automatic tables pre-population for
> legacy mode emulation, sounds interesting.

Oh, I just meant that if someone wants to switch between legacy and
switchdev mode without changing the app FW - driver could hide the
representors and populate MAC/VLAN forwarding rules to get the same
behaviour as "legacy" cards have.