On Wed, 22 Nov 2023 18:55:17 +0200 Vladimir Oltean wrote: > > Well, ethtool has been the catch all for a lot of random things > > for the longest time. The question is whether we want to extend > > ETHTOOL_GET_TS_INFO or add a third API somewhere else. And if we > > do - do we also duplicate the functionality of ETHTOOL_GET_TS_INFO > > (i.e. getting capabilities)? > > > > My vote is that keeping it in ethtool is less bad than 3rd API. > > With SIOCSHWTSTAMP also implemented by CAN (and presumably also by > wireless in the future), I do wonder whether ethtool is the right place > for the netlink conversion. ethtool currently provides the only way we have to configure ring length, ring count, RSS, UDP tunnels etc. It's a matter of taste, IMO ethtool is a bit of a lost cause already and keeping things together (ethtool already has TS_INFO) is cleaner than spreading them around. > I wouldn't suggest duplicating ETHTOOL_GET_TS_INFO towards the netdev > netlink family. FTR so far the netdev family is all about SW configuration. We should probably keep it that way, so it doesn't become ginormous. It's easy enough to create a new family, if needed.
