linux-kernel - RE: [PATCH net-next] netdevsim: Add max_vfs to bus

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: <AM6PR05MB5142B1D44D6190BBDE19F7E0C5510@AM6PR05MB5142.eurprd05.prod.outlook.com>
Date:   Mon, 16 Dec 2019 22:52:30 +0000
From:   Yuval Avnery <yuvalav@...lanox.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
CC:     Jiri Pirko <jiri@...lanox.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Andy Gospodarek <andy@...yhouse.net>,
        Daniel Jurgens <danielj@...lanox.com>,
        Parav Pandit <parav@...lanox.com>
Subject: RE: [PATCH net-next] netdevsim: Add max_vfs to bus_dev



> -----Original Message-----
> From: Jakub Kicinski <jakub.kicinski@...ronome.com>
> Sent: Monday, December 16, 2019 12:45 PM
> To: Yuval Avnery <yuvalav@...lanox.com>
> Cc: Jiri Pirko <jiri@...lanox.com>; davem@...emloft.net;
> netdev@...r.kernel.org; linux-kernel@...r.kernel.org; Andy Gospodarek
> <andy@...yhouse.net>; Daniel Jurgens <danielj@...lanox.com>
> Subject: Re: [PATCH net-next] netdevsim: Add max_vfs to bus_dev
> 

> The ip-link API will suddenly start returning errors which may not be
> expected to the user space. So the question is what the user space is you're
> expecting to run/testing with? _Some_ user space should prove this design
> out before we merge it.
> 
> The alternative design is to "forward" hosts ip-link requests to the NIC CPU
> and let software running there talk to the cloud back end.
> Rather than going
>   customer -> could API -> NIC,
> go
>   customer -> NIC -> cloud API
> That obviously is more complex, but has the big advantage of nothing on the
> host CPU having to change.

I will try to summarize your comments:
1. There will always be encapsulation, therefore network management shouldn't care what MACs customers use.
2.  Customer is always requesting MAC, it never simply acquires it from the NIC.
     There is always going to be an entity running on the host setting MACs to VFs.

Is that correct?