Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>: > Subject: Re: [PATCH] IB/core: fix SM LID/LID changewithclient reregister set > > On Tue, 2006-08-15 at 12:45, Michael S. Tsirkin wrote: > > Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>: > > > > This patch simply restores the previous behavior of the sa_query and > > > > cache > > > > modules in responding to events. > > > > > > Understood but doesn't it also has the effect of doing more than this > > > for certain cases of Set PortInfo ? > > > > Not that I can see. > > It's more based on what the driver(s) is/are doing which is not your > change but is the one (back on May 31) which caused this change to be > needed. Client reregister takes precedence over LID change so client > reregister needs to do everything LID change does and possibly more.
Yes, I dislike this too - this seems to set policy in low level driver, of all places. In hindsight, it seems that we should have had a single PORT_INFO_SET event with additional bits marking which fields were set. Something along the lines of IB_EVENT_PORTINFO_SET = 0x100, IB_EVENT_LID_CHANGE = 0x101, IB_EVENT_PKEY_CHANGE = 0x102, IB_EVENT_SM_CHANGE = 0x104, IB_EVENT_CLIENT_REREGISTER = 0x108 and now each event can pass full information to users, and you can test specific bits to figure out if you are interested, or just IB_EVENT_PORTINFO_SET to handle all such events identically. Clearly not 2.6.18, but - how does this sound? > Your change looks fine to me. > > What about local_sa ? Does it need this change too ? No idea. I'm focusing on 2.6.18 mainly. local sa revocation policy is not really clear to me, maybe it's already covered? -- MST _______________________________________________ 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