[openib-general] [RFC] [PATCH] Optimize access to method->agent using bitops

Krishna Kumar krkumar at us.ibm.com
Tue Nov 2 18:35:16 PST 2004


Hi Hal,

Thanks for the update. I will recreate the patch and send it tomorrow.

thanks,

- KK

On Tue, 2 Nov 2004, Hal Rosenstock wrote:

> On Tue, 2004-11-02 at 18:46, Krishna Kumar wrote:
> > I didn't fix the argument to this routine, I was trying to understand if
> > the idea behind this will work, hence the RFC in the subject. Sorry for
> > creating the confusion. I was trying to understand if what I was assuming
> > is right or not.
> >
> > The first part of the patch checks if any bit is set in the method_mask,
> > and if so, it means that a method (table?) is registered and hence it
> > returns error. Actually there might be a better way to check if the
> > bitmask is all-zero's and avoid the for loop, but I don't see any macros
> > for that, and I didn't want to use "if (method_mask)".
> >
> > The add_mad_reg_req() code is doing :
> > 	/* Finally, add in methods being registered */
> >         for (i = find_first_bit(mad_reg_req->method_mask,IB_MGMT_MAX_METHODS);
> > 	     i < IB_MGMT_MAX_METHODS;
> > 	     i = find_next_bit(mad_reg_req->method_mask, IB_MGMT_MAX_METHODS,
> >                                1+i)) {
> >                 (*method)->agent[i] = priv;
> >         }
> > So the agent[0-128] is pointing to the priv when that particular bitmask
> > is set in the method_mask (exact same bit number is used as index in
> > agent).
> >
> > Do you think this model is correct ? The Get/Set/Repress functions can be
> > checked faster by checking if the first/next bit being set rather than
> > going through the entire array of 128 agents, or in one case whether the
> > bitmask is zero or non-zero instead of looping 128 times. If this is true,
> > I will recreate the patch and compile before sending in the final patch.
>
> Sorry I misunderstood that it was RFC. In fact what I wrote was wrong.
> Checking the registration request is just as good as checking the method
> table. Perhaps the routine is now check_method_mask rather than
> check_method_table. The calling parameters are straightforward to fix.
> So the model seems fine to me.
>
> -- Hal
>
>
>




More information about the general mailing list