RE: [PATCH net-next] netdevsim: Add max_vfs to bus_dev

[Yuval Avnery]

> -----Original Message-----
> From: Jakub Kicinski <jakub.kicinski@xxxxxxxxxxxxx>
> Sent: Monday, December 16, 2019 12:45 PM
> To: Yuval Avnery <yuvalav@xxxxxxxxxxxx>
> Cc: Jiri Pirko <jiri@xxxxxxxxxxxx>; davem@xxxxxxxxxxxxx;
> netdev@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Andy Gospodarek
> <andy@xxxxxxxxxxxxx>; Daniel Jurgens <danielj@xxxxxxxxxxxx>
> 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?