<br><br>
<div><span class="gmail_quote">On 6/12/08, <b class="gmail_sendername">Hal Rosenstock</b> <<a href="mailto:hrosenstock@xsigo.com">hrosenstock@xsigo.com</a>> wrote:</span> 
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi Olga,<br><br>On Thu, 2008-06-12 at 09:46 +0300, Olga Shern wrote:<br>> Hi All,<br>><br>><br>><br>
> We have found something that seems like Infiniband Spec hole,<br><br>What's the spec hole ?</blockquote>
<div> </div>
<div>According to the Infiniband spec - partial member cannot "talk" with partial member only with full member.</div>
<div>Therefore if partial member sending MC packet - all other partial members of this partition will generate BAD PKEY trap.</div>
<div> It means that the behavior that we see is according to Infiniband Spec - but very problematic</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> This issue is system issue that prevents from partial P_Key setup to<br>> go into production.<br><br>
Indeed :-(<br><br>> Short Setup & test description:<br>> ------------------------------------------<br>> * Node A: P_Key XXX (full member)<br>> * Node B, C, D, E, F: P_Key XXx (partial member)<br>><br>> 1. Send ping from B -> A : ping is OK<br>
> 2. Send ping from C -> A : ping is OK<br>> 3. Send ping from B -> C  : no ping also OK<br>> * Get traps Bad P_Key in SM - from all HCA in the fabric both for<br>> test 1 & 2 (one time) and also for test 3 (all the time).<br>
><br>> Probably the ARP request that is MC traffic generate the trap in HCA,<br>> for test 1<br>> & 2 we have only one ARP but for test 3 we send ARP all the time<br>> because<br>> we do not get any ARP reply.<br>
><br>> * The trap number SM get is 257 (HCA trap) if we will do P_Key<br>> switch enforcement we will probably get 259<br><br>Is this with OpenSM or VSM ?</blockquote>
<div> </div>
<div>We tested it with Voltaire SM but it should behave the same with OpenSM.</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">-- Hal<br><br>> * We get trap also from the originator of the MC traffic even<br>> though that receive switch relay error counter is increased (when out<br>
> port==in port), the switch does not drop the packet ?<br>><br>> Additional questions/issues:<br>> * Do we have a way to suppress port traps from SMA ?? i.e. that<br>> the port will not generate traps that can "kill the SM" - as its look<br>
> this is bug in the spec where we can't send any mc traffic (even ARP)<br>> when we have partial members and we do not have a way to suppress the<br>> traps.<br>><br>><br>> * What will happen in the HCA when we get many traps (mc packets<br>
> from many nodes) and they need to keep all events until SM will<br>> acknowledge?  - Is there limitation in the number of on-going<br>> traps (any HCA specific issues)?<br>><br>><br>><br>><br>><br>
> Best Regards<br>><br>> Olga<br>><br>><br>> _______________________________________________<br>> general mailing list<br>> <a href="mailto:general@lists.openfabrics.org">general@lists.openfabrics.org</a><br>
> <a href="http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general">http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general</a><br>><br>> To unsubscribe, please visit <a href="http://openib.org/mailman/listinfo/openib-general">http://openib.org/mailman/listinfo/openib-general</a><br>
<br>_______________________________________________<br>general mailing list<br><a href="mailto:general@lists.openfabrics.org">general@lists.openfabrics.org</a><br><a href="http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general">http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general</a><br>
<br>To unsubscribe, please visit <a href="http://openib.org/mailman/listinfo/openib-general">http://openib.org/mailman/listinfo/openib-general</a><br></blockquote></div><br>