[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