Version: 1
-Previous: 2298069f16e71df0b1f49714294824dea0a70920
-Head: 15505ed4f343d65936a136feb16cc5265c3cb5af
+Previous: 63ba32d815bb8c31365613a40dc400207dcb3b33
+Head: 1c9cb4576f95c0d2cc7bf96d33cc6efe5f6c313d
Applied:
- opt_mc_av: a26b6e020fd54f16249125ed2fbf94bb93f7828e
- refresh-temp: 15505ed4f343d65936a136feb16cc5265c3cb5af
+ opt_mc_av: 1c9cb4576f95c0d2cc7bf96d33cc6efe5f6c313d
Unapplied:
addr_size: 8de02c47fbf595132105a7050ad6f755f49f9a7a
Hidden:
Author: Sean Hefty <sean.hefty@intel.com>
Date: 2011-04-01 14:46:34 -0700
-ibacm: Allocate address handles dynamically when needed
+ibacm: Reduce overhead on multicast groups not used
-ibacm allocates an address handle for every remote destination
-that it tracks. However, under normal operation, the handle
-is used infrequently - typically only once by the target
-service to send a response and not at all on the initiator
-service. Avoid the overhead of having 1 address handle per
-destination by allocating them dynamically only when they are needed.
-
-The exceptions to this are the address handles allocated to
-communicate with the SA and the primary multicast group.
+ACM may join several multicast groups when using the multicast
+group protocol. No data is ever sent on those groups. They exist
+simply to see if a port *could* send data across those groups, for
+example, to validate the mtu or rate between two endpoints. Since
+we don't send data on them, there's no need to create an address
+handle for them or attach the ACM UD QP to it.
Signed-off-by: Sean Hefty <sean.hefty@intel.com>
+++ /dev/null
-Bottom: ff1f0e0cc0c31d7a9b01b551462a6a3a0612e4b9
-Top: ff1f0e0cc0c31d7a9b01b551462a6a3a0612e4b9
-Author: Sean Hefty <sean.hefty@intel.com>
-Date: 2011-04-01 15:49:19 -0700
-
-Refresh of opt_mc_av
-
----
-
-