From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl0-f65.google.com (mail-pl0-f65.google.com [209.85.160.65]) by dpdk.org (Postfix) with ESMTP id 0BB7D1B2BA for ; Fri, 16 Feb 2018 18:58:16 +0100 (CET) Received: by mail-pl0-f65.google.com with SMTP id g18so2065948plo.7 for ; Fri, 16 Feb 2018 09:58:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=A/BiexPVEJaoFX/ftyYGPmi3yt6FnghsoCwXylQuOhU=; b=xkdqQclTLMTsR5UIij90is0N57SLqWd8Hf43Y9QLsd343Zl6ZBR8BxEYqr6LjLIyHf q2tkYeiUEUQjwg2RXBlpz5o5QqT8IYR+2MAyx32TKFQ0Iwn/dQrHo0k6DpsHSDiA2IOW k0cNcqKRTRy+rJTooZH3QbBmEnU6qqFgwmYtZ+i4sYG6TgBVysoOxe75ocXOOD/Cg3iL h/zDWDbL/AOCLV/Nwf5ykbtznPq6FtSAD1Gp++9jB4RbkhhLy5/kJ53LHO0Dr7EhZJGB +QTSO7JiiRXJ2FSaa1hPDAiXpIET3TGMEMnnSfEExoE5uEZmOFyWRF38Z8GttNvTl/iH z2Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=A/BiexPVEJaoFX/ftyYGPmi3yt6FnghsoCwXylQuOhU=; b=sVmYDW+uU+P5XFLaLpsSykmnqUUqOjLBgXJTi8r4KX3xtVgiIzXJ4qHtD9BwbVXG9Z WMeCui9/c6AB+WbVnck1EJTWJ5X01ijb8y6bEcn6xyVkVqzrscek8MKlUWIIT1S8GwJ0 WvRmsVhflWbfgLUuNawwEHWNLmibu9rR3pXLr6gVayW6Zd3Tp7+Kw5a8PjClnGu9CojF Qj7JdoFZPkzJdtheU3101V944H0c2zygHiGxHZjK3cDIEEwACTpdMyXkzTISa/n3MJ4w 3CU4kBpWloz0W8+YdV5hEGaEY49sXQd6PbFm0S/gAiTPCjg83qbytdo99rLJ+iRqbcqG S4yg== X-Gm-Message-State: APf1xPDqtl9VWldmpNtNFXD8RaZBevmnNplIWS2nE2xgZX5GK0MncV+p dUhZPWlTF0T4rCyHnI3KHVJXHw== X-Google-Smtp-Source: AH8x226CWAM5rtvI2HJZU//LYWldFO+TPNhegKjV3m4e/udvkYOvDT5VdZ7hqx7vbjTkDuI2FF2XKw== X-Received: by 2002:a17:902:9a04:: with SMTP id v4-v6mr6473799plp.252.1518803895180; Fri, 16 Feb 2018 09:58:15 -0800 (PST) Received: from xeon-e3 (204-195-71-95.wavecable.com. [204.195.71.95]) by smtp.gmail.com with ESMTPSA id e127sm4051568pfe.157.2018.02.16.09.58.14 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 16 Feb 2018 09:58:15 -0800 (PST) Date: Fri, 16 Feb 2018 09:58:12 -0800 From: Stephen Hemminger To: Alex Kiselev Cc: dev@dpdk.org Message-ID: <20180216095812.7e634a53@xeon-e3> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] release/acquire memory barriers and ring X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 17:58:16 -0000 On Tue, 13 Feb 2018 22:37:37 +0300 Alex Kiselev wrote: > Hi. > > I've been wondering should I use a release/acquire memory barrier pair > in order to be sure that the other thread will see the fully/corrected > initialized object > passed to it via a dpdk ring or ring itself is a kind of barrier? > > Let's say I have a pseudo code: > > Thread1: > obj = alloc(); > ... > obj initialization > ... > > ??? fence(memory_order_release); ??? > rte_ring_sp_enqueue(ring, obj) > > > Thread2: > ??? fence(memory_order_acquire); ??? > rte_ring_sc_dequeue(ring, obj) > > Should I use fences in that code? > > Thanks. > > -- > Alex Not necessary. Enqueue/dequeue has necessary ordering; it is built on compare-exchange which has implied barrier.