Hi all, In yesterday’s call, we discussed separating the current QMPI_Get_function call (that takes the current tool_id and an enum value to get the function in the call stack) into two function calls. The first would determine the next tool in the stack and the second would get the desired function for that tool. So they would look something like this: QMPI_Get_next_tool(int tool_id, int num_next_tools, int *next_tool_ids); QMPI_Get_tool_fn(int tool_id, enum QMPI_Functions_enum function_enum, void (*function_ptr)(void), QMPI_Context *context); However, as I went to implement that today, I realized that the reason this is a single function today is that not all tools implement all functions. So if you have a tool stack that looks like this: A - B - C and tools A and C intercept MPI_SEND and tool B does not, when tool A asks for the next tool to implement MPI_SEND, it should get back the function for tool C. Unfortunately, if we don’t ask for a specific function, MPI doesn’t have a way to figure out whether it should return B or C. So there’s two options here. 1) Keep the two functions combined. This makes it clear in the current, linear case which tool comes next. However, it doesn’t move us toward the potential future of having a mechanism (internal or external) to make dynamic decisions about the next tool. 2) Add an enum value to the QMPI_Get_next_tool function so it is only searching for tools that implement the particular function. This does complicate the search functionality a little bit more, but not significantly. The main drawback I see here is just the confusion of passing that enum value into both functions. If we’re not providing this decision functionality in QMPI v1, it’s weird that we have this placeholder for it now. However, that’s already true with the array of next tools that will always be 1, so maybe it’s not a big deal. I would imagine that 2 is the best option here to support the PnMPI use case, but I’m happy to hear feedback. Thanks, Wes