From owner-freebsd-hackers@FreeBSD.ORG Fri May 8 04:36:03 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06C69DDE; Fri, 8 May 2015 04:36:03 +0000 (UTC) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D2D5C1DA8; Fri, 8 May 2015 04:36:02 +0000 (UTC) Received: by pdbqd1 with SMTP id qd1so62528928pdb.2; Thu, 07 May 2015 21:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=W9xhQEs2VxMiWfdnBryTkDfyvp9eu2SIXLAnKv/OX9o=; b=TJ5goZTDeZk7zjBTkJLB//Ezh5GoI1sL5sJJiW4OdLJQ/Z4Qp51vP5vGuJ8zcGRRUW jbXhUC8HO1BaHNXiGNJ6ryBEhKds1/VEymIwH0PDvq0VrfS3dr6bX0RnjoeAx6NUWCRY VS28Nhwwn9ioQZL7tgrWYIa7Wcm0Jw8/EBe+2WHKNvKlYxnL9kpDvg14iFJbDlOczy6R QEY5o+1XbUryLPi9t7JDBl6XgJubPMVM4QQFd+I/TWLJ4cdPQC6Wq9xHOqR8RCPysAhV bIHafywxXlJ/42wYSFDx2HPksTDglf7+DjCrd/Rk01x2DLiJ8JHryFWoBicsdLG+xmRM fyWw== X-Received: by 10.67.4.2 with SMTP id ca2mr3371113pad.62.1431059762437; Thu, 07 May 2015 21:36:02 -0700 (PDT) Received: from [0.0.0.0] (ec2-54-64-223-91.ap-northeast-1.compute.amazonaws.com. [54.64.223.91]) by mx.google.com with ESMTPSA id wa4sm3678543pab.17.2015.05.07.21.36.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 May 2015 21:36:01 -0700 (PDT) Message-ID: <554C3D2A.7030909@gmail.com> Date: Fri, 08 May 2015 12:35:54 +0800 From: rhenjau User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ian Lepore CC: freebsd-hackers@freebsd.org Subject: Re: Memory barriers about buf_ring(9) References: <1431008458.6170.165.camel@freebsd.org> In-Reply-To: <1431008458.6170.165.camel@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 04:36:03 -0000 Hi, Ian Thank you for your information. On 2015/5/7 22:20, Ian Lepore wrote: > On Thu, 2015-05-07 at 18:10 +0800, rhenjau wrote: >> Hi, hackers >> I'm reading buf_ring(9) and have a question about the following >> function. Is a memory barrier needed before br_cons_tail to prevent the >> loading of br_ring[cons_head] load is reordered after br_cons_tail is set? >> Producers may overwrite the area. >> >> /* >> * single-consumer dequeue >> * use where dequeue is protected by a lock >> * e.g. a network driver's tx queue lock >> */ >> static __inline void * >> buf_ring_dequeue_sc(struct buf_ring *br) >> { >> uint32_t cons_head, cons_next; >> #ifdef PREFETCH_DEFINED >> uint32_t cons_next_next; >> #endif >> uint32_t prod_tail; >> void *buf; >> >> cons_head = br->br_cons_head; >> prod_tail = br->br_prod_tail; >> >> cons_next = (cons_head + 1) & br->br_cons_mask; >> #ifdef PREFETCH_DEFINED >> cons_next_next = (cons_head + 2) & br->br_cons_mask; >> #endif >> >> if (cons_head == prod_tail) >> return (NULL); >> >> #ifdef PREFETCH_DEFINED >> if (cons_next != prod_tail) { >> prefetch(br->br_ring[cons_next]); >> if (cons_next_next != prod_tail) >> prefetch(br->br_ring[cons_next_next]); >> } >> #endif >> br->br_cons_head = cons_next; >> buf = br->br_ring[cons_head]; >> >> #ifdef DEBUG_BUFRING >> br->br_ring[cons_head] = NULL; >> if (!mtx_owned(br->br_lock)) >> panic("lock not held on single consumer dequeue"); >> if (br->br_cons_tail != cons_head) >> panic("inconsistent list cons_tail=%d cons_head=%d", >> br->br_cons_tail, cons_head); >> #endif >> ----------------------------------------------------- need memory >> barrier? >> br->br_cons_tail = cons_next; >> return (buf); >> } >> > There was some discussion and changes relating to barriers in buf_ring, > but it looks like the changes never got committed (I don't know why). > > https://reviews.freebsd.org/D1945 > > -- Ian >