Thu, Oct 12, 2017 at 11:53:56PM CEST, ro...@cumulusnetworks.com wrote: >On Thu, Oct 12, 2017 at 12:20 PM, Florian Fainelli <f.faine...@gmail.com> >wrote: >> On 10/12/2017 12:06 PM, David Miller wrote: >>> From: Florian Fainelli <f.faine...@gmail.com> >>> 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
