<html>
<body>
<font size=3><br>
Just to make this clear:<br><br>
- There are only two QP that are defined with specific intention - QP0
and QP1. All other QP may vary throughout the entire QP
space. <br><br>
- All ULP built on top of IB must assume that the QP are variant and must
discover these through various protocol such as the service ID protocol
or for IPoIB, the ARP / ND exchange.<br><br>
- Multiple QP may be used for a given service allowing both finer grain
partitioning as well as scaling opportunities.<br><br>
So, this isn't something open to debate. It is how we designed the
technology to allow flexibility and performance.<br><br>
Mike<br><br>
<br><br>
At 08:17 AM 3/5/2005, Hal Rosenstock wrote:<br>
<blockquote type=cite class=cite cite="">On Sat, 2005-03-05 at 10:22,
David M. Brean wrote:<br>
> There is an I-D for DHCP on IB. IPoIB defines a
"broadcast" address and <br>
> DHCP (and ARP) on IB use it. Could make RARP work using this
mechanism, <br>
> but as someone else pointed out, the IB hardware address contains a
<br>
> QPN. The I-D for IPoIB says something like:<br>
> <br>
> The link-layer address for IPoIB includes
the QPN which might not be<br>
> constant across reboots or even across
network interface resets.<br>
> Cached QPN entries, such as in static ARP
entries or in RARP servers<br>
> will only work if the implementation(s)
using these options ensure<br>
> that the QPN associated with an interface is
invariant across<br>
> reboots/network resets.<br><br>
That may be the requirement but I think there are some issues with<br>
keeping the QPN invariant. Quoting Dror Goldenberg<br>
(<a href="http://openib.org/pipermail/openib-general/2004-November/006765.html" eudora="autourl">
http://openib.org/pipermail/openib-general/2004-November/006765.html</a>
):<br>
"Assigning specific QPN for ipoib requires allocation of QPN space
which<br>
is beyond IB spec verbs. Current verbs do not allow it. I don't have
any<br>
objection for that, except that you have to hold a set of
preallocated<br>
QPs with specific numbers and hand them over to privileged consumer
when<br>
requested to. I wouldn't commit that it will work on any HCA<br>
architecture."<br><br>
-- Hal<br><br>
<br>
> <br>
> So, there are requirements on the IPoIB implementation to make RARP
<br>
> work. Folks in the IPoIB work group decided not to go much
further than <br>
> these statements for RARP support since most folks felt that DHCP is
(de <br>
> facto) replacement.<br>
> <br>
> -David<br>
> <br>
> <br>
> >-- greg<br>
> ><br>
> ><br>
> >_______________________________________________<br>
> >openib-general mailing list<br>
> >openib-general@openib.org<br>
>
><a href="http://openib.org/mailman/listinfo/openib-general" eudora="autourl">
http://openib.org/mailman/listinfo/openib-general</a><br>
> ><br>
> >To unsubscribe, please visit
<a href="http://openib.org/mailman/listinfo/openib-general" eudora="autourl">
http://openib.org/mailman/listinfo/openib-general</a><br>
> > <br>
> ><br>
> <br>
> _______________________________________________<br>
> openib-general mailing list<br>
> openib-general@openib.org<br>
>
<a href="http://openib.org/mailman/listinfo/openib-general" eudora="autourl">
http://openib.org/mailman/listinfo/openib-general</a><br>
> <br>
> To unsubscribe, please visit
<a href="http://openib.org/mailman/listinfo/openib-general" eudora="autourl">
http://openib.org/mailman/listinfo/openib-general</a><br><br>
_______________________________________________<br>
openib-general mailing list<br>
openib-general@openib.org<br>
<a href="http://openib.org/mailman/listinfo/openib-general" eudora="autourl">
http://openib.org/mailman/listinfo/openib-general</a><br><br>
To unsubscribe, please visit
<a href="http://openib.org/mailman/listinfo/openib-general" eudora="autourl">
http://openib.org/mailman/listinfo/openib-general</a>
</font></blockquote></body>
</html>