Hello, The WinOF name has been changed to OFED for windows or OFED-W when necessary for clarification...
A couple of questions: disclaimer - I am not a Windows driver expert, only a student, mileage may vary. 1) you are speaking of trunk\ulp\ipoib_ndis6_cm driver? I'm guessing yes. 2) IPoIB is technically not a 'filter' driver; although it's behavior may somewhat mimic filter driver behaviors. 3) The entire InfiniBand 'bus device management' concept is somewhat wedged into the Windows driver stack w.r.t. PNP event handling. Consider the chicken-n-egg issues of IB bus device management. An HCA can not be removed/disabled unless the IB bus devices it supports have previously been removed/disabled. The problem is how to efficiently inform IB bus devices to remove/change-state without holding the HCA in limbo until IB bus devices have been removed; all the IB bus device PNP mgmt was done long ago in the 'early' days of Server 2003. IB bus devices (IPoIB, vnic, SRP) peek at (register with IBAL for) PNP events such that the IB bus device will remove itself if the HCA is being removed. The PNP event/IRP eventually reaches the HCA which can then properly remove itself knowing it's IB bus devices have removed themselves prior. The IB bus device PNP peeking was chosen long ago to be faster/cleaner than implementing a generalized IB bus device PNP manager. please find additional inline comments. ________________________________ From: John Russo [mailto:[email protected]] Sent: Monday, April 19, 2010 10:23 AM To: Smith, Stan; Hefty, Sean; [email protected] Subject: Filter Drivers in WinOF QLogic is seeing some issues with the current implementation of IPoIB and how it affects PnP Notifications. Can anyone tell me why we are doing things this way or if they disagree with the following statements... Problem: IPoIB registers itself to handle PnP notifications in ipoib_driver.c, function ipoib_pnp_notify(). Any PnP notification other than PowerProfileChanged will cause the adapter state to become "Removed" and the IPoIB filter driver will drop it's connection. This is in direct contradiction to MS Best Practices for filter drivers, which clearly state that filter drivers should *not* interpret PnP or Power notifications, but should instead pass these down the driver stack to the base driver which has the responsibility for actually interpreting the event. This is similar to the WinVerbs D0 handler, where the WinVerbs *filter* driver is attempting to manage a Power notification. If the above mentioned drivers did not view/peek at PNP notifications, then how would the HCA be able to be removed or disabled? Solution: IPoIB should follow the MS Best Practices for filter drivers and stop attempting to manage the Power or PnP notifications, and allow them to pass down the driver stack Personally I do not have a problem with making drivers less complex, provided they continue to work. Additional: This will become problematic during PCI rebalancing, which recall is *not* supposed to cause a teardown but instead a suspension. IPoIB will treat the PnP rebalance notifications as "teardown" events Agreed, sounds like a bug. Perhaps the IPoIB implementers from Mellanox will provide a more in-depth view of the how and why of IPoIB PNP handling. stan. [cid:782515119@19042010-2C2C] John F. Russo Engineering Manager QLogic Corporation 780 Fifth Avenue Suite 140 King of Prussia, PA 19406 Direct: 610-233-4866 Fax: 610-233-4777 Cell: 610-246-9903 www.qlogic.com<http://www.qlogic.com>
<<inline: image001.jpg>>
_______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
