From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by dpdk.org (Postfix) with ESMTP id B83351F3 for ; Tue, 20 Aug 2013 10:21:38 +0200 (CEST) Received: by mail-wi0-f177.google.com with SMTP id hq12so104783wib.4 for ; Tue, 20 Aug 2013 01:22:08 -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=4OLCFvHqT+aXEMzK90cvC0xCioauYVLrNQPo3Eeymhc=; b=oKpagJTVg7TWcJs0GF2IJBBMwGvljKBsOeUAjZIQGWlAdsPDDft5zoxMtpXTRKsg2z uT7s51sZOh/qVtZL7uDGT0nxtiNVMyUWAnKHYYPs2Ku6uxEYzRwwbTVCswquR8A2PLMG bNNow6OEPw9de6vD8wg9KpN0JHoRgp9ya+5SZNmRQryEJj54mlubO+WSiTZT/oqfaDWC oCf5tqi/0eAMwuFv6b4+dQFYUGKwUXNFV6i/y7qRjiNysBDp+bfO3jzDQu9LurCRcpUX IelBuPBuYvEqQI8uixWx+Vh6ynVr3P+e0QZprGTn/HQn/ehPTFoPgBngxo1844546g2r iM6g== X-Gm-Message-State: ALoCoQmo4Dtc+bfywXM9pAYkmoCuv8y0sZBEnfRwdzjjRNbH6d+5z/7xdA2T31AWOuYI1sRc/Gf/ X-Received: by 10.194.123.199 with SMTP id mc7mr289784wjb.43.1376986928338; Tue, 20 Aug 2013 01:22:08 -0700 (PDT) Received: from [10.16.0.195] (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id v9sm22105875wiw.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 Aug 2013 01:22:07 -0700 (PDT) Message-ID: <5213272C.4060101@6wind.com> Date: Tue, 20 Aug 2013 10:22:04 +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: Bob Chen References: 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: Tue, 20 Aug 2013 08:21:39 -0000 Hello Ben, > OK, here is the question: Why DPDK has to maintain that public prod_tail > structure? Is it really necessary to endure a while loop here? If you remove this wait loop, you can trigger an issue. Imagine a case where core 0 wants to add an object in the ring: it does the CAS, modifying prod_head. At this time it is interrupted for some reason (maybe by the kernel) before writing the object pointer in the ring, and thus before the modification of prod_tail. During this time, core 1 wants to enqueue another object: it does the CAS, then writes the object pointer, then modifies prod_head (without waiting the core 0 as we removed the wait loop). Now the state ring is wrong: it shows 2 objects, but one object pointer is invalid. If you try to dequeue the objects, it will return an bad pointer. Of course, the interruption by the kernel should be avoided as much as possible, but even without beeing interrupted, a similar scenario can occur if a core is slower than another to enqueue its data (due to a cache miss for instance, or because the first core enqueues more objects than the other). To convince you, I think you can remove the wait loop and run the ring test in app/test/test_ring.c, I suppose it won't work. Regards, Olivier