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>
index | next in thread | previous in thread | raw e-mail
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
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C369172.4020700>