netdev - RE: [RFC v2] current devlink extension plan for NICs

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: <AM0PR05MB4866653E5683E3822ED22037D1B60@AM0PR05MB4866.eurprd05.prod.outlook.com>
Date:   Wed, 20 May 2020 12:58:52 +0000
From:   Parav Pandit <parav@...lanox.com>
To:     Jacob Keller <jacob.e.keller@...el.com>,
        Jiri Pirko <jiri@...nulli.us>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        Yuval Avnery <yuvalav@...lanox.com>,
        "jgg@...pe.ca" <jgg@...pe.ca>,
        Saeed Mahameed <saeedm@...lanox.com>,
        "leon@...nel.org" <leon@...nel.org>,
        "andrew.gospodarek@...adcom.com" <andrew.gospodarek@...adcom.com>,
        "michael.chan@...adcom.com" <michael.chan@...adcom.com>,
        Moshe Shemesh <moshe@...lanox.com>,
        Aya Levin <ayal@...lanox.com>,
        Eran Ben Elisha <eranbe@...lanox.com>,
        Vlad Buslov <vladbu@...lanox.com>,
        Yevgeny Kliteynik <kliteyn@...lanox.com>,
        "dchickles@...vell.com" <dchickles@...vell.com>,
        "sburla@...vell.com" <sburla@...vell.com>,
        "fmanlunas@...vell.com" <fmanlunas@...vell.com>,
        Tariq Toukan <tariqt@...lanox.com>,
        "oss-drivers@...ronome.com" <oss-drivers@...ronome.com>,
        "snelson@...sando.io" <snelson@...sando.io>,
        "drivers@...sando.io" <drivers@...sando.io>,
        "aelior@...vell.com" <aelior@...vell.com>,
        "GR-everest-linux-l2@...vell.com" <GR-everest-linux-l2@...vell.com>,
        "grygorii.strashko@...com" <grygorii.strashko@...com>,
        mlxsw <mlxsw@...lanox.com>, Ido Schimmel <idosch@...lanox.com>,
        Mark Zhang <markz@...lanox.com>,
        Alex Vesker <valex@...lanox.com>,
        "linyunsheng@...wei.com" <linyunsheng@...wei.com>,
        "lihong.yang@...el.com" <lihong.yang@...el.com>,
        "vikas.gupta@...adcom.com" <vikas.gupta@...adcom.com>,
        "sridhar.samudrala@...el.com" <sridhar.samudrala@...el.com>
Subject: RE: [RFC v2] current devlink extension plan for NICs


> From: Jacob Keller <jacob.e.keller@...el.com>
> Sent: Wednesday, May 20, 2020 1:15 AM
> 
> On 5/18/2020 10:17 PM, Parav Pandit wrote:
> > Hi Jake,
> >
> 
> >> Ok. So in the smart NIC CPU, we'd see the primary PF and some child
> >> PFs, and in the host system we'd see a "primary PF" that is the other
> >> end of the associated Child PF, and might be able to manage its own
> subswitch.
> >>
> >> Ok this is making more sense now.
> >>
> >> I think I had imagined that was what subfuntions were. But really
> >> subfunctions are a bit different, they're more similar to expanded VFs?
> >>
> >
> > 1. Sub functions are more light weight than VFs because, 2. They share
> > the same PCI device (BAR, IRQs) as that of PF/VF on which it is deployed.
> > 3. Unlike VFs which are enabled/disabled in bulk, subfunctions are created,
> deployed in unit of 1.
> >
> > Since this RFC content is overwhelming, I expanded the SF plumbing details
> more in [1] in previous RFC version.
> > You can replace 'devlink slice' with 'devlink port func' in [1].
> >
> > [1] https://marc.info/?l=linux-netdev&m=158555928517777&w=2
> >
> 
> Thanks! Indeed, this makes things a lot more clear to me now.
> 
Thanks for the review Jake.

> Regards,
> Jake