[openib-general] RE: User Level Events - request for support
Title: RE: User Level Events - request for support To isolate the implementation of OpenSM from the specific access layer implementation the thread etc would be in the vendor layer. The code in OpenSM core will use a simpler API: provide a callback and context. 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: Michael S. Tsirkin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 18, 2005 1:39 AM To: Eitan Zahavi Cc: 'Hal Rosenstock'; Liran Sorani; Yael Kalka; openib-general@openib.org Subject: Re: User Level Events - request for support Quoting r. Eitan Zahavi [EMAIL PROTECTED]: Subject: RE: User Level Events - request for support Hal Wrote: The OpenSM vendor layer should be enhanced with an additional API for a local port state changed event (and take a flag for port down and port up). OpenSM could then take this event and handle it generically. This could be implemented for gen2 (OpenIB) and gen1 if the events can be generated from VAPI or whatever. Yes. I agree. We should have osm_vendor_api.h define some callback registration function for the local port up/down event. I will implement the OpenSM code for firing a sweep one the port is up. EZ Eitan Zahavi Design Technology Director Mellanox Technologies LTD Tel:+972-4-9097208 Fax:+972-4-9593245 P.O. Box 586 Yokneam 20692 ISRAEL IMHO a function that blocks till there's an event would be a saner API since it matches what kernel can provide. opensm can always create a thread if it wants to get a callback asynchronously. -- MST - Michael S. Tsirkin ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: User Level Events - request for support
Quoting r. Eitan Zahavi [EMAIL PROTECTED]: Subject: RE: User Level Events - request for support Hal Wrote: The OpenSM vendor layer should be enhanced with an additional API for a local port state changed event (and take a flag for port down and port up). OpenSM could then take this event and handle it generically. This could be implemented for gen2 (OpenIB) and gen1 if the events can be generated from VAPI or whatever. Yes. I agree. We should have osm_vendor_api.h define some callback registration function for the local port up/down event. I will implement the OpenSM code for firing a sweep one the port is up. EZ Eitan Zahavi Design Technology Director Mellanox Technologies LTD Tel:+972-4-9097208 Fax:+972-4-9593245 P.O. Box 586 Yokneam 20692 ISRAEL IMHO a function that blocks till there's an event would be a saner API since it matches what kernel can provide. opensm can always create a thread if it wants to get a callback asynchronously. -- MST - Michael S. Tsirkin ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: User Level Events - request for support
Quoting r. Eitan Zahavi [EMAIL PROTECTED]: Subject: User Level Events - request for support I would like to propose for gen2 stack to have a user level API supporting registration for notifications on unaffiliated asynchronous events. As an example in cases when the local IB port link goes down an SM that runs on top of this port needs to be notified and start a sweep when the port is back up. Missing such event, in user land, prevents the SM from knowing about the change. Currently gen1 and gen2 OpenSM is not registered to get these events. The SM will then fail to reconfigure the subnet in cases like: 1. The SM cable connects to a switch and the user changes the switch port the SM is connected to. In this case the SM might be in the middle of a sweep and do not even notice (due to the short time the change takes) that there was a change. Traps coming from the switch are forwarded to the old port the SM was connected to and are dropped (as the port is down). As OpenSM does not know there was any change in the subnet topology, it will not perform a heavy sweep. 2. The switch connected to the SM is rebooted. If the reboot happens so fast that it falls between two light sweeps, OpenSM will not be able to know the switch was reset (as all SMPs are DR). Although one can write special case code to handle these cases, due to the asynchronous nature of things there are many races that can not be resolved without a simple port up/down event that the SM should register to. Hope this provides enough reason behind my request for a user-level event notification mechanism. Eitan uverbs already have this capability, of course. However I think I agree it might make sence to add this capability to umad. Since sm is already blocking on read from umad, it might be simplest to make read return with an error code. Does this make sence? Alternatively, we could try using kobject_uevent. -- MST - Michael S. Tsirkin ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Re: User Level Events - request for support
On Thu, 2005-03-17 at 05:03, Michael S. Tsirkin wrote: However I think I agree it might make sence to add this capability to umad. Since sm is already blocking on read from umad, it might be simplest to make read return with an error code. Does this make sence? Alternatively, we could try using kobject_uevent. This has been on the OpenSM todo list (https://openib.org/svn/gen2/trunk/src/userspace/management/osm/doc/todo). This functionality in umad at the initial port to OpenIB and I believe is on the todo list. -- Hal ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
