[openib-general] [RFC] [PATCH 2/7] ib_multicast 2.6.20: add ib_multicast module to track join requests from the same port

Michael S. Tsirkin mst at mellanox.co.il
Wed Oct 11 05:09:49 PDT 2006


IPoIB discussion aside, some more comments on the API:

> +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?
As was discussed separately, a single mcast group might match
mutiple distinct queries.

So need to either specify which values are valid,
or use a different structure here.

> +/**
> + * ib_join_multicast - Initiates a join request to the specified multicast
> + *   group.
> + * @device: Device associated with the multicast group.
> + * @port_num: Port on the specified device to associate with the multicast
> + *   group.
> + * @rec: SA multicast member record specifying group attributes.
> + * @comp_mask: Component mask indicating which group attributes of %rec are
> + *   valid.
> + * @gfp_mask: GFP mask for memory allocations.
> + * @callback: User callback invoked once the join operation completes.

Is callback invoked only once? If no should document.

> + * @context: User specified context stored with the ib_multicast structure.
> + *
> + * This call initiates a multicast join request with the SA for the specified
> + * multicast group.  If the join operation is started successfully, it returns
> + * an ib_multicast structure that is used to track the multicast operation.
> + * Users must free this structure by calling ib_free_multicast, even if the
> + * join operation later fails.  (The callback status is non-zero.)
> + */
> +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?
I see that it's not just 0 or non-zero - IPoIB needs to treat some
of them magically for some reason.
Must document.

>From IPoIB code it seems that e.g. port state change will cause
join to fail. Correct? Why is that? Why not rely on timeout for that?

> +				       void *context);

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.

-- 
MST




More information about the general mailing list