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]

Message-ID: <1454951595.25441.4.camel@intel.com>
Date:	Mon, 8 Feb 2016 17:13:15 +0000
From:	"Keller, Jacob E" <jacob.e.keller@...el.com>
To:	"moorray3@...pl" <moorray3@...pl>
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, 2016-02-08 at 13:26 +0000, Jakub Kicinski wrote:
> Hi Jacob!
> 
> First of all thanks for putting your time into sorting this out,
> figuring out what to do with user-set RSS table when queues are
> reconfigured was a head scratcher for me as well.
> 

Yep!

> 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?

I do agree that the queue size reconfig can handle the new minimum
queue value easily.

Regards,
Jake