[broadcom]: respect the current network namespace when creating netdev

[ishidawataru]

Broadcom-Switch/OpenNSL#26

Signed-off-by: Wataru Ishida [email protected]

[lguohan]

retest vsimage please

[lguohan]

I do not see other netdev drivers have this patch. Do you know if this is a standard behavior in kernel module?

[ishidawataru]

It depends on the device.
TUN device which I think similar to KNET device sets the current netns when creating netdevice.

https://elixir.bootlin.com/linux/latest/source/drivers/net/tun.c#L2789

ref: list of dev_net_set usage

https://elixir.bootlin.com/linux/latest/ident/dev_net_set

This patch won't change the current SONiC behavior since all SONiC containers are running with --net=host.
However, I think it is better to run containers which need access to front panel ports (like syncd/swss/frr/lldp) in a separate network namespace so that we can avoid configuring the netdevs directly without using SONiC toolchains from the default network namespace (e.g. assign an IP address via ip command which is not recommended in SONiC ).

[lguohan]

you assume the syncd container will be in the same namespace as swss. it is not always the case. a more generic solution is the create the netdev in global namespace and have a user space daemon to move the netdev to the right namespace.

[ishidawataru]

Yes, I was assuming putting syncd and swss ( and other daemons that need front panel port access ) in the same netns.
What would be the motivation to put syncd and swss in different namespaces?

I think it's not consistent with other virtual netdev like TUN or veth if we create KNET netdev in a network namespace other than the default and it pops out in the default one.
I feel more natural that the KNET will get created in the netns of the user.

If we need to move it to another namespace, we can do that after creating it.

[lguohan]

we are working on a case a single syncd support multiple asic, in that case, all the netdevs created by syncd will likely not in the same namespace. but I think your have a point. this knet driver is more like a tun/tap device than other traditional netdev.

[lguohan]

@judyjoseph