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 _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"