#
303975 |
|
11-Aug-2016 |
gjb |
Copy stable/11@r303970 to releng/11.0 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, and rename it to RC1.
Update __FreeBSD_version.
Use the quarterly branch for the default FreeBSD.conf pkg(8) repo and the dvd1.iso packages population.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
302408 |
|
08-Jul-2016 |
gjb |
Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle. Prune svn:mergeinfo from the new branch, as nothing has been merged here.
Additional commits post-branch will follow.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
287277 |
|
29-Aug-2015 |
adrian |
Rename rss_soft_m2cpuid() -> rss_soft_m2cpuid_v4() in preparation for an IPv6 version to show up.
Submitted by: Tiwei Bie <btw@mail.ustc.edu.cn> Differential Revision: https://reviews.freebsd.org/D3504
|
#
277331 |
|
18-Jan-2015 |
adrian |
Refactor / restructure the RSS code into generic, IPv4 and IPv6 specific bits.
The motivation here is to eventually teach netisr and potentially other networking subsystems a bit more about how RSS work queues / buckets are configured so things have a hope of auto-configuring in the future.
* net/rss_config.[ch] takes care of the generic bits for doing configuration, hash function selection, etc; * topelitz.[ch] is now in net/ rather than netinet/; * (and would be in libkern if it didn't directly include RSS_KEYSIZE; that's a later thing to fix up.) * netinet/in_rss.[ch] now just contains the IPv4 specific methods; * and netinet/in6_rss.[ch] now just contains the IPv6 specific methods.
This should have no functional impact on anyone currently using the RSS support.
Differential Revision: D1383 Reviewed by: gnn, jfv (intel driver bits)
|
#
276484 |
|
31-Dec-2014 |
adrian |
Migrate the RSS IPv6 hash code to use pointers to the v6 addresses rather than passing them in by value.
The eventual aim is to do incremental hash construction rather than all of the memcpy()'ing into a contiguous buffer for the hash function, which does show up as taking quite a bit of CPU during profiling.
Tested:
* a variety of laptops/desktop setups I have, with v6 connectivity
Differential Revision: D1404 Reviewed by: bz, rpaulo
|
#
271297 |
|
09-Sep-2014 |
adrian |
Implement IPv4 RSS software hash functions to use during packet ingress and egress.
* rss_mbuf_software_hash_v4 - look at the IPv4 mbuf to fetch the IPv4 details + direction to calculate a hash. * rss_proto_software_hash_v4 - hash the given source/destination IPv4 address, port and direction. * rss_soft_m2cpuid - map the given mbuf to an RSS CPU ("bucket" for now)
These functions are intended to be used by the stack to support the following:
* Not all NICs do RSS hashing, so we should support some way of doing a hash in software; * The NIC / driver may not hash frames the way we want (eg UDP 4-tuple hashing when the stack is only doing 2-tuple hashing for UDP); so we may need to re-hash frames; * .. same with IPv4 fragments - they will need to be re-hashed after reassembly; * .. and same with things like IP tunneling and such; * The transmit path for things like UDP, RAW and ICMP don't currently have any RSS information attached to them - so they'll need an RSS calculation performed before transmit.
TODO:
* Counters! Everywhere! * Add a debug mode that software hashes received frames and compares them to the hardware hash provided by the hardware to ensure they match.
The IPv6 part of this is missing - I'm going to do some re-juggling of where various parts of the RSS framework live before I add the IPv6 code (read: the IPv6 code is going to go into netinet6/in6_rss.[ch], rather than living here.)
Note: This API is still fluid. Please keep that in mind.
Differential Revision: https://reviews.freebsd.org/D527 Reviewed by: grehan
|
#
268911 |
|
20-Jul-2014 |
adrian |
Implement rss_gethashconfig() - return the currently supported hash methods by the stack.
Right now the stack isn't really setup for RSS with 4-tuple UDP hashing for either IPv4 and IPv6.
The specifics:
* The UDP init path udp_init() and udplite_init() specify the hash as 2-tuple, so the PCBGROUPS code only tries a 2-tuple check; * The PCBGROUPS and RSS code doesn't know about the UDP hash types just yet, so they're never treated as valid hashes. * For correctness, 4-tuple can't be enabled in the general case because UDP datagrams can be more fragmented than IP datagrams may be.
Strictly speaking, TCP datagrams may also be fragmented and this could cause issues with PCBGROUPS/RSS until the IP defragment path grows some code to re-calculate the RSS hash.
I'll follow this commit up with awareness of the UDP 4-tuple for those who wish to configure it, but for now it'll stay disabled.
No drivers (yet) know to use this function when RSS is enabled.
|
#
267891 |
|
26-Jun-2014 |
adrian |
Add another RSS method to query the indirection table entries.
There's 128 indirection table entries which correspond to the low 7 bits of the 32 bit RSS hash. Each value will correspond to an RSS bucket. (Then each RSS bucket currently will map to a CPU.)
This is a more explicit way of figuring out which RSS bucket is in each RSS indirection slot. It can be inferred by the other methods but I'd rather drivers use something more simplified and explicit.
|
#
266737 |
|
27-May-2014 |
adrian |
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.
|
#
266419 |
|
18-May-2014 |
adrian |
Add a new function to do a CPU ID lookup based on RSS hash information.
This is intended to be used by various places that wish to hash some information about a TCP/UDP/IP flow but don't necessarily have a live mbuf to do it with.
Refactor rss_m2cpuid() to use the refactored function.
|
#
263198 |
|
15-Mar-2014 |
rwatson |
Several years after initial development, merge prototype support for linking NIC Receive Side Scaling (RSS) to the network stack's connection-group implementation. This prototype (and derived patches) are in use at Juniper and several other FreeBSD-using companies, so despite some reservations about its maturity, merge the patch to the base tree so that it can be iteratively refined in collaboration rather than maintained as a set of gradually diverging patch sets.
(1) Merge a software implementation of the Toeplitz hash specified in RSS implemented by David Malone. This is used to allow suitable pcbgroup placement of connections before the first packet is received from the NIC. Software hashing is generally avoided, however, due to high cost of the hash on general-purpose CPUs.
(2) In in_rss.c, maintain authoritative versions of RSS state intended to be pushed to each NIC, including keying material, hash algorithm/ configuration, and buckets. Provide software-facing interfaces to hash 2- and 4-tuples for IPv4 and IPv6 using both the RSS standardised Toeplitz and a 'naive' variation with a hash efficient in software but with poor distribution properties. Implement rss_m2cpuid()to be used by netisr and other load balancing code to look up the CPU on which an mbuf should be processed.
(3) In the Ethernet link layer, allow netisr distribution using RSS as a source of policy as an alternative to source ordering; continue to default to direct dispatch (i.e., don't try and requeue packets for processing on the 'right' CPU if they arrive in a directly dispatchable context).
(4) Allow RSS to control tuning of connection groups in order to align groups with RSS buckets. If a packet arrives on a protocol using connection groups, and contains a suitable hardware-generated hash, use that hash value to select the connection group for pcb lookup for both IPv4 and IPv6. If no hardware-generated Toeplitz hash is available, we fall back on regular PCB lookup risking contention rather than pay the cost of Toeplitz in software -- this is a less scalable but, at my last measurement, faster approach. As core counts go up, we may want to revise this strategy despite CPU overhead.
Where device drivers suitably configure NICs, and connection groups / RSS are enabled, this should avoid both lock and line contention during connection lookup for TCP. This commit does not modify any device drivers to tune device RSS configuration to the global RSS configuration; patches are in circulation to do this for at least Chelsio T3 and Intel 1G/10G drivers. Currently, the KPI for device drivers is not particularly robust, nor aware of more advanced features such as runtime reconfiguration/rebalancing. This will hopefully prove a useful starting point for refinement.
No MFC is scheduled as we will first want to nail down a more mature and maintainable KPI/KBI for device drivers.
Sponsored by: Juniper Networks (original work) Sponsored by: EMC/Isilon (patch update and merge)
|