svn commit: r209119 - head/sys/sys

[Lawrence Stewart]

On 07/11/10 18:24, Kostik Belousov wrote:
> On Fri, Jul 09, 2010 at 01:03:14PM +1000, Lawrence Stewart wrote:
>> On 06/18/10 11:57, Lawrence Stewart wrote:
>>> On 06/17/10 17:13, Kostik Belousov wrote:
>>>> On Thu, Jun 17, 2010 at 12:38:08PM +1000, Lawrence Stewart wrote:
>>>>> On 06/14/10 20:43, Kostik Belousov wrote:
>>> [snip]
>>>>>> Or, you could ditch the sum at all, indeed using ({}) and returning the
>>>>>> result. __typeof is your friend to select proper type of accumulator.
>>>>>
>>>>> So, something like this?
>>>>>
>>>>> #define DPCPU_SUM(n, var) __extension__                                \
>>>>> ({                                                                     \
>>>>>          u_int
>>>>> _i;                                                      \
>>>>>          __typeof((DPCPU_PTR(n))->var)
>>>>> sum;                             \
>>>>>                                                                        
>>>>> \
>>>>>          sum =
>>>>> 0;                                                       \
>>>>>          CPU_FOREACH(_i)
>>>>> {                                              \
>>>>>                  sum += (DPCPU_ID_PTR(_i,
>>>>> n))->var;                     \
>>>>>         
>>>>> }                                                              \
>>>>>         
>>>>> sum;                                                           \
>>>>> })
>>>>>
>>>>> Which can be used like this:
>>>>>
>>>>> totalss.n_in = DPCPU_SUM(ss, n_in);
>>
>> [snip]
>>
>>> I'll commit the above version of the macro this evening (GMT+10) unless
>>> I hear any objections. Thanks to all of you for your input.
>>
>> Any objections to the following patch going in as a follow up to the
>> above discussion?
>>
>> http://people.freebsd.org/~lstewart/patches/tcp_ffcaia2008/dpcpu_zeromember_9.x.r209745.patch
>>
>> Turns out I need DPCPU_ZERO to fix a bug in SIFTR and it occurred to me
>> that providing variants of the macros which work on the DPCPU variable
>> itself or a member of a DPCPU struct makes good sense. The new patch
>> therefore renames my original DPCPU_SUM to DPCPU_MEMBERSUM and includes
>> DPCPU_MEMBERZERO().
>>
>> Also open to suggestions on a sensible shortening of MEMBER or other
>> appropriate and descriptive indicator to reduce the macro name lengths.
>> MBR implies some sort of memory barrier... any other ideas?
> 
> I suggest changing MEMBER to VAR.

I'd be happy with that. If I don't get a better suggestion or an
objection I'll go with DPCPU_VARZERO and DPCPU_VARSUM. Thanks for the input.

> Are the macros only believed to be useful, or you already use them ?

DPCPU_ZERO and DPCPU_MEMBERSUM I have an immediate use for in the SIFTR
code. I don't have an immediate use for DPCPU_MEMBERZERO and DPCPU_SUM,
but I can imagine they will both find use once people start converting
stats counters and various other kernel data to DPCPU.

> For the usual reasons, it seems to be better to wrap DCPU_ZERO
> into do/while (0).

Oops, good point. Will do.

Cheers,
Lawrence