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

[Shannon Nelson <snelson@pensando.io>]

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.

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

sln