On 10/12/2017 12:06 PM, David Miller wrote: > From: Florian Fainelli <f.fainelli@xxxxxxxxx> > 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. > > I think it's important that we don't expand the scope of devlink > beyond what it was originally designed for. It seems to me like devlink is well defined in what it is not for: it is not meant to be used for any object that is/has a net_device, but it is not well defined for what it can offer to these non network devices. For instance, we have a tremendous amount of operations that are extremely specific to its single user(s) such as mlx5 and mlxsw. For instance, I am not sure how the buffer reservation scheme can be generalized, and this is always the tricky part with a single user facility in that you try to generalize the best you can based on the HW you know. This is not a criticism or meant to be anything negative, this just happens to be the case, and we did not have anything better. So maybe the first thing is to clarify what devlink operations can and should be and what they are absolutely not allowed to cover. We should also clarify whether a generic set/get that Steven is proposing is something that we tolerate, or whether there should be specific function pointers implemented for each attribute, which would be more in line with what has been done thus far. -- Florian
