[PATCH v3 0/4] sunrpc: hardcode pool_mode to pernode, remove other modes

The second patch is basically the same as v2, aside from some changes
that Neil suggested.

The other three patches address what is a shortcoming of the existing
code -- namely that the server can be configured to schedule RPCs to
pools with no threads in them. The first patch addresses this problem:
if the chosen pool has no threads, then choose another that does.

The third patch tries to prevent this situation in the thread
auto-placement case by ensuring that each node has at least one thread.

The last patch is a performance micro-optimization. The old code used a
modulus (actually two) to determine the pool (and prevent potentially
overrunning the array). This trades that for a less cpu-intensive method
of finding the pool to use.

Signed-off-by: Jeff Layton <[email protected]>
---
Changes in v3:
- Add patch to ensure that we don't route requests to empty pools
- When auto-distributing threads, always create at least one thread per populated pool
- Use sysfs_match_string for the module parameter
- Reword deprecation printk to be more vague about removal
- Explicitly set m_count == 0 in svc_pool_map_get()
- Optimize svc_pool_for_cpu() by eliminating modulus ops
- Link to v2: https://lore.kernel.org/r/[email protected]

Changes in v2:
- Accept any previously-accepted setting for pool_mode
- Link to v1: https://lore.kernel.org/r/[email protected]

---
Jeff Layton (4):
      sunrpc: route to a populated pool in svc_pool_for_cpu()
      sunrpc: hardcode pool_mode to pernode, remove other modes
      sunrpc: guarantee a thread per CPU-bearing node when auto-distributing
      sunrpc: eliminate a modulus operation from the enqueueing codepath

 Documentation/admin-guide/kernel-parameters.txt |  20 +-
 net/sunrpc/svc.c                                | 281 +++++++-----------------
 2 files changed, 88 insertions(+), 213 deletions(-)
---
base-commit: f8eb95335cc219493427f976460cf4b7e9641e92
change-id: 20260423-sunrpc-pool-mode-3e6b56320dc4

Best regards,
-- 
Jeff Layton <[email protected]>