On Fri, Oct 30, 2009 at 4:06 PM, Sasha Khapyorsky <sas...@voltaire.com> wrote:
> On 09:48 Fri 30 Oct     , Hal Rosenstock wrote:
>> >
>> > diff --git a/opensm/opensm/osm_mcast_tbl.c b/opensm/opensm/osm_mcast_tbl.c
>> > index b5ae6f2..eee9290 100644
>> > --- a/opensm/opensm/osm_mcast_tbl.c
>> > +++ b/opensm/opensm/osm_mcast_tbl.c
>> > @@ -122,7 +122,7 @@ int osm_mcast_tbl_realloc(IN osm_mcast_tbl_t * p_tbl, 
>> > IN
>> > uintn_t mlid_offset)
>> >        uint16_t (*p_mask_tbl)[][IB_MCAST_POSITION_MAX];
>> >
>> >        if (mlid_offset < p_tbl->mft_depth)
>> > -               return 0;
>> > +               goto done;
>>
>> Why should max_mlid_ho be changed when < mft_depth ?
>
> To be equal to an actually configured max mlid value (not a size of
> mcast table allocation).
>
>> Doing so makes group removal not work properly.
>
> This may have this issue, but not due to fact of max_mlid_ho change, but
> due to invalid check in osm_mcast_tbl_clear_mlid(). I think there it
> should be something like:
>
> diff --git a/opensm/opensm/osm_mcast_tbl.c b/opensm/opensm/osm_mcast_tbl.c
> index 0a45904..a599e56 100644
> --- a/opensm/opensm/osm_mcast_tbl.c
> +++ b/opensm/opensm/osm_mcast_tbl.c
> @@ -245,8 +245,8 @@ void osm_mcast_tbl_clear_mlid(IN osm_mcast_tbl_t * p_tbl, 
> IN uint16_t mlid_ho)
>        CL_ASSERT(p_tbl);
>        CL_ASSERT(mlid_ho >= IB_LID_MCAST_START_HO);
>
> -       if (p_tbl->p_mask_tbl && mlid_ho <= p_tbl->max_mlid_ho) {
> -               mlid_offset = mlid_ho - IB_LID_MCAST_START_HO;
> +       mlid_offset = mlid_ho - IB_LID_MCAST_START_HO;
> +       if (p_tbl->p_mask_tbl && mlid_offset < p_tbl->mft_depth) {
>                for (i = 0; i <= p_tbl->max_position; i++)
>                        (*p_tbl->p_mask_tbl)[mlid_offset][i] = 0;
>        }
>
> Does it make sense?

Yes, that fixes the removal issue.

Tested-by: Hal Rosenstock <hal.rosenst...@gmail.com>

-- Hal

> Sasha
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to