From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f65.google.com ([74.125.82.65]:46061 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750722AbdJMHLW (ORCPT ); Fri, 13 Oct 2017 03:11:22 -0400 Received: by mail-wm0-f65.google.com with SMTP id q124so18796025wmb.0 for ; Fri, 13 Oct 2017 00:11:22 -0700 (PDT) Date: Fri, 13 Oct 2017 09:11:21 +0200 From: Jiri Pirko To: Roopa Prabhu Cc: Florian Fainelli , David Miller , Steve Lin , "netdev@vger.kernel.org" , Jiri Pirko , Michael Chan , linux-pci@vger.kernel.org, "John W. Linville" , Andy Gospodarek Subject: Re: [RFC 0/3] Adding config get/set to devlink Message-ID: <20171013071121.GF1952@nanopsycho.orion> References: <20171012150419.GI14672@nanopsycho> <24E5DE7C-A401-48BF-BF80-673ACC38FBBE@gmail.com> <20171012.120650.1063812043202847517.davem@davemloft.net> <21ab4a5d-0b6a-7976-7bf0-acd334f2613f@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Sender: linux-pci-owner@vger.kernel.org List-ID: Thu, Oct 12, 2017 at 11:53:56PM CEST, roopa@cumulusnetworks.com wrote: >On Thu, Oct 12, 2017 at 12:20 PM, Florian Fainelli wrote: >> On 10/12/2017 12:06 PM, David Miller wrote: >>> From: Florian Fainelli >>> Date: Thu, 12 Oct 2017 08:43:59 -0700 >>> >>>> Once we move ethtool (or however we name its successor) over to >>>> netlink there is an opportunity for accessing objects that do and do >>>> not have a netdevice representor today (e.g: management ports on >>>> switches) with the same interface, and devlink could be used for >>>> that. >>> >>> That is an interesting angle for including this in devlink. >>> >>> I'm not so sure what to do about this. >>> >>> One suggestion is that devlink is used for getting ethtool stats for >>> objects lacking netdev representor's, and a new genetlink family is >>> used for netdev based ethtool. >> >> Right, I was also thinking along those lines that we we would have a new >> generic netlink family for ethtool to support ethtool over netlink. > >new api is fine by me. The reason for suggesting devlink was because >some of the devlink >port_* ops are close to ethtool ops that can operate on a port/netdev. >eg split_port could be a netdev operation >unless you want to split before the netdev is created. Let me correct you. The split is always devlink_port operation. In some cases however when there is a mapping between devlink_port and netdev, userspace part could translate netdev->devlink_port. > >There are some ops in devlink which are global hw parameters and not >specific to a port, those fit perfectly with >devlinks original goal. There are 2 handles from the very beginning: 1) devlink - asic-wide handle 2) devlink_port - port handle