Date: Fri, 09 Jul 2010 13:03:14 +1000 From: Lawrence Stewart <lstewart@freebsd.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: Matthew Fleming <mdf@FreeBSD.org>, src-committers@FreeBSD.org, Pawel Jakub Dawidek <pjd@FreeBSD.org>, John Baldwin <jhb@FreeBSD.org>, svn-src-all@FreeBSD.org, brde@optusnet.com.au, svn-src-head@FreeBSD.org Subject: Re: svn commit: r209119 - head/sys/sys Message-ID: <4C369172.4020700@freebsd.org> In-Reply-To: <4C1AD292.5070508@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C369172.4020700>