From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A351C43381 for ; Sun, 24 Feb 2019 20:33:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E424B2084D for ; Sun, 24 Feb 2019 20:33:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728406AbfBXUdg (ORCPT ); Sun, 24 Feb 2019 15:33:36 -0500 Received: from mx2.suse.de ([195.135.220.15]:35948 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726458AbfBXUdg (ORCPT ); Sun, 24 Feb 2019 15:33:36 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 6871AAED5; Sun, 24 Feb 2019 20:33:35 +0000 (UTC) Received: by unicorn.suse.cz (Postfix, from userid 1000) id A0D07E00AD; Sun, 24 Feb 2019 21:33:33 +0100 (CET) Date: Sun, 24 Feb 2019 21:33:33 +0100 From: Michal Kubecek To: Andrew Lunn Cc: Tariq Toukan , "John W. Linville" , netdev@vger.kernel.org, Eran Ben Elisha , Aya Levin Subject: Re: [PATCH ethtool] ethtool: Add support for 200Gbps (50Gbps per lane) link mode Message-ID: <20190224203333.GC1914@unicorn.suse.cz> References: <1551020901-20257-1-git-send-email-tariqt@mellanox.com> <20190224164751.GG26626@lunn.ch> <20190224184046.GB1914@unicorn.suse.cz> <20190224194015.GM26626@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190224194015.GM26626@lunn.ch> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Sun, Feb 24, 2019 at 08:40:15PM +0100, Andrew Lunn wrote: > > > This is getting less friendly all the time, and it was never very > > > friendly to start with. We have the strings which represent these link > > > modes in the table used for dumping caps. How about allowing the user > > > to list a comma separate list of modes. > > > > > > ethtool -s lan42 advertise 100000baseKR2/Full,100000baseSR2/Full,100000baseCR2/Full > > > > In my preliminary netlink patchset, I'm adding support for e.g. > > > > ethtool -s eth0 advertise 100baseT/Half off 1000baseT/Full on > > > > I'm not sure what would be more useful, if switching individual modes or > > listing the whole set. After all, we can also support both. But I fully > > agree that the numeric bitmaps are already too inconvenient. > > Hi Michal > > So are you doing a read/modify/write? In that case, off/on makes > sense. For a pure write, i don't see the need for off/on. When using netlink interface, the read/modify/write cycle is limited to kernel code and is done under rtnl_lock. The netlink interface allows userspace to send only attributes it wants to change and for bit sets (like link modes) to tell kernel which bits it wants to change so that there is no need to read current values first (and open a race window). When using ioctl interface, ethtool does read the value first even now as ETHTOOL_SLINKSETTINGS command uses struct ethtool_link_usettings which has also other members and there is no way to say we only want to change advertised link modes. Michal