[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y42hg4MsATH/07ED@unreal>
Date: Mon, 5 Dec 2022 09:45:07 +0200
From: Leon Romanovsky <leon@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Sudheer Mogilappagari <sudheer.mogilappagari@...el.com>,
netdev@...r.kernel.org, mkubecek@...e.cz, andrew@...n.ch,
corbet@....net, sridhar.samudrala@...el.com,
anthony.l.nguyen@...el.com
Subject: Re: [PATCH net-next v7] ethtool: add netlink based get rss support
On Sun, Dec 04, 2022 at 03:38:50PM -0800, Jakub Kicinski wrote:
> On Sun, 4 Dec 2022 14:17:05 +0200 Leon Romanovsky wrote:
> > On Thu, Dec 01, 2022 at 04:25:55PM -0800, Sudheer Mogilappagari wrote:
> > > Add netlink based support for "ethtool -x <dev> [context x]"
> > > command by implementing ETHTOOL_MSG_RSS_GET netlink message.
> > > This is equivalent to functionality provided via ETHTOOL_GRSSH
> > > in ioctl path. It sends RSS table, hash key and hash function
> > > of an interface to user space.
> > >
> > > This patch implements existing functionality available
> > > in ioctl path and enables addition of new RSS context
> > > based parameters in future.
> >
> > But why do you do this conversion now? Was this "future" already
> > discussed on the ML?
>
> Conversion to netlink stands on its own.
It doesn't answer on my question. The answer is "we do, just because we
can" is nice but doesn't remove my worries that such "future" extension
will work with real future feature. From my experience, many UAPI designs
without real use case in hand will require adaptions and won't work out-of-box.
IMHO, it is the same sin as premature optimization.
>
> > > + u8 *rss_config;
> > > + int ret;
> >
> > <...>
> >
> > > + data->indir_table = (u32 *)rss_config;
> >
> > Please use correct type from the beginning.
>
> There are two tables in this memory, the second one is u8.
> So one of them will need the cast, the code is fine AFAICT.
Right, I missed hkey.
Thanks
Powered by blists - more mailing lists