> Yes - there's a FIXME to extend that, but I'm waiting for > examples of such arguments: no point adding the facility > until we're sure something will need to use it. > So far I have no concrete examples of anything needing it. You are right for the load-level selector. I don't know how real the selector I had in mind is (my impression when talking with NUMA people). As I understood they would need to decide for every io which path to take, based on a relation between the memory of the io and the adapter. So you would need to get called for every io (we could do that by using 1 as repeat count) and a way to set this correlation. This would require individual selector arguments. > I'm trying exporting a new 'struct path' to ps & hwh with > space for them to add their own state information. > struct dm_dev *dev; // Not allowed to change this > void *pscontext; > void *hwhcontext; > [patches on laptop which I can't connect today] That would help to quickly find selector and hw handler data from a passed in path pointer. Especially on status info calls the path lookup should be quick. Sounds good. > > I don't would it help to provide an example patch? > > Most useful thing at present would be discussion of examples of > realistic alternative classes of path selection algorithms so > we can check how they fit into the framework. > > The two considered so far are round-robin (already implemented) > and load-balancing (which I believe the current interface will > support adequately, possibly with the addition of the PS > arguments). For the load-balancing part yes. And the rest depends on how realistic the numa-selector is. > > count to 0 then. > > Or 1, meaning call the PS for every I/O. > (Strongly discouraged, unless it's just to gather statistics - > I'd expect a load balancer to want to vary this number each time.) > > 0 means don't call it again until the path has failed. You're right. I meant 1. For load-balancing I'd start with 32 or so. Stefan