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