[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