On Wed, 26 Jun 2019 09:07:29 -0700, Shannon Nelson wrote:

On 6/25/19 4:54 PM, Jakub Kicinski wrote:

quoted

On Thu, 20 Jun 2019 13:24:19 -0700, Shannon Nelson wrote:  

quoted

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