From: Michal Kubecek <mkubecek@suse.cz>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Tariq Toukan <tariqt@mellanox.com>,
"John W. Linville" <linville@tuxdriver.com>,
netdev@vger.kernel.org, Eran Ben Elisha <eranbe@mellanox.com>,
Aya Levin <ayal@mellanox.com>
Subject: Re: [PATCH ethtool] ethtool: Add support for 200Gbps (50Gbps per lane) link mode
Date: Sun, 24 Feb 2019 21:33:33 +0100 [thread overview]
Message-ID: <20190224203333.GC1914@unicorn.suse.cz> (raw)
In-Reply-To: <20190224194015.GM26626@lunn.ch>
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
next prev parent reply other threads:[~2019-02-24 20:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-24 15:08 [PATCH ethtool] ethtool: Add support for 200Gbps (50Gbps per lane) link mode Tariq Toukan
2019-02-24 16:47 ` Andrew Lunn
2019-02-24 18:40 ` Michal Kubecek
2019-02-24 19:40 ` Andrew Lunn
2019-02-24 20:33 ` Michal Kubecek [this message]
2019-02-24 20:43 ` Andrew Lunn
2019-02-25 15:30 ` Tariq Toukan
2019-02-25 12:42 ` Aya Levin
2019-02-24 18:11 ` Michal Kubecek
2019-02-25 11:48 ` Michal Kubecek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190224203333.GC1914@unicorn.suse.cz \
--to=mkubecek@suse.cz \
--cc=andrew@lunn.ch \
--cc=ayal@mellanox.com \
--cc=eranbe@mellanox.com \
--cc=linville@tuxdriver.com \
--cc=netdev@vger.kernel.org \
--cc=tariqt@mellanox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.