From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiri Pirko Subject: Re: [patch net-next v2 0/9] Introduce devlink interface and first drivers to use it Date: Thu, 25 Feb 2016 23:58:03 +0100 Message-ID: <20160225225803.GA2191@nanopsycho.orion> References: <1456242694-29463-1-git-send-email-jiri@resnulli.us> <20160225.151247.479900417232368503.davem@davemloft.net> <56CF67BB.70901@stressinduktion.org> <20160225211256.GA2164@nanopsycho.orion> <56CF77DA.7050602@stressinduktion.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David Miller , netdev@vger.kernel.org, idosch@mellanox.com, eladr@mellanox.com, yotamg@mellanox.com, ogerlitz@mellanox.com, yishaih@mellanox.com, dledford@redhat.com, sean.hefty@intel.com, hal.rosenstock@gmail.com, eugenia@mellanox.com, roopa@cumulusnetworks.com, nikolay@cumulusnetworks.com, hadarh@mellanox.com, jhs@mojatatu.com, john.fastabend@gmail.com, jeffrey.t.kirsher@intel.com, brouer@redhat.com, ivecera@redhat.com, rami.rosen@intel.com, gospo@cumulusnetworks.com To: Hannes Frederic Sowa Return-path: Received: from mail-wm0-f41.google.com ([74.125.82.41]:35916 "EHLO mail-wm0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752409AbcBYW6G (ORCPT ); Thu, 25 Feb 2016 17:58:06 -0500 Received: by mail-wm0-f41.google.com with SMTP id g62so50185218wme.1 for ; Thu, 25 Feb 2016 14:58:06 -0800 (PST) Content-Disposition: inline In-Reply-To: <56CF77DA.7050602@stressinduktion.org> Sender: netdev-owner@vger.kernel.org List-ID: Thu, Feb 25, 2016 at 10:53:30PM CET, hannes@stressinduktion.org wrote: >On 25.02.2016 22:12, Jiri Pirko wrote: >>Thu, Feb 25, 2016 at 09:44:43PM CET, hannes@stressinduktion.org wrote: >>>On 25.02.2016 21:12, David Miller wrote: >>>>From: Jiri Pirko >>>>Date: Tue, 23 Feb 2016 16:51:25 +0100 >>>> >>>>>There a is need for some userspace API that would allow to expose things >>>>>that are not directly related to any device class like net_device of >>>>>ib_device, but rather chip-wide/switch-ASIC-wide stuff. >>>>> >>>>>Use cases: >>>>>1) get/set of port type (Ethernet/InfiniBand) >>>>>2) setting up port splitters - split port into multiple ones and squash again, >>>>> enables usage of splitter cable >>>>>3) setting up shared buffers - shared among multiple ports within >>>>> one chip (work in progress) >>>>>4) configuration of switch wide properties - resources division etc - This will >>>>> allow to pass configuration that is unacceptable to be passed as >>>>> a module option. >>>>> >>>>>First patch of this set introduces a new generic Netlink based interface, >>>>>called "devlink". It is similar to nl80211 model and it is heavily >>>>>influenced by it, including the API definition. The devlink introduction patch >>>>>implements use cases 1) and 2). Other 2 are in development atm and will >>>>>be addressed by follow-ups. >>>>> >>>>>It is very convenient for drivers to use devlink, as you can see in other >>>>>patches in this set. >>>>> >>>>>Counterpart for devlink is userspace tool for now called "dl". Command line >>>>>interface and outputs are derived from "ip" tool so it should be easy >>>>>for users to get used to it. >>>> >>>>I am very close to applying this series as-is. >>>> >>>>The clincher for me is that there is precendence in the nl80211 stuff, >>>>so obviously whatever userland infrastructure sits on top of that has >>>>found a way to deal whatever perceived shortcomings devlink has. >>> >>>Actually nl80211 phy interfaces aren't really managed by wpa_supplicant nor >>>NetworkManager, but they use net_device names to discover those later on. In >>>devlink we don't necessarily have netdev names, thus my only objection to >>>this series is to switch to stable topology identifiers. >> >>Hannes, as I mentioned earlier in one of my replies, you can choose to >>use devlink name or pci (or other) address for your commands. So you >>have your stable names even before udev takes care of renaming. It's up >>to you as a user what handle to use. > >I understood that part from the beginning. In my opinion we should simply >keep APIs simple and clean, reduced to the minimum and let user space build >upon this. > >If an entity in the kernel doesn't need a name and/or a naming database, I >would not bother implementing it. Not everyone is a kernel developer who uses >Linux and can infer the problems from dl --help. I bet most users will use >names at some point in time and they simply can't match even with the udev >quirks in place when setting up netbooting or configuration must happen from >the currently provided initramfs. This is my point. > >If names are fragile to use simply don't provide it if not necessary. > >devlink is an interface of its own and the names won't be referenced by other >subsystems like iptables -i or iproute. So why bother with names in >the kernel? > >On the rest with netlink etc. I agree already. I just want to eliminate >possible mistakes by users. > >Hope that makes my point more clear, Okay. You convinced me. Will send v3 removing in-kernel naming and indexing of devlinks and will only use bus type and bus name as a handle. Thanks.