[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