From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f193.google.com (mail-wr0-f193.google.com [209.85.128.193]) by dpdk.org (Postfix) with ESMTP id 1FB071B38B for ; Mon, 13 Nov 2017 15:49:56 +0100 (CET) Received: by mail-wr0-f193.google.com with SMTP id 4so14671049wrt.0 for ; Mon, 13 Nov 2017 06:49:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=hTf5lcx2SXplegONBgRZ6ATCp7ZeXvU4dXsrhMuNdSA=; b=VKs4kXPgu+w+SnEKw0rfDhZlzfKvb87I+8FA8cq2luadfWhMmvaPZjfjGbXr3Ggcf+ SAVgd56nVMJPnBVO+mI/6IPsVAAnPatTYasQq49ghdssOV/MaYLFw1ywihE/rICuMoj/ ANhl5fcGQyXmEVDPOYc0D2FEc6YlL97ZUSXvtHwxUgyA8kuE/AMvK7YIIt++qZNcxB9C jWjtOp80XxPT7hlPu6W1tr7VZ0/QkJfjv1tuWMM2KRZbAaJyE8ZFX4YJXxb1nSwkdFRF ztiWH4FsBMxk5yD2nNwQe2D0wd0EFNfMwMu77Sm0FT01efJxjyk/iLQgjWh1VTDz1EiS QPeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=hTf5lcx2SXplegONBgRZ6ATCp7ZeXvU4dXsrhMuNdSA=; b=qhthNrmH5nTTf6S9RcUmQ2hO3H8K5DFSjzbcOUT6vkBN0xOYRlf6QI1OiqWBW+MNOs mM40ju+cXxmqyB42dn+18Qg3m+9otfRSfH6eI44sMGH4170wArXqXMN1pAX0NLxDqcsG l12y68uGhjO0lWW0mv7w4dUnUD2kdTb5AuIBSXgkrwrny17FEOUeLoodnEgzwSrcKSOG 4UnEe/J7LV7oqHezJ8F2Png47+zk5QepX4R3BMIOXmii3YA0mKZVBa5GRYeHv0RiwUwP 0UE1bA0ByNGi0nJLK6UDMeWYpcY5mxHJ42D5ikYdjFvKNEFwLG6tX0Ch2QFMbMpavpo1 a/UQ== X-Gm-Message-State: AJaThX6mU56yM93LnnaemJQtcPbin3xu9Qph5vkwdYylVsFAVuBqnuZF CMFBrOYB04nohvLCcq/VkeI= X-Google-Smtp-Source: AGs4zMba4680MNQq13DUkb4WIrWfqr7Zcpb64bebom3QFsjA4fxmQ/lOzA+q6/ZTbbqfHEpgNTTBbg== X-Received: by 10.223.163.143 with SMTP id l15mr7234537wrb.65.1510584595801; Mon, 13 Nov 2017 06:49:55 -0800 (PST) Received: from localhost ([2a00:23c5:bef3:400:4a51:b7ff:fe0b:4749]) by smtp.gmail.com with ESMTPSA id 2sm6268471wre.17.2017.11.13.06.49.54 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 13 Nov 2017 06:49:55 -0800 (PST) From: luca.boccassi@gmail.com To: Jia He Cc: Jie Liu , Bing Zhao , Jerin Jacob , Jianbo Liu , dpdk stable Date: Mon, 13 Nov 2017 14:49:38 +0000 Message-Id: <20171113144938.30993-7-luca.boccassi@gmail.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20171113144938.30993-1-luca.boccassi@gmail.com> References: <20171110161000.15369-16-luca.boccassi@gmail.com> <20171113144938.30993-1-luca.boccassi@gmail.com> Subject: [dpdk-stable] patch 'ring: guarantee load/load order in enqueue and dequeue' has been queued to LTS release 16.11.4 X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 14:49:56 -0000 Hi, FYI, your patch has been queued to LTS release 16.11.4 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before 11/15/17. So please shout if anyone has objections. Thanks. Kind regards, Luca Boccassi --- >>From 0b16342d527b3ea5ca579274598ff8a52fcb7e8e Mon Sep 17 00:00:00 2001 From: Jia He Date: Fri, 10 Nov 2017 03:30:42 +0000 Subject: [PATCH] ring: guarantee load/load order in enqueue and dequeue [ upstream commit 9bc2cbb007c0a3335c5582357ae9f6d37ea0b654 ] We watched a rte panic of mbuf_autotest in our qualcomm arm64 server (Amberwing). Root cause: In __rte_ring_move_cons_head() ... do { /* Restore n as it may change every loop */ n = max; *old_head = r->cons.head; //1st load const uint32_t prod_tail = r->prod.tail; //2nd load In weak memory order architectures (powerpc,arm), the 2nd load might be reodered before the 1st load, that makes *entries is bigger than we wanted. This nasty reording messed enque/deque up. cpu1(producer) cpu2(consumer) cpu3(consumer) load r->prod.tail in enqueue: load r->cons.tail load r->prod.head store r->prod.tail load r->cons.head load r->prod.tail ... store r->cons.{head,tail} load r->cons.head Then, r->cons.head will be bigger than prod_tail, then make *entries very big and the consumer will go forward incorrectly. After this patch, the old cons.head will be recaculated after failure of rte_atomic32_cmpset There is no such issue on X86, because X86 is strong memory order model. But rte_smp_rmb() doesn't have impact on runtime performance on X86, so keep the same code without architectures specific concerns. Fixes: 50d769054872 ("ring: add burst API") Signed-off-by: Jia He Signed-off-by: Jie Liu Signed-off-by: Bing Zhao Acked-by: Jerin Jacob Acked-by: Jianbo Liu --- lib/librte_ring/rte_ring.h | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h index 32b8c8d2c..c1b311a8b 100644 --- a/lib/librte_ring/rte_ring.h +++ b/lib/librte_ring/rte_ring.h @@ -450,6 +450,12 @@ __rte_ring_mp_do_enqueue(struct rte_ring *r, void * const *obj_table, n = max; prod_head = r->prod.head; + + /* add rmb barrier to avoid load/load reorder in weak + * memory model. It is noop on x86 + */ + rte_smp_rmb(); + cons_tail = r->cons.tail; /* The subtraction is done between two unsigned 32bits value * (the result is always modulo 32 bits even if we have @@ -642,6 +648,12 @@ __rte_ring_mc_do_dequeue(struct rte_ring *r, void **obj_table, n = max; cons_head = r->cons.head; + + /* add rmb barrier to avoid load/load reorder in weak + * memory model. It is noop on x86 + */ + rte_smp_rmb(); + prod_tail = r->prod.tail; /* The subtraction is done between two unsigned 32bits value * (the result is always modulo 32 bits even if we have -- 2.11.0