Re: [PATCH net-next 13/18] ionic: Add initial ethtool support

[Jakub Kicinski <jakub.kicinski@netronome.com>]

On Wed, 26 Jun 2019 09:07:29 -0700, Shannon Nelson wrote:
> On 6/25/19 4:54 PM, Jakub Kicinski wrote:
> > On Thu, 20 Jun 2019 13:24:19 -0700, Shannon Nelson wrote:  
> >> +	running = test_bit(LIF_UP, lif->state);
> >> +	if (running)
> >> +		ionic_stop(netdev);
> >> +
> >> +	lif->ntxq_descs = ring->tx_pending;
> >> +	lif->nrxq_descs = ring->rx_pending;
> >> +
> >> +	if (running)
> >> +		ionic_open(netdev);
> >> +	clear_bit(LIF_QUEUE_RESET, lif->state);
> >> +	running = test_bit(LIF_UP, lif->state);
> >> +	if (running)
> >> +		ionic_stop(netdev);
> >> +
> >> +	lif->nxqs = ch->combined_count;
> >> +
> >> +	if (running)
> >> +		ionic_open(netdev);
> >> +	clear_bit(LIF_QUEUE_RESET, lif->state);  
> > I think we'd rather see the drivers allocate/reserve the resources
> > first, and then perform the configuration once they are as sure as
> > possible it will succeed :(  I'm not sure it's a hard requirement,
> > but I think certainly it'd be nice in new drivers.  
> I think I know what you mean, but I suspect it depends upon which 
> resources.  I think the point of the range checking already being done 
> covers what the driver is pretty sure it can handle, as early on it went 
> through some sizing work to figure out the max queues, interrupts, 
> filters, etc.

Yes, hopefully those don't fail.

> If we're looking at memory resources, then it may be a little harder: 
> should we try to allocate a whole new set of buffers before dropping 
> what we have, straining memory resources even more, or do we try to 
> extend or contract what we currently have, a little more complex 
> depending on layout?
> 
> Interesting...

Indeed. I think whichever is simpler :) Either way we get shorter
traffic disruption and avoid the risk of "half up" interfaces..