netdev - Re: [RFC] 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200324001143.GG20941@ziepe.ca>
Date:   Mon, 23 Mar 2020 21:11:43 -0300
From:   Jason Gunthorpe <jgg@...lanox.com>
To:     Andy Gospodarek <andy@...yhouse.net>
Cc:     Jiri Pirko <jiri@...nulli.us>, Jakub Kicinski <kuba@...nel.org>,
        netdev@...r.kernel.org, davem@...emloft.net, parav@...lanox.com,
        yuvalav@...lanox.com, saeedm@...lanox.com, leon@...nel.org,
        andrew.gospodarek@...adcom.com, michael.chan@...adcom.com,
        moshe@...lanox.com, ayal@...lanox.com, eranbe@...lanox.com,
        vladbu@...lanox.com, kliteyn@...lanox.com, dchickles@...vell.com,
        sburla@...vell.com, fmanlunas@...vell.com, tariqt@...lanox.com,
        oss-drivers@...ronome.com, snelson@...sando.io,
        drivers@...sando.io, aelior@...vell.com,
        GR-everest-linux-l2@...vell.com, grygorii.strashko@...com,
        mlxsw@...lanox.com, idosch@...lanox.com, markz@...lanox.com,
        jacob.e.keller@...el.com, valex@...lanox.com,
        linyunsheng@...wei.com, lihong.yang@...el.com,
        vikas.gupta@...adcom.com, magnus.karlsson@...el.com
Subject: Re: [RFC] current devlink extension plan for NICs

On Mon, Mar 23, 2020 at 07:32:00PM -0400, Andy Gospodarek wrote:

> If a smartnic wants to give control of flows to the host
> then it makes more sense to allow some communication at a higher layer
> so that requests for hardware offload can be easily validated against
> some sort of policy set forth by the admin of the smartnic.

The important rule is that a PF/VF/SF is always constrained by its
representor. It doesn't matter how it handles the packets internally,
via a tx/rx ring, via an eswitch offload, RDMA, iscsi, etc, it is all
the same as far as the representor is concerned..

Since eswitch is a powerful offload capability it makes sense to
directly nest it.

Jason