[ofa-general] RE: installing 1.2-GA on Redhat EL5

Suresh Shelvapille suri at baymicrosystems.com
Wed Jul 25 11:04:14 PDT 2007


It was a space limitation issue, fixed it...thanks.


-Suri

> -----Original Message-----
> From: Doug Ledford [mailto:dledford at redhat.com]
> Sent: Wednesday, July 25, 2007 1:00 PM
> To: Suresh Shelvapille
> Cc: 'OpenIB'
> Subject: Re: installing 1.2-GA on Redhat EL5
> 
> On Wed, 2007-07-25 at 12:54 -0400, Suresh Shelvapille wrote:
> > Doug:
> >
> > I had ofed-1.2-rc1 installed on a server running redhat el5. I am trying to upgrade the
> > release to ofed-1.2-GA. The build finished and the install gives me this error:
> >
> >
> > --------------
> >
> > Installing OFED software into /usr/local/ofed_1.2
> >
> > Running /bin/rpm -ihv --force --nodeps
> > /root/ofed_1.2-GA/OFED-1.2-20070626-0917/RPMS/redhat-release-5Server-5.0.0.9/kernel-ib-1.2-
> 2.6.18_8.el5.x86_64.rpm
> > /root/ofed_1.2-GA/OFED-1.2-20070626-0917/RPMS/redhat-release-5Server-5.0.0.9/kernel-ib-devel-1.2-
> 2.6.18_8.el5.x86_64.rpm
> > |
> > ERROR: Failed executing "/bin/rpm -ihv --force --nodeps
> > /root/ofed_1.2-GA/OFED-1.2-20070626-0917/RPMS/redhat-release-5Server-5.0.0.9/kernel-ib-1.2-
> 2.6.18_8.el5.x86_64.rpm
> > /root/ofed_1.2-GA/OFED-1.2-20070626-0917/RPMS/redhat-release-5Server-5.0.0.9/kernel-ib-devel-1.2-
> 2.6.18_8.el5.x86_64.rpm
> > "
> >
> > -------------------
> >
> > Any ideas...
> 
> Not from this output.  I would need the actual rpm error messages to
> know what's wrong.  Try running the above rpm command by hand and
> copy-n-pasting the errors.
> 
> >
> > Thanks,
> > Suri
> >
> >
> > > -----Original Message-----
> > > From: general-bounces at lists.openfabrics.org [mailto:general-bounces at lists.openfabrics.org] On
> Behalf
> > > Of Sean Hefty
> > > Sent: Monday, July 23, 2007 8:23 PM
> > > To: Yevgeny Kliteynik
> > > Cc: OpenIB
> > > Subject: Re: [ofa-general] QoS RFC
> > >
> > > > 2.5. ULPs that use CM interface (like SRP) should have their own
> > > > pre-assigned Service-ID and use it while obtaining PR/MPR for
> > > > establishing connections. The SA receiving the PR/MPR should match it
> > > > against the policy and return the appropriate PR/MPR including SL,
> > > > MTU and RATE.
> > >
> > > We need to ensure that this can work without pre-assigned service IDs,
> > > or at least service IDs that are assigned within a fairly wide range,
> > > such as locally assigned IDs.
> > >
> > > > 2.6. ULPs and programs using CMA to establish RC connection should
> > > > provide the CMA the target IP and Service-ID. Some of the ULPs might
> > > > also provide QoS-Class (E.g. for SDP sockets that are provided the
> > > > TOS socket option). The CMA should then use the provided Service-ID
> > > > and optional QoS-Class and pass them in the PR/MPR request. The
> > > > resulting PR/MPR should be used for configuring the connection QP.
> > >
> > > The interface to the CMA needs to remain as transport independent as
> > > possible, and I am unsure of the transport independence of tying QoS to
> > > the destination port number.  (I'm not disagreeing; I'm just not sure at
> > > the moment it's the right approach.)
> > >
> > > > PathRecord and MultiPathRecord enhancement for QoS: As mentioned
> > > > above the PathRecord and MultiPathRecord attributes should be
> > > > enhanced to carry the Service-ID which is a 64bit value, which has
> > > > been standardized by the IBTA. A new field QoS-Class is also
> > > > provided. A new capability bit should describe the SM QoS support in
> > > > the SA class port info. This approach provides an easy migration path
> > > > for existing access layer and ULPs by not introducing new set of
> > > > PR/MPR attribute.
> > >
> > > Has any thought been given to how to make this scale?
> > >
> > > > 5. CMA features ----------------
> > > >
> > > > The CMA interface supports Service-ID through the notion of port
> > > > space as a prefixes to the port_num which is part of the sockaddr
> > > > provided to rdma_resolve_add(). What is missing is the explicit
> > > > request for a QoS-Class that should allow the ULP (like SDP) to
> > > > propagate a specific request for a class of service. A mechanism for
> > > > providing the QoS-Class is available in the IPv6 address, so we could
> > > > use that address field. Another option is to implement a special
> > > > connection options API for CMA.
> > > >
> > > > Missing functionality by CMA is the usage of the provided QoS-Class
> > > > and Service-ID in the sent PR/MPR. When a response is obtained it is
> > > > an existing requirement for the CMA to use the PR/MPR from the
> > > > response in setting up the QP address vector.
> > >
> > > The most natural function to specify additional QoS parameters would be
> > > rdma_resolve_route.
> > >
> > > - Sean
> > > _______________________________________________
> > > general mailing list
> > > general at lists.openfabrics.org
> > > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
> > >
> > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
> --
> Doug Ledford <dledford at redhat.com>
>               GPG KeyID: CFBFF194
>               http://people.redhat.com/dledford
> 
> Infiniband specific RPMs available at
>               http://people.redhat.com/dledford/Infiniband




More information about the general mailing list