From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) by dpdk.org (Postfix) with ESMTP id 16D941F3 for ; Wed, 21 Aug 2013 10:31:01 +0200 (CEST) Received: by mail-we0-f176.google.com with SMTP id q56so119053wes.35 for ; Wed, 21 Aug 2013 01:31:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xf6cYyk4HYMtJm8NjN8wsqn0QSFYSXZSLC3EyUlAwjE=; b=Fm/rmeP4MMa+F3nrA2Nzd3T5qtkopEhLDRgbekJ94AJ2b32ZE2nIfmHm7gQ0Ug+R4H fXSg3EYeeV4mqSiBtiHYwr9SamHggia1t+HOxUxobgmprWcyUNyyKiA4nmmFY+PIdXs0 Jks//ob3bXbMc7ZmSsfwIm9+T+2R5dvTEDvS/rKN7xpZy0zJYpiYy4btW+9ESzGimWWO yvB4XCapO9PXCRvA2ZY1MlqTrFFJbLvdvzVJat3WRUdnkYchLtvQS/wbDQQxWDNTwI+T QdkO3XMGqEIjogTG1RxamsG4iJfxFjJtd/eograoDgja21Frf3kUsLmMl71giEh6ixr1 wg7w== X-Gm-Message-State: ALoCoQmWEkCv+/cx1MIPCpncKg0wbyhU543sdUJh+XpIy0+wEzl2KYfpMCO6qrkJL+lm/N2SM449 X-Received: by 10.180.13.13 with SMTP id d13mr4541073wic.34.1377073891850; Wed, 21 Aug 2013 01:31:31 -0700 (PDT) Received: from [10.16.0.195] (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id l7sm29354792wiw.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Aug 2013 01:31:31 -0700 (PDT) Message-ID: <52147AE1.4030000@6wind.com> Date: Wed, 21 Aug 2013 10:31:29 +0200 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120817 Icedove/10.0.6 MIME-Version: 1.0 To: "Chen, Bo D" References: <5213272C.4060101@6wind.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dev Subject: Re: [dpdk-dev] A question of DPDK ring buffer X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 08:31:02 -0000 Hi Bob, > do { > prod_head = r->prod.head; > cons_tail = r->cons.tail; > prod_next = prod_head + n; > success = rte_atomic32_cmpset(&r->prod.head, prod_head, prod_next); > > /* > * Why not enqueue data here? It would be just a couple of pointers assignment, not taking too much time. > * Then the entire CAS loop contains both pointer adjustment and data enqueue, and the dequeue operation would not have a chance to interfere data producing. > * The next wait loop can be removed accordingly. > /* You cannot enqueue your data here: before writing the objects, you must first check that the cmpset is succesful. In your example, if the cmpset fails, it would write the objects pointer in a zone already reserved by another producer core. The writing of objects must be done after the "do - while" loop, once cmpset is succesful. But even with that, you cannot remove the wait loop (r->prod.tail != prod_head) for the reasons described in my previous mail. The ring test in app/test/test_ring.c is quite stressful for the rings so you can use it to check that your solution is working. Regards, Olivier