K 10
svn:author
V 6
adrian
K 8
svn:date
V 27
2014-05-27T08:06:20.195812Z
K 7
svn:log
V 1015
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.

END