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: <20200323123116.769e50e4@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Mon, 23 Mar 2020 12:31:16 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Parav Pandit <parav@...lanox.com>
Cc:     Jiri Pirko <jiri@...nulli.us>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        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>,
        "jacob.e.keller@...el.com" <jacob.e.keller@...el.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>,
        "magnus.karlsson@...el.com" <magnus.karlsson@...el.com>
Subject: Re: [RFC] current devlink extension plan for NICs

On Sat, 21 Mar 2020 09:07:30 +0000 Parav Pandit wrote:
> > I see so you want the creation to be controlled by the same entity that
> > controls the eswitch..
> > 
> > To me the creation should be on the side that actually needs/will use
> > the new port. And if it's not eswitch manager then eswitch manager
> > needs to ack it.
> >  
> 
> There are few reasons to create them on eswitch manager system as below.
> 
> 1. Creation and deletion on one system and synchronizing it with eswitch
> system requires multiple back-n-forth calls between two systems.
> 
> 2. When this happens, system where its created, doesn't know when is the
> right time to provision to a VM or to a application.
> udev/systemd/Network Manager and others such software might already
> start initializing it doing DHCP but its switch side is not yet ready.

Networking software can deal with link down..

> So it is desired to make sure that once device is fully
> ready/configured, its activated.
> 
> 3. Additionally it doesn't follow mirror sequence during deletion when
> created on host.

Why so? Surely host needs to request deletion, otherwise container
given only an SF could be cut off?

> 4. eswitch administrator simply doesn't have direct access to the system
> where this device is used. So it just cannot be created there by eswitch
> administrator.

Right, that is the point. It's the host admin that wants the new
entity, so if possible it'd be better if they could just ask for it 
via devlink rather than some cloud API. Not that I'm completely opposed
to a cloud API - just seems unnecessary here.