svn commit: r209119 - head/sys/sys

[Kostik Belousov]

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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-all/attachments/20100711/156dbf5e/attachment.pgp