Date: Sun, 11 Jul 2010 11:24:54 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Lawrence Stewart <lstewart@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r209119 - head/sys/sys Message-ID: <20100711082454.GN2408@deviant.kiev.zoral.com.ua> In-Reply-To: <4C369172.4020700@freebsd.org> References: <201006130239.o5D2du3m086332@svn.freebsd.org> <20100613101025.GD1320@garage.freebsd.pl> <4C158B71.205@freebsd.org> <20100614085205.GD13238@deviant.kiev.zoral.com.ua> <4C1605A7.2000202@freebsd.org> <20100614104349.GF13238@deviant.kiev.zoral.com.ua> <4C198A90.3060905@freebsd.org> <20100617071300.GX13238@deviant.kiev.zoral.com.ua> <4C1AD292.5070508@freebsd.org> <4C369172.4020700@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
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).
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)
iEYEARECAAYFAkw5f9YACgkQC3+MBN1Mb4h4/ACfagFoqk7I2yAkvp+gu3jGvP0Z
HJEAoM+1XFk8J2pHN+29u/mQEtDBdD5p
=ZeY9
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100711082454.GN2408>