From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [RFC] hv_netvsc: automatically name slave VF network device Date: Tue, 19 Dec 2017 13:29:49 -0800 Message-ID: <20171219132949.57926170@xeon-e3> References: <20171219193537.22587-1-sthemmin@microsoft.com> <20171219123234.683f9b8d@cakuba.netronome.com> <20171219124425.56033614@xeon-e3> <20171219131816.70645a7b@cakuba.netronome.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, Stephen Hemminger , Jiri Pirko To: Jakub Kicinski Return-path: Received: from mail-pg0-f41.google.com ([74.125.83.41]:36996 "EHLO mail-pg0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751499AbdLSV3x (ORCPT ); Tue, 19 Dec 2017 16:29:53 -0500 Received: by mail-pg0-f41.google.com with SMTP id o13so333527pgp.4 for ; Tue, 19 Dec 2017 13:29:52 -0800 (PST) In-Reply-To: <20171219131816.70645a7b@cakuba.netronome.com> Sender: netdev-owner@vger.kernel.org List-ID: On Tue, 19 Dec 2017 13:18:16 -0800 Jakub Kicinski wrote: > On Tue, 19 Dec 2017 12:44:25 -0800, Stephen Hemminger wrote: > > On Tue, 19 Dec 2017 12:32:34 -0800 > > Jakub Kicinski wrote: > > > > > On Tue, 19 Dec 2017 11:35:37 -0800, Stephen Hemminger wrote: > > > > Rename the VF device to ethX_vf based on the ethX as the > > > > synthetic device. This eliminates the need for delay on setup, > > > > and the PCI (udev based) naming is not reproducible on Hyper-V > > > > anyway. The name of the VF does not matter since all control > > > > operations take place the primary device. It does make the > > > > user experience better to associate the names. > > > > > > > > Based on feedback from all.systems.go talk. > > > > The downside is that it requires exporting a symbol from netdev > > > > core which makes it harder to backport. > > > > > > > > Signed-off-by: Stephen Hemminger > > > > > > Why do you have to name the devices in the kernel space in the first > > > place? :/ Why don't upstream the correct change to biosdevname like > > > hardware vendors do? > > > > biosdevname is dead, gone and wouldn't work on Azure (it dumpster dives in /dev/mem). > > Hm, I haven't worked on biosdevname myself, but AFAIU it also falls > back to information from the PCI VPD, which could be populated by > the hypervisor. VPD never had any useful standard are info. The rules used by udev come off sysfs, see: https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ > > > I assume you mean the modern application is udev, and it works but the name is meaningless > > because it based of synthetic PCI information. The PCI host adapter is simulated > > for pass through devices. Names like enp12s0. > > > > Since every passthrough VF device on Hyper-V/Azure has a matching synthetic > > network device with same mac address. It is best to have the relationship > > shown in the name. > > How about we make the VF drivers expose "vf" as phys_port_name? > Then systemd/udev should glue that onto the name regardless of > how the VF is used. One of the goals was not to modify in any way other drivers (like VF). > > > > Your VF setup is really _not_ special, I don't understand why we are > > > OK with ignoring the standard practices. Real enterprise distroes > > > are very careful never to break the naming of interfaces and they keep > > > the naming policy in user space. Playing tricks in the kernel has every > > > chance of breaking existing user setups. > > > > Actually, Systemd folks said "naming policy is in userspace only because > > kernel can't get it right". Also there is no uniformity in userspace > > there are at least 5 systems trying to do network setup. And most of > > them depend on eth0 (yes still). Fixing userspace is impossible.