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 ;)
