<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Or Gerlitz wrote:
<blockquote cite="mid:48FEE7BF.2020604@voltaire.com" type="cite">
<pre wrap="">Bob Noseworthy wrote:
</pre>
<blockquote type="cite">
<pre wrap="">A bug for the observed IPoIB issue was logged last Friday, and
updated yesterday confirming that RC3 still demonstrates the issue.
This is logged as <a class="moz-txt-link-freetext" href="https://bugs.openfabrics.org/show_bug.cgi?id=1287">https://bugs.openfabrics.org/show_bug.cgi?id=1287</a>
Further issues/observations from the recent OFA Interoperability Logo
Group's September Interoperability Event are at the end of this
email. Summary of reported IPoIB issue: If IPoIB datagram mode is
enabled, and IP frames of 8K or larger are sent, and no ARP entry
exists for the destination, then the first IP frame is always lost
(ping used), no matter what the timeout is set to (as high as 15s)
</pre>
</blockquote>
<pre wrap=""><!---->Looking in the code, the issue you report seems to be related to the
length of internal queue used by ipoib to keep skbs whose neighbour
doesn't have yet an IB Address-Handle (L2 info needed for xmit)
associated with
</pre>
<blockquote type="cite">
<pre wrap="">drivers/infiniband/ulp/ipoib/ipoib.h: IPOIB_MAX_PATH_REC_QUEUE = 3,
drivers/infiniband/ulp/ipoib/ipoib_main.c if (skb_queue_len(&neigh->queue) < IPOIB_MAX_PATH_REC_QUEUE)
drivers/infiniband/ulp/ipoib/ipoib_main.c: skb_queue_len(&path->queue) < IPOIB_MAX_PATH_REC_QUEUE) {
drivers/infiniband/ulp/ipoib/ipoib_main.c: if (skb_queue_len(&neigh->queue) < IPOIB_MAX_PATH_REC_QUEUE)
</pre>
</blockquote>
<pre wrap=""><!---->the current code will keep up to three skbs and then drop all the ones
that follows till the point in time a reply for the driver path query is
received from the SA. Unless I miss something, this code is there from
day one (Q4/2005), do you claim that with older code drops this issue
has not been observed? I am cc-ing here Roland, the maintainer of the
driver, so you can check things with him.
</pre>
</blockquote>
Our cluster is a constantly evolving system, along with the software,
test plan and just about anything else you can think of can and will
change. So there is no claim that this problem did or did not exist in
previous events.<br>
<blockquote cite="mid:48FEE7BF.2020604@voltaire.com" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">The following is a short summary of various updates from the September
OpenFabrics Interoperability Event. Due to confidentiality reasons,
many details are occluded. Per the request of the IWG on Oct 14, this
information is being shared with the EWG.
Testing is ongoing with RC3 and future 1.4RCs on a best effort basis
until the GA, at which time the Logo Event will be held for those
participating. If you have additional questions about these
comments, the Interoperability Events, Logo Events, or the OFA
Interoperability Test Plan, please feel free to contact us here at UNH-IOL
</pre>
</blockquote>
<pre wrap=""><!---->May I ask whose decision was it to test the Linux kernel RDMA stack in
its "ofed" flavor and what was the reasonings behind it? the main-line
kernel IB/iWARP code is well maintained and has an associated small
supporting developer community. The ofed kernel bits contain code which
was not accepted yet to the upstream kernel so you are actually testing
not the product delivered by the ofa maintainers but rather a different
creature, are you aware to that?
</pre>
</blockquote>
We are tangentially aware of some loose relationship between the kernel
and OFED and how they can not be entirely in sync. However, since its
inception the IWG and logo group has focused efforts on running OFED
releases. If the EWG thinks that this should be modified to utilize
the latest kernel as opposed to OFED we can certainly propose it to the
IWG group and change our operating procedures accordingly. The main
point of the logo program is to test and verify open fabrics SS in the
environment that customers will be mostly utilizing, at least
anecdotally, conversations that I have had and overheard all indicate
that customers run RHEL or SLES out of the box and push the latest OFED
release on their roll-outs.<br>
<blockquote cite="mid:48FEE7BF.2020604@voltaire.com" type="cite">
<pre wrap="">
Or.
_______________________________________________
Ofalab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ofalab@postal.iol.unh.edu">Ofalab@postal.iol.unh.edu</a>
<a class="moz-txt-link-freetext" href="https://postal.iol.unh.edu/mailman/listinfo/ofalab">https://postal.iol.unh.edu/mailman/listinfo/ofalab</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">Mikkel Hagen
Project Assistant - Fibre Channel/SAS/SATA Consortiums
Research and Development Engineer - iWARP Consortium
FC/SAS/SATA:1-603-862-0701 iWARP:1-603-862-5083 Fax:1-603-862-4181
UNH-IOL
121 Technology Drive, Suite 2
Durham, NH 03824
</pre>
<br>
</body>
</html>