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

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: <4ffa2c70-9ae7-15eb-3b21-34148de89b44@pensando.io>
Date:   Wed, 26 Jun 2019 09:07:29 -0700
From:   Shannon Nelson <snelson@...sando.io>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH net-next 13/18] ionic: Add initial ethtool support

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