[openib-general] [RFC] [PATCH 2/7] ib_multicast 2.6.20: add ib_multicast module to track join requests from the same port
Sean Hefty
mshefty at ichips.intel.com
Wed Oct 11 09:20:10 PDT 2006
Michael S. Tsirkin wrote:
>>+struct ib_multicast {
>>+ struct ib_sa_mcmember_rec rec;
>>+ ib_sa_comp_mask comp_mask;
>>+ int (*callback)(int status,
>>+ struct ib_multicast *multicast);
>>+ void *context;
>>+};
>
>
> Why is ib_sa_mcmember_rec exposed?
Because the user needs to get the actual mcmember record somewhere.
> So need to either specify which values are valid,
> or use a different structure here.
It's the mcmember record. All of the values are valid.
> Is callback invoked only once? If no should document.
The callback may be invoked multiple times.
>>+struct ib_multicast *ib_join_multicast(struct ib_device *device, u8 port_num,
>>+ struct ib_sa_mcmember_rec *rec,
>>+ ib_sa_comp_mask comp_mask, gfp_t gfp_mask,
>>+ int (*callback)(int status,
>>+ struct ib_multicast
>>+ *multicast),
>
> What are the values for status?
It depends on the failure. Typically it matches the value returned by ib_sa.
This can be documented.
> I see that it's not just 0 or non-zero - IPoIB needs to treat some
> of them magically for some reason.
I'm not sure what you mean by magically. It traps for ENETRESET, with a comment
that it traps for port events itself, and ETIMEOUT.
> We used to have a timeout value - I think this is something ULP might want
> control over. Of course if we are already in the group you can return
> immediately.
Multiple join requests may be funneled into a single MAD. A timeout value makes
no sense with multiple users.
- Sean
More information about the general
mailing list