[openib-general] [PATCH] IB/core: fix SM LID/LID changewithclient reregister set

Michael S. Tsirkin mst at mellanox.co.il
Tue Aug 15 10:53:05 PDT 2006


Quoting r. Hal Rosenstock <halr at voltaire.com>:
> 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 <halr at voltaire.com>:
> > > > 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




More information about the general mailing list