Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Sep 2011 21:02:55 -0400
From:      Arnaud Lacombe <lacombar@gmail.com>
To:        "K. Macy" <kmacy@freebsd.org>
Cc:        FreeBSD Hackers <freebsd-hackers@freebsd.org>
Subject:   Re: buf_ring(9) API precisions
Message-ID:  <CACqU3MWwOw_otd0sJ-c4OXedeeJtchwiX9Xpx7V0zNW%2BcNZ7Yw@mail.gmail.com>
In-Reply-To: <CACqU3MXQ6tD804fKymeFeKDnHndSXVvHJwepYztB4DsnNmtMiw@mail.gmail.com>
References:  <CACqU3MXQ6tD804fKymeFeKDnHndSXVvHJwepYztB4DsnNmtMiw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,

On Wed, Sep 14, 2011 at 10:53 PM, Arnaud Lacombe <lacombar@gmail.com> wrote=
:
> Hi Kip,
>
> I've got a few question about the buf_ring(9) API.
>
> 1) what means the 'drbr_' prefix. I can guess the two last letter, 'b'
> and 'r', for Buffer Ring, but what about 'd' and 'r' ?
>
> 2) in `sys/sys/buf_ring.h', you defined 'struct buf_ring' as:
>
> struct buf_ring {
> =A0 =A0 =A0 =A0volatile uint32_t =A0 =A0 =A0 br_prod_head;
> =A0 =A0 =A0 =A0volatile uint32_t =A0 =A0 =A0 br_prod_tail;
> =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 br_prod_size;
> =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 br_prod_mask;
> =A0 =A0 =A0 =A0uint64_t =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0br_drops;
> =A0 =A0 =A0 =A0uint64_t =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0br_prod_bufs;
> =A0 =A0 =A0 =A0uint64_t =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0br_prod_bytes;
shouldn't those 3 fields be updated atomically, especially on 32bits
platforms ? That might pose a problem as, AFAIK, FreeBSD do not have
MI 64bits atomics operations...

 - Arnaud

> =A0 =A0 =A0 =A0/*
> =A0 =A0 =A0 =A0 * Pad out to next L2 cache line
> =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0uint64_t =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_pad0[11];
>
> =A0 =A0 =A0 =A0volatile uint32_t =A0 =A0 =A0 br_cons_head;
> =A0 =A0 =A0 =A0volatile uint32_t =A0 =A0 =A0 br_cons_tail;
> =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 br_cons_size;
> =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 br_cons_mask;
>
> =A0 =A0 =A0 =A0/*
> =A0 =A0 =A0 =A0 * Pad out to next L2 cache line
> =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0uint64_t =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_pad1[14];
> #ifdef DEBUG_BUFRING
> =A0 =A0 =A0 =A0struct mtx =A0 =A0 =A0 =A0 =A0 =A0 =A0*br_lock;
> #endif
> =A0 =A0 =A0 =A0void =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*br_ring[0];
> };
>
> Why are you making an MD guess, the amount of padding to fit the size
> of a cache line, in MI API ? Strangely enough, you did not make this
> assumption in, say r205488 (picked randomly).
>
> Thanks in advance,
> =A0- Arnaud
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACqU3MWwOw_otd0sJ-c4OXedeeJtchwiX9Xpx7V0zNW%2BcNZ7Yw>