From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 15 03:21:47 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7983E106564A for ; Thu, 15 Sep 2011 03:21:47 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 56F378FC0C for ; Thu, 15 Sep 2011 03:21:47 +0000 (UTC) Received: by pzk36 with SMTP id 36so412627pzk.31 for ; Wed, 14 Sep 2011 20:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=moaGSZQYgXM734xpFcswt2BHX92yeB8jLZd9dgLDkrQ=; b=xljVGdvtJU9CyQxFEaKrkzf3WYP0sqs26iERV8hs6lJD41FSuD9K4I9kk3ygpx1g7Z X5Pu3sx4Y0ZctYYC5JGRq2HFECFge4uM3Nj8hO8qVeqGn9hPjZjLq4OraexyQpFODD/z Eu0Y3wG/XaDmMJcCs/Eh+4vJaYx+LX8MMU2vc= MIME-Version: 1.0 Received: by 10.68.27.101 with SMTP id s5mr786809pbg.197.1316055205974; Wed, 14 Sep 2011 19:53:25 -0700 (PDT) Received: by 10.142.12.18 with HTTP; Wed, 14 Sep 2011 19:53:25 -0700 (PDT) Date: Wed, 14 Sep 2011 22:53:25 -0400 Message-ID: From: Arnaud Lacombe To: "K. Macy" Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers Subject: buf_ring(9) API precisions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 03:21:47 -0000 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 { volatile uint32_t br_prod_head; volatile uint32_t br_prod_tail; int br_prod_size; int br_prod_mask; uint64_t br_drops; uint64_t br_prod_bufs; uint64_t br_prod_bytes; /* * Pad out to next L2 cache line */ uint64_t _pad0[11]; volatile uint32_t br_cons_head; volatile uint32_t br_cons_tail; int br_cons_size; int br_cons_mask; /* * Pad out to next L2 cache line */ uint64_t _pad1[14]; #ifdef DEBUG_BUFRING struct mtx *br_lock; #endif void *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, - Arnaud