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: <20190626091838.03dfca5b@cakuba.netronome.com>
Date:   Wed, 26 Jun 2019 09:18:38 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Shannon Nelson <snelson@...sando.io>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH net-next 13/18] ionic: Add initial ethtool support

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