Re: [ofa-general] Re: [RFC] OpenSM and IPv6 Scalability Proposal
On Sat, May 09, 2009 at 01:32:06PM +0300, Eli Dorfman wrote: On Fri, May 8, 2009 at 4:57 PM, Hal Rosenstock hal.rosenst...@gmail.com wrote: On Wed, May 6, 2009 at 6:24 AM, Slava Strebkov sla...@voltaire.com wrote: In addition to the original proposal we suggest allocating special MLID for the following MGIDs: ??1. FF12401b - All Nodes ??2. FF12401b0001 - All hosts ??3. FF12401b004d ??- all Gateways ??4. FF12401b0002 - all routers ??5. FF12601bABCD0001ffxx - IPv6 SNM It turns out that collapsing multicast groups across PKeys on a single MLID may not be such a good idea unless partition enforcement enforcement by switches is disabled. There should be different modes of collapsing based on this based on whether this is enabled or not. The idea is to allocate a different MLID per each of the above special MGIDs. In practice I think you'd be better to combine the All Nodes, All hosts, All Gatesways, All Routers and IPv4 broadcast group onto a single MLID and then distribute the SNM groups over some number of additional MLIDs in an intelligent manner. The specialty groups are not really used very much, while the purpose of the SNM group is for ND scalability. If your network is large enough to care about this then it is probably also large enough to benefit from multiple SNM groups.. Otherwise, you may as well lump them all together into the broadcast MLID. Jason ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: [RFC] OpenSM and IPv6 Scalability Proposal
On Fri, May 8, 2009 at 4:57 PM, Hal Rosenstock hal.rosenst...@gmail.com wrote: On Wed, May 6, 2009 at 6:24 AM, Slava Strebkov sla...@voltaire.com wrote: In addition to the original proposal we suggest allocating special MLID for the following MGIDs: 1. FF12401b - All Nodes 2. FF12401b0001 - All hosts 3. FF12401b004d - all Gateways 4. FF12401b0002 - all routers 5. FF12601bABCD0001ffxx - IPv6 SNM It turns out that collapsing multicast groups across PKeys on a single MLID may not be such a good idea unless partition enforcement enforcement by switches is disabled. There should be different modes of collapsing based on this based on whether this is enabled or not. The idea is to allocate a different MLID per each of the above special MGIDs. For all other cases we suggest that same MLID will be assigned to different MGIDs if: 1. They share the same P Key 2. Same signature - for IPoIB only 3. Same LSB bits - bitmask configurable by user (default 10 bits) for example, the following are the same: MGID1: FF12401bABCDx755 MGID2: FF12401bABCDyB55 Jason's approach to this was in a thread entitled IPv6 and IPoIB scalability issue: http://lists.openfabrics.org/pipermail/general/2006-November/029621.html in which he proposed an MGID range (MGID/prefix syntax) for collapsing IPv6 SNM groups. Additionally, there was the potential to distribute the matched groups across some number of MLIDs. See also thread [RFC] OpenSM and IPv6 Scalability Proposal: http://lists.openfabrics.org/pipermail/general/2008-June/051226.html Implementation. Since there will be many mgroups shared same mlid, mlid-array entry will contain fleximap holding mgroups. Searching of mgroup will be performed by mlid (index in the array) and mgid - key in the fleximap. Sasha proposed using an array rather than fleximap for this: http://lists.openfabrics.org/pipermail/general/2008-June/051525.html -- Hal Slava Strebkov ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: [RFC] OpenSM and IPv6 Scalability Proposal
On Sat, May 9, 2009 at 6:32 AM, Eli Dorfman dorfman@gmail.com wrote: On Fri, May 8, 2009 at 4:57 PM, Hal Rosenstock hal.rosenst...@gmail.com wrote: On Wed, May 6, 2009 at 6:24 AM, Slava Strebkov sla...@voltaire.com wrote: In addition to the original proposal we suggest allocating special MLID for the following MGIDs: 1. FF12401b - All Nodes 2. FF12401b0001 - All hosts 3. FF12401b004d - all Gateways 4. FF12401b0002 - all routers 5. FF12601bABCD0001ffxx - IPv6 SNM It turns out that collapsing multicast groups across PKeys on a single MLID may not be such a good idea unless partition enforcement enforcement by switches is disabled. There should be different modes of collapsing based on this based on whether this is enabled or not. The idea is to allocate a different MLID per each of the above special MGIDs. So one MLID per PKey in the MGID ? What's the difference between 's and ABCD in the syntax above ? IPv6 is being collapsed per PKey too, right ? For all other cases we suggest that same MLID will be assigned to different MGIDs if: 1. They share the same P Key 2. Same signature - for IPoIB only 3. Same LSB bits - bitmask configurable by user (default 10 bits) for example, the following are the same: MGID1: FF12401bABCDx755 MGID2: FF12401bABCDyB55 Jason's approach to this was in a thread entitled IPv6 and IPoIB scalability issue: http://lists.openfabrics.org/pipermail/general/2006-November/029621.html in which he proposed an MGID range (MGID/prefix syntax) for collapsing IPv6 SNM groups. Additionally, there was the potential to distribute the matched groups across some number of MLIDs. See also thread [RFC] OpenSM and IPv6 Scalability Proposal: http://lists.openfabrics.org/pipermail/general/2008-June/051226.html Implementation. Since there will be many mgroups shared same mlid, mlid-array entry will contain fleximap holding mgroups. Searching of mgroup will be performed by mlid (index in the array) and mgid - key in the fleximap. Sasha proposed using an array rather than fleximap for this: http://lists.openfabrics.org/pipermail/general/2008-June/051525.html -- Hal Slava Strebkov ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: [RFC] OpenSM and IPv6 Scalability Proposal
On Sat, May 9, 2009 at 1:41 PM, Hal Rosenstock hal.rosenst...@gmail.com wrote: On Sat, May 9, 2009 at 6:32 AM, Eli Dorfman dorfman@gmail.com wrote: On Fri, May 8, 2009 at 4:57 PM, Hal Rosenstock hal.rosenst...@gmail.com wrote: On Wed, May 6, 2009 at 6:24 AM, Slava Strebkov sla...@voltaire.com wrote: In addition to the original proposal we suggest allocating special MLID for the following MGIDs: 1. FF12401b - All Nodes 2. FF12401b0001 - All hosts 3. FF12401b004d - all Gateways 4. FF12401b0002 - all routers 5. FF12601bABCD0001ffxx - IPv6 SNM It turns out that collapsing multicast groups across PKeys on a single MLID may not be such a good idea unless partition enforcement enforcement by switches is disabled. There should be different modes of collapsing based on this based on whether this is enabled or not. The idea is to allocate a different MLID per each of the above special MGIDs. So one MLID per PKey in the MGID ? yes What's the difference between 's and ABCD in the syntax above ? none. should be the same. IPv6 is being collapsed per PKey too, right ? yes For all other cases we suggest that same MLID will be assigned to different MGIDs if: 1. They share the same P Key 2. Same signature - for IPoIB only 3. Same LSB bits - bitmask configurable by user (default 10 bits) for example, the following are the same: MGID1: FF12401bABCDx755 MGID2: FF12401bABCDyB55 Jason's approach to this was in a thread entitled IPv6 and IPoIB scalability issue: http://lists.openfabrics.org/pipermail/general/2006-November/029621.html in which he proposed an MGID range (MGID/prefix syntax) for collapsing IPv6 SNM groups. Additionally, there was the potential to distribute the matched groups across some number of MLIDs. See also thread [RFC] OpenSM and IPv6 Scalability Proposal: http://lists.openfabrics.org/pipermail/general/2008-June/051226.html Implementation. Since there will be many mgroups shared same mlid, mlid-array entry will contain fleximap holding mgroups. Searching of mgroup will be performed by mlid (index in the array) and mgid - key in the fleximap. Sasha proposed using an array rather than fleximap for this: http://lists.openfabrics.org/pipermail/general/2008-June/051525.html -- Hal Slava Strebkov ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: [RFC] OpenSM and IPv6 Scalability Proposal
On Sat, May 9, 2009 at 7:31 AM, Eli Dorfman dorfman@gmail.com wrote: On Sat, May 9, 2009 at 1:41 PM, Hal Rosenstock hal.rosenst...@gmail.com wrote: On Sat, May 9, 2009 at 6:32 AM, Eli Dorfman dorfman@gmail.com wrote: On Fri, May 8, 2009 at 4:57 PM, Hal Rosenstock hal.rosenst...@gmail.com wrote: On Wed, May 6, 2009 at 6:24 AM, Slava Strebkov sla...@voltaire.com wrote: In addition to the original proposal we suggest allocating special MLID for the following MGIDs: 1. FF12401b - All Nodes 2. FF12401b0001 - All hosts 3. FF12401b004d - all Gateways 4. FF12401b0002 - all routers 5. FF12601bABCD0001ffxx - IPv6 SNM It turns out that collapsing multicast groups across PKeys on a single MLID may not be such a good idea unless partition enforcement enforcement by switches is disabled. There should be different modes of collapsing based on this based on whether this is enabled or not. The idea is to allocate a different MLID per each of the above special MGIDs. So one MLID per PKey in the MGID ? yes What's the difference between 's and ABCD in the syntax above ? none. should be the same. Doesn't the xx for IPv6 mean mask these nibbles though ? IPv6 is being collapsed per PKey too, right ? yes For all other cases we suggest that same MLID will be assigned to different MGIDs if: 1. They share the same P Key 2. Same signature - for IPoIB only 3. Same LSB bits - bitmask configurable by user (default 10 bits) for example, the following are the same: MGID1: FF12401bABCDx755 MGID2: FF12401bABCDyB55 Jason's approach to this was in a thread entitled IPv6 and IPoIB scalability issue: http://lists.openfabrics.org/pipermail/general/2006-November/029621.html in which he proposed an MGID range (MGID/prefix syntax) for collapsing IPv6 SNM groups. Additionally, there was the potential to distribute the matched groups across some number of MLIDs. See also thread [RFC] OpenSM and IPv6 Scalability Proposal: http://lists.openfabrics.org/pipermail/general/2008-June/051226.html Implementation. Since there will be many mgroups shared same mlid, mlid-array entry will contain fleximap holding mgroups. Searching of mgroup will be performed by mlid (index in the array) and mgid - key in the fleximap. Sasha proposed using an array rather than fleximap for this: http://lists.openfabrics.org/pipermail/general/2008-June/051525.html -- Hal Slava Strebkov ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: [RFC] OpenSM and IPv6 Scalability Proposal
Hal Rosenstock wrote: On Sat, May 9, 2009 at 7:31 AM, Eli Dorfman dorfman@gmail.com wrote: On Sat, May 9, 2009 at 1:41 PM, Hal Rosenstock hal.rosenst...@gmail.com wrote: On Sat, May 9, 2009 at 6:32 AM, Eli Dorfman dorfman@gmail.com wrote: On Fri, May 8, 2009 at 4:57 PM, Hal Rosenstock hal.rosenst...@gmail.com wrote: On Wed, May 6, 2009 at 6:24 AM, Slava Strebkov sla...@voltaire.com wrote: In addition to the original proposal we suggest allocating special MLID for the following MGIDs: 1. FF12401b - All Nodes 2. FF12401b0001 - All hosts 3. FF12401b004d - all Gateways 4. FF12401b0002 - all routers 5. FF12601bABCD0001ffxx - IPv6 SNM It turns out that collapsing multicast groups across PKeys on a single MLID may not be such a good idea unless partition enforcement enforcement by switches is disabled. There should be different modes of collapsing based on this based on whether this is enabled or not. The idea is to allocate a different MLID per each of the above special MGIDs. So one MLID per PKey in the MGID ? yes What's the difference between 's and ABCD in the syntax above ? none. should be the same. Doesn't the xx for IPv6 mean mask these nibbles though ? For IPv6 the ABCD is the pkey and xx is the mask To make it the same as IPv4 groups we can use the following notation (mm=mask and =pkey) FF12601b0001ffmm ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [ofa-general] Re: [RFC] OpenSM and IPv6 Scalability Proposal
-Original Message- From: Hal Rosenstock [mailto:hal.rosenst...@gmail.com] Sent: Friday, May 08, 2009 4:58 PM To: Slava Strebkov Cc: general@lists.openfabrics.org Subject: Re: [ofa-general] Re: [RFC] OpenSM and IPv6 Scalability Proposal On Wed, May 6, 2009 at 6:24 AM, Slava Strebkov sla...@voltaire.com wrote: In addition to the original proposal we suggest allocating special MLID for the following MGIDs: 1. FF12401b - All Nodes 2. FF12401b0001 - All hosts 3. FF12401b004d - all Gateways 4. FF12401b0002 - all routers 5. FF12601bABCD0001ffxx - IPv6 SNM It turns out that collapsing multicast groups across PKeys on a single MLID may not be such a good idea unless partition enforcement enforcement by switches is disabled. There should be different modes of collapsing based on this based on whether this is enabled or not. For all other cases we suggest that same MLID will be assigned to different MGIDs if: 1. They share the same P Key 2. Same signature - for IPoIB only 3. Same LSB bits - bitmask configurable by user (default 10 bits) for example, the following are the same: MGID1: FF12401bABCDx755 MGID2: FF12401bABCDyB55 Jason's approach to this was in a thread entitled IPv6 and IPoIB scalability issue: http://lists.openfabrics.org/pipermail/general/2006-November/029621.html in which he proposed an MGID range (MGID/prefix syntax) for collapsing IPv6 SNM groups. Additionally, there was the potential to distribute the matched groups across some number of MLIDs. See also thread [RFC] OpenSM and IPv6 Scalability Proposal: http://lists.openfabrics.org/pipermail/general/2008-June/051226.html Implementation. Since there will be many mgroups shared same mlid, mlid-array entry will contain fleximap holding mgroups. Searching of mgroup will be performed by mlid (index in the array) and mgid - key in the fleximap. Sasha proposed using an array rather than fleximap for this: http://lists.openfabrics.org/pipermail/general/2008-June/051525.html We propose MLID -indexed array, but instead of list of pointers to multicast groups, there will be fleximap sorted by MGID. This is faster than simple list. Slava -- Hal Slava Strebkov ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: [RFC] OpenSM and IPv6 Scalability Proposal
On Wed, May 6, 2009 at 6:24 AM, Slava Strebkov sla...@voltaire.com wrote: In addition to the original proposal we suggest allocating special MLID for the following MGIDs: 1. FF12401b - All Nodes 2. FF12401b0001 - All hosts 3. FF12401b004d - all Gateways 4. FF12401b0002 - all routers 5. FF12601bABCD0001ffxx - IPv6 SNM It turns out that collapsing multicast groups across PKeys on a single MLID may not be such a good idea unless partition enforcement enforcement by switches is disabled. There should be different modes of collapsing based on this based on whether this is enabled or not. For all other cases we suggest that same MLID will be assigned to different MGIDs if: 1. They share the same P Key 2. Same signature - for IPoIB only 3. Same LSB bits - bitmask configurable by user (default 10 bits) for example, the following are the same: MGID1: FF12401bABCDx755 MGID2: FF12401bABCDyB55 Jason's approach to this was in a thread entitled IPv6 and IPoIB scalability issue: http://lists.openfabrics.org/pipermail/general/2006-November/029621.html in which he proposed an MGID range (MGID/prefix syntax) for collapsing IPv6 SNM groups. Additionally, there was the potential to distribute the matched groups across some number of MLIDs. See also thread [RFC] OpenSM and IPv6 Scalability Proposal: http://lists.openfabrics.org/pipermail/general/2008-June/051226.html Implementation. Since there will be many mgroups shared same mlid, mlid-array entry will contain fleximap holding mgroups. Searching of mgroup will be performed by mlid (index in the array) and mgid - key in the fleximap. Sasha proposed using an array rather than fleximap for this: http://lists.openfabrics.org/pipermail/general/2008-June/051525.html -- Hal Slava Strebkov ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: [RFC] OpenSM and IPv6 Scalability Proposal
Hi Sasha, On Mon, 2008-06-16 at 09:39 +0300, Sasha Khapyorsky wrote: Hi Hal, On 06:03 Sat 07 Jun , Hal Rosenstock wrote: 1. Change the current underlying multicast tree from being MLID based to MGID based. This involves using fleximap rather than qmap. The downside of this is that MLID lookups will be slower as now they are not as direct as the MLID will no longer be the key in the map. Rather than searching by MLID key, the tree will need to be scanned entry by entry for MLID matches. Actually it is not necessary to slow down there. Instead of mgrp_mlid_tbl and in addition to MGID map we can just keep array of pointers to existing multicast groups indexed by MLID offset from 0xc000. It will be always limited in size and should be even faster than original quick map. Is a 16K array of pointers preferable to some map ? It's unclear how much this will slow down MLID searches but it is thought that none of these searches are time critical (and shouldn't cause any existing timeouts to pop). Some searches are on a fast paths. I think it is important to not slow down there. The comment was at a fine not coarse level. There was some minor additions thought to be in the code path. 2. Add in support for overloading MLIDs. On the configuration side, a number of additional options would be added to consolidate_ipv6_snm_req. These include the number of MLIDs to compress down to (default 16), a multicast group (MGID) base address and (full MGID) mask. this would default to 0xff1Z601b : 0x0001ffYY where Z is the scope, is the P_Key, and YY is the last 24 bits of the port guid ( the YY bits would be masked out by default). This is what the current workaround uses for collapsing the multicast groups. The criteria for overloading MLIDs includes any group parameters that need to be in common (e.g. rate. MTU, perhaps PKey (see below), etc.). Aside from changing the underlying implementation of MLID searches, multicast group deletion wll need another check when there are no ports left in a group. If that group is on a compressed MLID (this part of the check is an optimization), then the multicast group tree needs to be checked to ensure there are no other groups sharing that MLID. If we will have MLID indexed array with pointers to multicast groups kept in a list it should be easy to do. Something like: i: (MLID = 0xc000 + i) - MGRP MGID1 - MGRP MGID2 - ... That's how I envisioned the mgrp_mlid_tbl changing. It would point at an MLID and a MGID chain rather than an individual MGID. IBA 1.2.1 v1 p.151 4.1.3 Local Identifiers item 10) states: When a multicast LID is overloaded, the multicast groups sharing the same MLID must have the same P_Key. This simplification is required to allow switches and routers that implement optional P_Key enforcement for multicast operations. This is part of the C4-5 compliance. OPEN ISSUE As PKey is part of the MGID, does this need to be addressed (and if so) how ? Since it is required by spec It's unclear the spec is right in this. and we want to care about another common multicast parameters (mtu, rate, etc.) pkey can be handled in similar manner. Yes, it's potentially just another parameter for the sharing eligibility. In worst case we can disable/enable it with command line option or so. I was hoping that isn't needed. -- Hal If the approach above seems reasonable, I will work on such a set of patches. Great! Sasha ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: [RFC] OpenSM and IPv6 Scalability Proposal
On 07:01 Mon 16 Jun , Hal Rosenstock wrote: Is a 16K array of pointers preferable to some map ? I would think so, but didn't check deeply. And in fact actual size of such array can be limited by max supported number of MLIDs in a fabric (which is just 1K today). Sasha ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: [RFC] OpenSM and IPv6 Scalability Proposal
On 07:48 Mon 16 Jun , Hal Rosenstock wrote: I would think so, but didn't check deeply. And in fact actual size of such array can be limited by max supported number of MLIDs in a fabric Is that really a good idea to limit it in this way ? Guess it could be limited with some configurable option but even so if a device with a larger MFT comes along then the SM might not work. I meant something else - any multicast stuff will be processed in SM after initial subnet discovery, so it is not a big problem to detect max needed array size in run-time. OTOH 16K for MLIDs is not a so big deal, I would not bother with such optimization unless would explicitly need this. Sasha ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: [RFC] OpenSM and IPv6 Scalability Proposal
On Mon, 2008-06-16 at 18:07 +0300, Sasha Khapyorsky wrote: On 07:48 Mon 16 Jun , Hal Rosenstock wrote: I would think so, but didn't check deeply. And in fact actual size of such array can be limited by max supported number of MLIDs in a fabric Is that really a good idea to limit it in this way ? Guess it could be limited with some configurable option but even so if a device with a larger MFT comes along then the SM might not work. I meant something else - any multicast stuff will be processed in SM after initial subnet discovery, so it is not a big problem to detect max needed array size in run-time. Isn't a similar thing done in terms of unicast ? OTOH 16K for MLIDs is not a so big deal, I would not bother with such optimization unless would explicitly need this. OK with me; I would think such an optimization is a minor change anyhow. -- Hal Sasha ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: [RFC] OpenSM and IPv6 Scalability Proposal
On Mon, 2008-06-16 at 18:07 +0300, Sasha Khapyorsky wrote: I meant something else - any multicast stuff will be processed in SM after initial subnet discovery, so it is not a big problem to detect max needed array size in run-time. This already exists: max_multicast_lid_ho -- Hal ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: [RFC] OpenSM and IPv6 Scalability Proposal
On 08:26 Mon 16 Jun , Hal Rosenstock wrote: On Mon, 2008-06-16 at 18:07 +0300, Sasha Khapyorsky wrote: On 07:48 Mon 16 Jun , Hal Rosenstock wrote: I would think so, but didn't check deeply. And in fact actual size of such array can be limited by max supported number of MLIDs in a fabric Is that really a good idea to limit it in this way ? Guess it could be limited with some configurable option but even so if a device with a larger MFT comes along then the SM might not work. I meant something else - any multicast stuff will be processed in SM after initial subnet discovery, so it is not a big problem to detect max needed array size in run-time. Isn't a similar thing done in terms of unicast ? Yes, with cl_vector*() and it is *slow*. Sasha ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: [RFC] OpenSM and IPv6 Scalability Proposal
On 08:33 Mon 16 Jun , Hal Rosenstock wrote: This already exists: max_multicast_lid_ho Right. Sasha ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: [RFC] OpenSM and IPv6 Scalability Proposal
On Mon, 2008-06-16 at 18:51 +0300, Sasha Khapyorsky wrote: On 08:26 Mon 16 Jun , Hal Rosenstock wrote: On Mon, 2008-06-16 at 18:07 +0300, Sasha Khapyorsky wrote: On 07:48 Mon 16 Jun , Hal Rosenstock wrote: I would think so, but didn't check deeply. And in fact actual size of such array can be limited by max supported number of MLIDs in a fabric Is that really a good idea to limit it in this way ? Guess it could be limited with some configurable option but even so if a device with a larger MFT comes along then the SM might not work. I meant something else - any multicast stuff will be processed in SM after initial subnet discovery, so it is not a big problem to detect max needed array size in run-time. Isn't a similar thing done in terms of unicast ? Yes, with cl_vector*() and it is *slow*. If 16K array of pointers is OK, is a 48K array ? If so, then this should be straightforward to change. -- Hal Sasha ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: [RFC] OpenSM and IPv6 Scalability Proposal
On 09:06 Mon 16 Jun , Hal Rosenstock wrote: If 16K array of pointers is OK, is a 48K array ? If so, then this should be straightforward to change. Looks like a good idea for me. Sasha ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: [RFC] OpenSM and IPv6 Scalability Proposal
On Mon, 2008-06-16 at 19:08 +0300, Sasha Khapyorsky wrote: On 09:06 Mon 16 Jun , Hal Rosenstock wrote: If 16K array of pointers is OK, is a 48K array ? If so, then this should be straightforward to change. Looks like a good idea for me. It would need to be based on min of the switch LFT sizes rather than max LID in use/persistent as it is now. Also, max_unicast_lid_ho similar to max_multicast_lid_ho exists and is supported now so the actual max optimization could be applied although from a practical standpoint this doesn't have any benefit in most if not all subnets (whereas the multicast arch max is not currently implemented). -- Hal Sasha ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: [RFC] OpenSM and IPv6 Scalability Proposal
On Sun, 2008-06-08 at 08:02 -0700, Hal Rosenstock wrote: In terms of IB routers, if an MLID was overloaded, wouldn't they filter on scope as well (link local scope would be filtered), right ? Should have said not forward rather than filter on link local scope as these might be locally terminated on the router. -- Hal ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
