On Tue, 2013-10-08 at 07:10 +1100, Benjamin Herrenschmidt wrote: > On Mon, 2013-10-07 at 14:01 -0400, Tejun Heo wrote: > > I don't think the same race condition would happen with the loop. The > > problem case is where multiple msi(x) allocation fails completely > > because the global limit went down before inquiry and allocation. In > > the loop based interface, it'd retry with the lower number. > > > > As long as the number of drivers which need this sort of adaptive > > allocation isn't too high and the common cases can be made simple, I > > don't think the "complex" part of interface is all that important. > > Maybe we can have reserve / cancel type interface or just keep the > > loop with more explicit function names (ie. try_enable or something > > like that). > > We want to be able to request an MSI-X at runtime anyway ... if I want > to dynamically add a queue to my network interface, I want it to be able > to pop a new arbitrary MSI-X. If you want to dynamically allocate another queue, you'd either need to have them all pre-allocated at alloc_etherdev_mqs(), or add a new API to netdev that allows adding new queues on the fly. How things are done today, the Tx queues are all tacked onto the end of the netdev struct. That would have to change to probably a linked list of queues that could be grown or shrunk on the fly. netif_alloc_netdev_queues() would need to change the kzalloc() to a list allocation. Cheers, -PJ
