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