Adrian Chadd 8bde802a2b 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.
2014-05-27 08:06:20 +00:00
..
2014-05-18 22:30:12 +00:00
2013-11-01 10:29:10 +00:00
2012-08-07 07:52:25 +00:00
2014-03-14 06:29:43 +00:00
2012-10-12 09:24:24 +00:00
In
2013-11-30 12:51:19 +00:00
2012-09-06 07:03:56 +00:00
2013-07-03 18:48:43 +00:00
2012-11-25 14:25:08 +00:00
2013-09-02 22:48:41 +00:00
2014-04-07 01:55:53 +00:00