[openib-general] [RFC] OpenSM Interactive Console
Hal Rosenstock
halr at voltaire.com
Thu Oct 27 04:44:32 PDT 2005
There have been requests for this CLI functionality from at least the labs. It has been discussed on the list.
Also, there was the following comment in OpenSM::main.c:
/*
Sit here forever
In the future, some sort of console interactivity could
be implemented in this loop.
*/
-- Hal
________________________________
From: Eitan Zahavi [mailto:eitan at mellanox.co.il]
Sent: Thu 10/27/2005 2:03 AM
To: Hal Rosenstock; Eitan Zahavi
Cc: Troy Benjegerdes; openib-general at openib.org
Subject: RE: [openib-general] [RFC] OpenSM Interactive Console
Yes this MIB needs some cleanup.
I would love to hear from the community some feedback regarding SM MIB usefulness.
In the past we did not get any push for interactive SM or online configurable SM so I did not see any reason to work on it.
I do not think it is a huge task to make SM MIB work with OpenSM. At least not the 90% of it that I glanced through.
Eitan Zahavi
Design Technology Director
Mellanox Technologies LTD
Tel:+972-4-9097208
Fax:+972-4-9593245
P.O. Box 586 Yokneam 20692 ISRAEL
> -----Original Message-----
> From: Hal Rosenstock [mailto:halr at voltaire.com]
> Sent: Wednesday, October 26, 2005 7:44 PM
> To: Eitan Zahavi
> Cc: Troy Benjegerdes; openib-general at openib.org
> Subject: RE: [openib-general] [RFC] OpenSM Interactive Console
>
> Hi Eitan,
>
> I sit corrected. There are R/W parameters in the SM MIB as you indicate. I was
> thinking of all the other IPoIB MIBs. It's been a while since I looked at the SM MIB.
>
> Also, the SM MIB (draft-ietf-ipoib-subnet-manager-mib-00) expired a while ago. At a
> minimum, it needs to be dusted off. That would include updating it for IBA 1.2.
>
> -- Hal
>
> ________________________________
>
> From: Eitan Zahavi [mailto:eitan at mellanox.co.il]
> Sent: Tue 10/25/2005 5:19 AM
> To: Hal Rosenstock
> Cc: Troy Benjegerdes; openib-general at openib.org
> Subject: Re: [openib-general] [RFC] OpenSM Interactive Console
>
>
>
> Hal Rosenstock wrote:
> > On Mon, 2005-10-24 at 14:38, Eitan Zahavi wrote:
> >
> >>Hal Rosenstock wrote:
> >>
> >>>On Mon, 2005-10-24 at 03:08, Eitan Zahavi wrote:
> >>>
> >>>
> >>>>I would suggest to use SNMP for the tasks below. IETF IPoIB group
> >
> > has
> >
> >>>>defined an SNMP MIB that can support the required functionality
> >
> > below.
> >
> >>>
> >>>The IETF SNMP MIBs are one way of presenting the information to the
> >>>outside world. There are other possible management interfaces. The
> >
> > SNMP
> >
> >>>MIB instrumentation would need to use lower layer APIs to get this
> >>>information out of the SM.
> >>
> >>Yes but the IETF SM MIB is the only one that is close to a standard
> >
> > way.
> >
> >>It does not require low level interface if it will integrate into the
> >
> > OpenSM code.
> >
> >>One way to do it is buy extending OpenSM with an AgentX interface.
> >>
> >>IMO one clear advantage of using SNMP for SM integration is that the
> >
> > code will work with any SM that is IETF compliant.
> >
> >>Also if you want to write a "client server" type of application on top
> >
> > of an SM you
> >
> >>can either stick to sending MADs which translate into SA client based
> >
> > application or
> >
> >>you better stay with some known protocol for management (like SNMP)
> >
> > and not develop yet another protocol for
> >
> >>doing exactly the same things as SNMP already supports.
> >
> >
> > There are limitations in the SNMP MIBs. One is that they are RO so they
> > are more for monitoring. Also, many environments do not use SNMP. It is
> > unclear how much of a requirement it is to manage any SM or how many
> > other SMs support the SM MIB. (There are other IB associated MIBs too).
>
> SNMP MIBs are certainly not just RO a simple example from the SM MIB:
> ibSmPortInfoLMC OBJECT-TYPE
> SYNTAX Unsigned32(0..7)
> MAX-ACCESS read-write
> STATUS current
> DESCRIPTION
> "LID mask for multipath support. User should take extra caution
> when setting this value, since any change will effect packet
> routing."
> ::= { ibSmPortInfoEntry 19 }
>
>
> I agree that it is possible that currently no SM is supporting the SM MIB.
> But it does make sense to have ALL of the them support it. Such that they can
> be activated/deactivated and configured in the manner.
>
> Most unix distributions and windows box have standard SNMP agent and client
> included in them
> So it does not take more then simple bash or C code to interact with the SM if it
> supports SNMP.
>
> >
> >
> >>>>Everything but the dynamic partitioning (OpenSM does not have
> >>>>partition manager to this moment)
> >>>
> >>>
> >>>What Troy meant by partitioning is not necessarily IB partitioning.
> >>
> >>How are you sure about that? Troy - please comment.
> >
> >
> > I think you missed an email on this.
> >
> >
> >>>>and forwarding of Performance
> >>>>Monitoring traps (which are generated by the PM) can be done through
> >>>>osmsh or through SA client today.
> >>>
> >>>
> >>>What PerfMgr are you referring to ?
> >>
> >>No specific one. But the specification does not require the SM too.
> >
> >
> > Huh ? What spec ? An SM is required in a subnet. There is no subnet
> > without this. There is a subnet without a PerfMgr.
> Yes its a typo I meant PM. SM is a requirement. You know I did not mean that.
> >
> >
> >>For various reasons (like load) it might make more sense to have the
> >
> > PM distributed.
> >
> > Sure. Also, the PerfMgr need not be colocated with the SM anyhow.
> >
> >
> >>Anyway, my point is that the SM is not the owner of PM trap reporting.
> >
> > It is the PM that
> >
> >>should support Reporting (I.e InformInfo registration and Trap
> >
> > forwarding) for PM traps.
> >
> >>But the spec does not define such traps anyway.
> >
> >
> > My point was that the PerfMgr is beyond the IBA spec. It is only the PMA
> > that is defined and has no traps so these will all need synthesis by the
> > PerfMgr.
> Agree.
> >
> > -- Hal
> >
More information about the general
mailing list