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:[EMAIL PROTECTED] Sent: Thu 10/27/2005 2:03 AM To: Hal Rosenstock; Eitan Zahavi Cc: Troy Benjegerdes; [email protected] 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:[EMAIL PROTECTED] > Sent: Wednesday, October 26, 2005 7:44 PM > To: Eitan Zahavi > Cc: Troy Benjegerdes; [email protected] > 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:[EMAIL PROTECTED] > Sent: Tue 10/25/2005 5:19 AM > To: Hal Rosenstock > Cc: Troy Benjegerdes; [email protected] > 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 > > _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
