From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) by dpdk.org (Postfix) with ESMTP id 60854532C for ; Mon, 28 Mar 2016 17:48:08 +0200 (CEST) Received: by mail-io0-f178.google.com with SMTP id g185so25369505ioa.2 for ; Mon, 28 Mar 2016 08:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nofutznetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=K7QwnLkyRFNfEj8YjumlyyMfKVDNsR8iIaU4vDUjfFs=; b=Sm9WhA7mVDPocdqXKKyfAAhkhOJ8O4+LdDSplpMf+Mu6Pdl25rV3QWu1CiYA+19jk8 1Wmsbt1zGAxQq1zWLQ+0J4DEOXssjDmAgjYAdnAHCYa5cfcSZcahqvzuo+dz5g6/8P1Q MAImMfkGlOhZE4qu031f3wYDRUF4YmlhgUQo+6rJufvaUfr6Caf9ALU7wXNcU+9tyLN/ P0vCJn9QtTK+BQUVqVIazH9niWYkW5hmDYOAcyaHjS9dvpGpDuxQwDZrY9TTkFiZpnCQ 08Hig4kijP66VH/wbfYEOHwY+LNJlGfUBPZCeF9U3V7zgLi2o59jpSczBcQQsMCTMJLj L1oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=K7QwnLkyRFNfEj8YjumlyyMfKVDNsR8iIaU4vDUjfFs=; b=lwTfPjTHNk/fz06KWSO3Pbm0+AH2lg1xFeijrvtJ3RiSYk4hbBmf0xD1wa7ntPCQH6 p193Gg/M5fnvw80P5Q9xWSZS+s6KKlEn/evztYK1dQV+N4cBfoNcaekA7knRAPTYDwXB MpP4MERK9GUG/OPfXXnt28JRVOirEM36JqBqAq4lhEyEC8gTAhqt0HHZ941jkbVQBo6I GNgXg9NoBJ6lMQHelheZmkdxCpsptPy+qBKJRBNguhpVqBuXzD5uX7oHLcNt702KpAKE rApyER52cmQMMZiBkV0zrE2E+f7dkjWcJlKrYIkMwEXiydZrdgZ6WEhT7UADKMO3Fx6K NJcw== X-Gm-Message-State: AD7BkJJVOf3WqIUBr6Lp0Lqp4ELpZZ7+saxl9V90SG0ogcuS8ZFEOZdC5M+7F7fgZIKEiO2YX+7/n4yzCLo8OA== MIME-Version: 1.0 X-Received: by 10.107.7.20 with SMTP id 20mr26393867ioh.181.1459180087618; Mon, 28 Mar 2016 08:48:07 -0700 (PDT) Received: by 10.107.143.23 with HTTP; Mon, 28 Mar 2016 08:48:07 -0700 (PDT) In-Reply-To: <56F51DCB.5020502@6wind.com> References: <1458229783-15547-1-git-send-email-l@nofutznetworks.com> <56F51DCB.5020502@6wind.com> Date: Mon, 28 Mar 2016 18:48:07 +0300 Message-ID: From: Lazaros Koromilas To: Olivier Matz Cc: dev@dpdk.org, Thomas Monjalon Content-Type: text/plain; charset=UTF-8 Subject: Re: [dpdk-dev] [PATCH v2] ring: check for zero objects mc dequeue / mp enqueue 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: Mon, 28 Mar 2016 15:48:08 -0000 Hi Olivier, We could have two threads (running on different cores in the general case) that both succeed the cmpset operation. In the dequeue path, when n == 0, then cons_next == cons_head, and cmpset will always succeed. Now, if they both see an old r->cons.tail value from a previous dequeue, they can get stuck in the while (unlikely(r->cons.tail != cons_head)) loop. I tried, however, to reproduce (without the patch) and it seems that there is still a window for deadlock. I'm pasting some debug output below that shows two processes' state. It's two receivers doing interleaved mc_dequeue(32)/mc_dequeue(0), and one sender doing mp_enqueue(32) on the same ring. gdb --args ./ring-test -l0 --proc-type=primary gdb --args ./ring-test -l1 --proc-type=secondary gdb --args ./ring-test -l2 --proc-type=secondary -- tx This is what I would usually see, process 0 and 1 both stuck at the same state: 663 while (unlikely(r->cons.tail != cons_head)) { (gdb) p n $1 = 0 (gdb) p r->cons.tail $2 = 576416 (gdb) p cons_head $3 = 576448 (gdb) p cons_next $4 = 576448 But now I managed to get the two processes stuck at this state too. process 0: 663 while (unlikely(r->cons.tail != cons_head)) { (gdb) p n $1 = 32 (gdb) p r->cons.tail $2 = 254348832 (gdb) p cons_head $3 = 254348864 (gdb) p cons_next $4 = 254348896 proccess 1: 663 while (unlikely(r->cons.tail != cons_head)) { (gdb) p n $1 = 32 (gdb) p r->cons.tail $2 = 254348832 (gdb) p cons_head $3 = 254348896 (gdb) p cons_next $4 = 254348928 I haven't been able to trigger this with the patch so far, but it should be possible. Lazaros. On Fri, Mar 25, 2016 at 1:15 PM, Olivier Matz wrote: > Hi Lazaros, > > On 03/17/2016 04:49 PM, Lazaros Koromilas wrote: >> Issuing a zero objects dequeue with a single consumer has no effect. >> Doing so with multiple consumers, can get more than one thread to succeed >> the compare-and-set operation and observe starvation or even deadlock in >> the while loop that checks for preceding dequeues. The problematic piece >> of code when n = 0: >> >> cons_next = cons_head + n; >> success = rte_atomic32_cmpset(&r->cons.head, cons_head, cons_next); >> >> The same is possible on the enqueue path. > > Just a question about this patch (that has been applied). Thomas > retitled the commit from your log message: > > ring: fix deadlock in zero object multi enqueue or dequeue > http://dpdk.org/browse/dpdk/commit/?id=d0979646166e > > I think this patch does not fix a deadlock, or did I miss something? > > As explained in the following links, the ring may not perform well > if several threads running on the same cpu use it: > > http://dpdk.org/ml/archives/dev/2013-November/000714.html > http://www.dpdk.org/ml/archives/dev/2014-January/001070.html > http://www.dpdk.org/ml/archives/dev/2014-January/001162.html > http://dpdk.org/ml/archives/dev/2015-July/020659.html > > A deadlock could occur if the threads running on the same core > have different priority. > > Regards, > Olivier