On Wed, Oct 28, 2020 at 07:34:36PM +0200, Ido Schimmel wrote: > On Wed, Oct 28, 2020 at 01:53:39AM +0100, Michal Kubecek wrote: > > On Tue, Oct 27, 2020 at 02:53:05PM -0700, Jakub Kicinski wrote: > > > > > > I did not look at the legacy code but I'm confused by what you wrote. > > > > > > IIUC for ioctl it's the user space that sets the advertised. > > > For netlink it's the kernel. > > > So how does the legacy flag make the kernel behave like it used to? > > > > The idea why I suggested "legacy" as the name was that it allowed > > ethtool to preserve the old behaviour (without having to query for > > supported modes first). But from this point of view it's indeed a bit > > confusing. > > I think it would be best to solve this by having user space query the > kernel for supported link modes if autoneg is being enabled without > additional parameters. Then user space will issue a set request with > ETHTOOL_A_LINKMODES_OURS being set to all supported link modes. > > It does not require kernel changes and would be easier on users that > currently need to resort to old ethtool despite having a kernel that > supports netlink-based ethtool.
That would certainly be a solution. I'm not exactly happy about having to issue two requests but (1) it would be limited to specific case with "autoneg on" without advertise, speed and duplex (and lanes, when/if it's introduced), (2) we would need an extra request to check support of the flag anyway and (3) supported modes of a device are unlikely to change so that we don't have to worry about races. Michal
