All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: "Mogilappagari, Sudheer" <sudheer.mogilappagari@intel.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"mkubecek@suse.cz" <mkubecek@suse.cz>,
	"andrew@lunn.ch" <andrew@lunn.ch>,
	"corbet@lwn.net" <corbet@lwn.net>,
	"Samudrala, Sridhar" <sridhar.samudrala@intel.com>,
	"Nguyen, Anthony L" <anthony.l.nguyen@intel.com>
Subject: Re: [PATCH net-next v2] ethtool: add netlink based get rxfh support
Date: Wed, 9 Nov 2022 16:46:03 -0800	[thread overview]
Message-ID: <20221109164603.1fd508ca@kernel.org> (raw)
In-Reply-To: <IA1PR11MB626686775A30F79E8AE85905E4019@IA1PR11MB6266.namprd11.prod.outlook.com>

On Thu, 10 Nov 2022 00:26:23 +0000 Mogilappagari, Sudheer wrote:
> > Can we describe in more detail which commands are reimplemented?
> > Otherwise calling the command RXFH makes little sense.
> > We may be better of using RSS in the name in the first place.  
> 
> This is the ethtool command being reimplemented.
> ethtool -x|--show-rxfh-indir DEVNAME   Show Rx flow hash indirection table and/or RSS hash key
>         [ context %d ]
> 
> Picked RXFH based on existing function names and ethtool_rxfh
> structure. If it needs to change, how about RSS_CTX or just RSS ? 

I vote for just RSS.

> > > +  ``ETHTOOL_A_RXFH_HEADER``            nested  reply header
> > > +  ``ETHTOOL_A_RXFH_RSS_CONTEXT``       u32     RSS context number
> > > +  ``ETHTOOL_A_RXFH_INDIR_SIZE``        u32     RSS Indirection table size  
> > > +  ``ETHTOOL_A_RXFH_KEY_SIZE``          u32     RSS hash key size
> > > +  ``ETHTOOL_A_RXFH_HFUNC``             u32     RSS hash func  
> > 
> > This is u8 in the implementation, please make the implementation u32 as
> > documented.  
> 
> This should have been u8 instead. Will make it consistent.

u32 is better, data sizes in netlink are rounded up to 4 bytes anyway,
so u8 is 1 usable byte and 3 bytes of padding. Much better to use u32.

> > > +static int rxfh_prepare_data(const struct ethnl_req_info *req_base,
> > > +			     struct ethnl_reply_data *reply_base,
> > > +			     struct genl_info *info)
> > > +{
> > > +	struct rxfh_reply_data *data = RXFH_REPDATA(reply_base);
> > > +	struct net_device *dev = reply_base->dev;
> > > +	struct ethtool_rxfh *rxfh = &data->rxfh;
> > > +	struct ethnl_req_info req_info = {};
> > > +	struct nlattr **tb = info->attrs;
> > > +	u32 indir_size = 0, hkey_size = 0;
> > > +	const struct ethtool_ops *ops;
> > > +	u32 total_size, indir_bytes;
> > > +	bool mod = false;
> > > +	u8 dev_hfunc = 0;
> > > +	u8 *hkey = NULL;
> > > +	u8 *rss_config;
> > > +	int ret;
> > > +
> > > +	ops = dev->ethtool_ops;
> > > +	if (!ops->get_rxfh)
> > > +		return -EOPNOTSUPP;
> > > +
> > > +	ret = ethnl_parse_header_dev_get(&req_info,
> > > +					 tb[ETHTOOL_A_RXFH_HEADER],
> > > +					 genl_info_net(info), info->extack,
> > > +					 true);  
> > 
> > Why are you parsing again?
> > 
> > You hook in ethnl_default_doit() and ethnl_default_dumpit(), which
> > should call the parsing for you already.
> 
> My bad. Had used other netlink get command implementation as reference
> and overlooked request_ops->parse_request. 

Right, as you probably discovered the core ethtool code can do a lot of
work for you if the command doesn't have special requirements and you
can rely on the default doit / dumpit handling.

  reply	other threads:[~2022-11-10  0:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-04 23:42 [PATCH net-next v2] ethtool: add netlink based get rxfh support Sudheer Mogilappagari
2022-11-08  2:25 ` Jakub Kicinski
2022-11-10  0:26   ` Mogilappagari, Sudheer
2022-11-10  0:46     ` Jakub Kicinski [this message]
2022-11-10 22:08       ` Samudrala, Sridhar
2022-11-10 22:34         ` Jakub Kicinski
2022-11-10 23:24           ` Samudrala, Sridhar
2022-11-11  0:12             ` Jakub Kicinski
2022-11-14  4:23               ` Samudrala, Sridhar
2022-11-14 17:15                 ` Jakub Kicinski
2022-11-15  1:46                   ` Samudrala, Sridhar

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=20221109164603.1fd508ca@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=anthony.l.nguyen@intel.com \
    --cc=corbet@lwn.net \
    --cc=mkubecek@suse.cz \
    --cc=netdev@vger.kernel.org \
    --cc=sridhar.samudrala@intel.com \
    --cc=sudheer.mogilappagari@intel.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.