netdev - Re: [PATCH 2/2] fm10k: correctly report error when changing number of channels

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 8 Feb 2016 19:23:38 +0000
From:	Jakub Kiciński <moorray3@...pl>
To:	"Keller, Jacob E" <jacob.e.keller@...el.com>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH 2/2] fm10k: correctly report error when changing number
 of channels

On Mon, 8 Feb 2016 17:13:15 +0000, Keller, Jacob E wrote:
> On Mon, 2016-02-08 at 13:26 +0000, Jakub Kicinski wrote:
> > On Fri,  5 Feb 2016 12:30:21 -0800, Jacob Keller wrote:
> > > +#define FM10K_FLAG_RETA_TABLE_CONFIGURED	(u32)(BIT(6))
> > 
> > If we go with your proposal every driver will have to keep track of 
> > how the RSS table was set and find max value on queue reconfig -
> > replicating effort and leaving space for diverging behaviour...
> > 
> 
> in which behavior has already diverged quite significantly, so shoring
> that up would be good as well.
> 
> > Would it be worth considering to place more of this code in the core?
> 
> Yes. I was unsure of how to do this, but I think I have a possible
> solution. Since basically all drivers are going to have the same issue,
> I think we can just do the check inside net/core/ethtool.c
> 
> At least some of the check can be done inside core ethtool, but I think
> we still need a way for driver to know it is in "default" mode, as the
> driver does behave differently in its reset flow depending on whether
> the RSS table has been set.
> 
> Maybe we can store it as a flag in the netdev structure instead?

Either flag in the netdev or keep your reset callback.  Neither seems
spectacularly clean.  Maybe someone with a better idea will speak up ;)