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. Are the macros only believed to be useful, or you already use them ? For the usual reasons, it seems to be better to wrap DCPU_ZERO into do/while (0).
pgpI4GbTVwQQG.pgp
Description: PGP signature