netdev - Re: [PATCH net-next v2 12/14] sfc: set EF100 VF MAC address through representor

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: <f0f5e9c8-d811-3412-a298-628e7abf4ba9@gmail.com>
Date:   Fri, 29 Jul 2022 16:17:47 +0100
From:   Edward Cree <ecree.xilinx@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     ecree@...inx.com, davem@...emloft.net, pabeni@...hat.com,
        linux-net-drivers@....com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v2 12/14] sfc: set EF100 VF MAC address through
 representor

On 29/07/2022 02:45, Jakub Kicinski wrote:
>> Devlink port function *would* be useful for administering functions
>>  that don't have a representor.  I just can't see any good reason
>>  why such things should ever exist.
> 
> The SmartNIC/DPU/IPU/isolated hv+IO CPU can expose storage functions
> to the peer. nVidia is working on extending the devlink rate limit API
> to cover such cases.

All the storage-on-SmartNIC setups I can imagine involve the storage
 function (e.g. a virtio-blk PF) being connected to the network switch,
 either to access remote network storage or to export the local storage
 over the network.  (I'm not quite sure why you'd bother combining
 storage and networking functionality onto a single device if they
 _weren't_ connected in this way.)
Which means that your storage function has a v-switch port, and thus
 should have a representor netdevice so you can e.g. use tc rules to
 define its access to the physical network.
Arguably any network rate limiting you then want to apply to that
 function's v-switch port should be in the form of a tc police action.
(Which is far more flexible than devlink rate, because you can have
 different policers for traffic matching different tc filters, e.g.
 separate rate limits for control and data traffic of the dFS.)

Idk, maybe I'm being crazy in assuming that hardware has sane design
 semantics.  But the obvious way to build a SmartNIC maps very cleanly
 onto representors, without any need for devlink port function, and I
 think it makes more sense to say that maybe some weird device might
 end up having representors to control some objects that don't have
 network access, than that everyone has to implement this whole
 parallel structure of devlink objects for things that already have
 representors.

-ed