The users of RSS shouldn't be directly concerned about hash -> CPU ID

mappings.  Instead, they should be first mapping to an RSS bucket and
then querying the RSS bucket -> CPU ID mapping to figure out the target
CPU.

When (if?) RSS rebalancing is implemented or some other (non round-robin)
distribution of work from buckets to CPU IDs, various bits of code - both
userland and kernel - will need to know how this mapping works.

So, to support this:

* Add a new function rss_m2bucket() - this maps an mbuf to a given bucket.
  Anything which is currently doing hash -> CPU work may instead wish to
  do hash -> bucket, and then query the bucket->cpuid map for which
  CPU it belongs on.  Or, map it to a bucket, then re-pin that bucket ->
  CPU during a rebalance operation.

* For userland applications which wish to exploit affinity to RSS buckets,
  the bucket -> CPU ID mapping is now available via a sysctl.
  net.inet.rss.bucket_mapping lists the bucket to CPU ID mapping via
  a list of bucket:cpu pairs.

1 files changed, 3 insertions, 0 deletions

diff --git a/sys/netinet/in_rss.h b/sys/netinet/in_rss.h
index e431270..0ee704b 100644
--- a/sys/netinet/in_rss.h
+++ b/sys/netinet/in_rss.h
@@ -91,5 +91,8 @@ uint32_t	rss_hash_ip6_2tuple(struct in6_addr src,
  */
 struct mbuf	*rss_m2cpuid(struct mbuf *m, uintptr_t source, u_int *cpuid);
 u_int		rss_hash2cpuid(uint32_t hash_val, uint32_t hash_type);
+int		rss_hash2bucket(uint32_t hash_val, uint32_t hash_type,
+		uint32_t *bucket_id);
+int		rss_m2bucket(struct mbuf *m, uint32_t *bucket_id);
 
 #endif /* !_NETINET_IN_RSS_H_ */