[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