[openib-general] [RFC] OpenSM Interactive Console
Eitan Zahavi
eitan at mellanox.co.il
Thu Oct 27 08:30:39 PDT 2005
Hi Hal,
I still think that a "server" like behavior is much preferable to having the
SM sit there and wait for console inputs. The SM is a service and thus
should run like a daemon.
MIB is just a standard way to avoid the need to define our own protocol to
do that.
In your implementation the SM should be put in console mode from the first
invocation and thus will need a dedicated terminal.
Even with osmsh one could implement (using standard Tcl sockets) a simple
server that could just wait for remote commands (I can provide the code as I
have done zillions of such servers).
The MIB is nicer and I think it is not very complicated to implement. At
least not the trivial groups of setting SM parameters.
The more I think about it the more I get convinced we need to do it.
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: Thursday, October 27, 2005 1:45 PM
> To: Eitan Zahavi
> Cc: Troy Benjegerdes; openib-general at openib.org
> Subject: RE: [openib-general] [RFC] OpenSM Interactive Console
>
> 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
> > >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20051027/c1cb22aa/attachment.html>
More information about the general
mailing list