svn commit: r209119 - head/sys/sys

[Lawrence Stewart]

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?

Cheers,
Lawrence