From: Michal Kubecek <mkubecek@suse.cz>
To: netdev@vger.kernel.org
Cc: Jakub Kicinski <kuba@kernel.org>,
David Miller <davem@davemloft.net>, Jiri Pirko <jiri@resnulli.us>,
Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
John Linville <linville@tuxdriver.com>,
Johannes Berg <johannes@sipsolutions.net>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 10/15] ethtool: provide ring sizes with RINGS_GET request
Date: Thu, 12 Mar 2020 13:29:22 +0100 [thread overview]
Message-ID: <20200312122922.GN8012@unicorn.suse.cz> (raw)
In-Reply-To: <20200311161625.7292f745@kicinski-fedora-PC1C0HJN>
On Wed, Mar 11, 2020 at 04:16:25PM -0700, Jakub Kicinski wrote:
> On Wed, 11 Mar 2020 22:40:53 +0100 (CET) Michal Kubecek wrote:
> > +static int rings_prepare_data(const struct ethnl_req_info *req_base,
> > + struct ethnl_reply_data *reply_base,
> > + struct genl_info *info)
> > +{
> > + struct rings_reply_data *data = RINGS_REPDATA(reply_base);
> > + struct net_device *dev = reply_base->dev;
> > + int ret;
> > +
> > + if (!dev->ethtool_ops->get_ringparam)
> > + return -EOPNOTSUPP;
> > + ret = ethnl_ops_begin(dev);
> > + if (ret < 0)
> > + return ret;
> > + dev->ethtool_ops->get_ringparam(dev, &data->ringparam);
> > + ret = 0;
> > + ethnl_ops_complete(dev);
> > +
> > + return ret;
>
> nit: just return 0 and drop ret = 0 above, there is no goto here
OK
> > +}
> > +
> > +static int rings_reply_size(const struct ethnl_req_info *req_base,
> > + const struct ethnl_reply_data *reply_base)
> > +{
> > + return 8 * nla_total_size(sizeof(u32))
>
> nit: 8 is a little bit of a magic constant
I'll rewrite this as a sum of 8 entries with comment referring to
attribute types. It's still a compile time computed constant so that
there should be no impact on resulting code.
> > + + 0;
>
> nit: personally not a huge fan
I don't like it either, to be honest. I just thought, based on reading
some earlier discussions, that it's the preferred way as it enforces
a compiler error when someone adds a new attribute and forgets to
replace the semicolon with plus (which IIRC happened in the past).
But as I checked now, reasonably new gcc (at least from version 7)
issues a warning in such case so that it wouldn't go unnoticed with
various kbuild bots around. So I agree to get rid of this trick.
> > +static int rings_fill_reply(struct sk_buff *skb,
> > + const struct ethnl_req_info *req_base,
> > + const struct ethnl_reply_data *reply_base)
> > +{
> > + const struct rings_reply_data *data = RINGS_REPDATA(reply_base);
> > + const struct ethtool_ringparam *ringparam = &data->ringparam;
> > +
> > + if (nla_put_u32(skb, ETHTOOL_A_RINGS_RX_MAX,
> > + ringparam->rx_max_pending) ||
> > + nla_put_u32(skb, ETHTOOL_A_RINGS_RX_MINI_MAX,
> > + ringparam->rx_mini_max_pending) ||
> > + nla_put_u32(skb, ETHTOOL_A_RINGS_RX_JUMBO_MAX,
> > + ringparam->rx_jumbo_max_pending) ||
> > + nla_put_u32(skb, ETHTOOL_A_RINGS_TX_MAX,
> > + ringparam->tx_max_pending) ||
> > + nla_put_u32(skb, ETHTOOL_A_RINGS_RX,
> > + ringparam->rx_pending) ||
> > + nla_put_u32(skb, ETHTOOL_A_RINGS_RX_MINI,
> > + ringparam->rx_mini_pending) ||
> > + nla_put_u32(skb, ETHTOOL_A_RINGS_RX_JUMBO,
> > + ringparam->rx_jumbo_pending) ||
> > + nla_put_u32(skb, ETHTOOL_A_RINGS_TX,
> > + ringparam->tx_pending))
> > + return -EMSGSIZE;
>
> nit: I wonder if it's necessary to report the zero values..
Good point. I would say that it makes perfect sense to omit the
attributes if the max value is zero (i.e. this type of ring is not
supported) but I would still report zero current size if corresponding
limit is not zero as it means the zero size is meaningful. (Many drivers
do not allow zero size but I found one which does.)
Michal
next prev parent reply other threads:[~2020-03-12 12:29 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-11 21:40 [PATCH net-next 00/15] ethtool netlink interface, part 3 Michal Kubecek
2020-03-11 21:40 ` [PATCH net-next 01/15] ethtool: rename ethnl_parse_header() to ethnl_parse_header_dev_get() Michal Kubecek
2020-03-11 21:40 ` [PATCH net-next 02/15] ethtool: update mapping of features to legacy ioctl requests Michal Kubecek
2020-03-11 21:40 ` [PATCH net-next 03/15] ethtool: provide netdev features with FEATURES_GET request Michal Kubecek
2020-03-11 22:49 ` Jakub Kicinski
2020-03-12 9:19 ` Michal Kubecek
2020-03-11 21:40 ` [PATCH net-next 04/15] ethtool: add ethnl_parse_bitset() helper Michal Kubecek
2020-03-12 5:48 ` David Miller
2020-03-12 9:25 ` Michal Kubecek
2020-03-11 21:40 ` [PATCH net-next 05/15] ethtool: set netdev features with FEATURES_SET request Michal Kubecek
2020-03-11 22:56 ` Jakub Kicinski
2020-03-12 9:45 ` Michal Kubecek
2020-03-11 21:40 ` [PATCH net-next 06/15] ethtool: add FEATURES_NTF notification Michal Kubecek
2020-03-11 21:40 ` [PATCH net-next 07/15] ethtool: provide private flags with PRIVFLAGS_GET request Michal Kubecek
2020-03-11 23:03 ` Jakub Kicinski
2020-03-11 21:40 ` [PATCH net-next 08/15] ethtool: set device private flags with PRIVFLAGS_SET request Michal Kubecek
2020-03-11 23:07 ` Jakub Kicinski
2020-03-11 21:40 ` [PATCH net-next 09/15] ethtool: add PRIVFLAGS_NTF notification Michal Kubecek
2020-03-11 21:40 ` [PATCH net-next 10/15] ethtool: provide ring sizes with RINGS_GET request Michal Kubecek
2020-03-11 23:16 ` Jakub Kicinski
2020-03-12 12:29 ` Michal Kubecek [this message]
2020-03-11 21:40 ` [PATCH net-next 11/15] ethtool: set device ring sizes with RINGS_SET request Michal Kubecek
2020-03-11 23:22 ` Jakub Kicinski
2020-03-11 21:41 ` [PATCH net-next 12/15] ethtool: add RINGS_NTF notification Michal Kubecek
2020-03-11 21:41 ` [PATCH net-next 13/15] ethtool: provide channel counts with CHANNELS_GET request Michal Kubecek
2020-03-11 23:24 ` Jakub Kicinski
2020-03-11 21:41 ` [PATCH net-next 14/15] ethtool: set device channel counts with CHANNELS_SET request Michal Kubecek
2020-03-11 21:41 ` [PATCH net-next 15/15] ethtool: add CHANNELS_NTF notification 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=20200312122922.GN8012@unicorn.suse.cz \
--to=mkubecek@suse.cz \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=jiri@resnulli.us \
--cc=johannes@sipsolutions.net \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=netdev@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).