<br><tt><font size=2>"Michael S. Tsirkin" <mst@mellanox.co.il>
wrote on 12/16/2006 12:03:28 PM:<br>
<br>
> > > > ><br>
> > > > > Tried this patch, it didn't work on ehca. I couldn't
change <br>
> the mode from<br>
> > > > > datagram to connected from /sys/class.<br>
> > > ><br>
> > > > It's wroking as designed in that respect.  ehca
does not implement<br>
> > > > srq - without<br>
> > > > srq, there is no way to prepost receive buffers for
a <br>
> resonable number of<br>
> > > > connections without running out of memory.<br>
> > > ><br>
> > > > So it is falling back on datagram mode.<br>
> > > > Talk to ehca guys to implement srq and connected mode
will be enabled.<br>
> > > Don't remember SRQ is a MUST for UC mode. Does this patch
support<br>
> > > devices with SRQ in RC mode?<br>
> > <br>
> > I don't think the IB HCA Spec requires SRQ support for RC but
is an optional<br>
> > feature. There are two adapters right now that don't support
SRQ <br>
> which means to<br>
> > use IPoIB-CM on them you should make the use of SRQ an option
setting.<br>
> <br>
> No, adding such "drink up all memory on real clusters but run
well <br>
> on a back to back<br>
> benchmark platform" option does not seem like a good idea to
me.<br>
> Rather, we should use UD mode to keep IPoIB scalable on all hardware.</font></tt>
<br>
<br><tt><font size=2>I agree that adapters that don't have SRQ can consume
larger amounts of memory than those with SRQ ,however, that is not a good
reason to prevent usage of RC or UC on those adapters. The memory consumption
problem with any protocol not using SRQ and running over RC or UC is well
documented. At the OpenFabrics meeting in Tampa one of several themes was
that we need better IP performance to move into commercial customers and
also help our current primarily HPC customers, some which are not large
numbers of endpoints configurations. Even thought other ULP's are available,
good IP is still the opportunity to getting more customers on IB. </font></tt>
<br>
<br><tt><font size=2>Not all IB customers we have a large number of endpoint
deployments so having non SRQ adapters use IPoIB-CM is still important
to expanding the customer base for IB. You have to let the customer decide
how they want to tune their system based on the available functions/features.
If not you don't have equality in potential performance across all HCA's.
Some guidance on memory consumption would be good, to guide users whether
they want to run IPoIB-CM without SRQ just like IPoIB-CM will be selectable.</font></tt>
<br><tt><font size=2><br>
> <br>
> > I agree<br>
> > that if it is available it should be used for scaling issues
probably if<br>
> > available automatically set. But I would like to see us at least
support the<br>
> > current hardware that meets the current SPEC.<br>
> <br>
> SRQ support is clearly optional. But neither is IPoIB CM support a
required<br>
> feature. Current code will fall back to datagram mode when SRQ is
not<br>
> supported, and since UD support in not optional, all current hardware
is still<br>
> supported with IPoIB - this patch does not break this.<br>
> <br>
> -- <br>
> MST<br>
</font></tt>
<br><font size=2 face="sans-serif"><br>
Bernie King-Smith  <br>
IBM Corporation<br>
Server Group<br>
Cluster System Performance  <br>
wombat2@us.ibm.com    (845)433-8483<br>
Tie. 293-8483 or wombat2 on NOTES <br>
<br>
"We are not responsible for the world we are born into, only for the
world we leave when we die.<br>
So we have to accept what has gone before us and work to change the only
thing we can,<br>
-- The Future." William Shatner</font>
<br>