From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f193.google.com (mail-pf0-f193.google.com [209.85.192.193]) by dpdk.org (Postfix) with ESMTP id 0CF9D1B2E0 for ; Wed, 8 Nov 2017 11:32:11 +0100 (CET) Received: by mail-pf0-f193.google.com with SMTP id b6so1132712pff.10 for ; Wed, 08 Nov 2017 02:32:11 -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=vBXzXissP/O1NQQvEdAHuwtyY1H+bMjWqg5fZhHyNKs=; b=aVybVdUJ1EyvJmUOLMRVLD+zYdtEMiJ+tZdogdZkjlaDptHha3NTju5+cSOzdptS6L 214RJx5O206/DyUbmK8RJ6cIS+XmU7Q6cx3Ti1XG1+0ZwC5P/RbGcei9mV3ibzaflQHb 1rgzstQbF3ARZfvI9Xre3ZVrq6DNf6vZenfUOhyeJMGV/0Dzm8/Bq+7bZC/dAcOMBG/z 4HNnExToUPiRpGI1+hE+4cyShsheEbmTjN8p+GPNZkL/E8yfUY52iHxsKEC7Ev23rPsb McXG9ssMEq5gA7DMWS5o44+C2OWKl5Dz+2gAIp68cGzJlVbyomHdm/6GbWQeuV170BEW UMdw== 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=vBXzXissP/O1NQQvEdAHuwtyY1H+bMjWqg5fZhHyNKs=; b=nEt7R5geUUw+UfPZAiFHR5mwp66ex68nMJYsJJHRQQtgHIyXoOWcmSnJMCiWG5ZwWT Gt7t/RX+lBKvm7TDMn85/SLiQfWpamaydS47btVL5sevL+yxNnbzMenxOMhEilTzzQqr /gW0rqGyjISxwtzoE0M84bLLxpq9XO4DpwGnp+u6yuiZSCvPzUwTVB/0RC4XP/6RFpEP texHyVjT5im2eRcTwo9JFB7eN2WIQU13E83oFefhBaNPCiLo2xDg0Mb0Y6rutZyzksOF hrzACD6/bkM6YCtHajLL9Pg86mxToALWZRZhLZ2qhvWBBAq9zen/dKWKry8a8wWBeI0k FdUQ== X-Gm-Message-State: AJaThX7jPTi4lvYBCj9XysM5Tv84EbntWhIuc4BrFc07Kq5eApCHTQkQ qDCpENmqg9p8hSc5bx5JLLM= X-Google-Smtp-Source: ABhQp+S2+u1hznSEyBfXfJmxtpjKPLMHDfhv1y7FrzJ55R9uAMlDBLoqnBDfAVbOHhtWO3H6+sItvg== X-Received: by 10.84.134.34 with SMTP id 31mr1769417plg.154.1510135036607; Wed, 08 Nov 2017 01:57:16 -0800 (PST) Received: from nfv-demo01.hxtcorp.net ([38.106.11.25]) by smtp.gmail.com with ESMTPSA id a19sm7678826pfh.30.2017.11.08.01.57.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 08 Nov 2017 01:57:16 -0800 (PST) From: Jia He To: jerin.jacob@caviumnetworks.com, dev@dpdk.org, olivier.matz@6wind.com Cc: konstantin.ananyev@intel.com, bruce.richardson@intel.com, jianbo.liu@arm.com, hemant.agrawal@nxp.com, Jia He , Jia He , jie2.liu@hxt-semitech.com, bing.zhao@hxt-semitech.com Date: Wed, 8 Nov 2017 09:54:39 +0000 Message-Id: <1510134881-22987-3-git-send-email-hejianet@gmail.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1510134881-22987-1-git-send-email-hejianet@gmail.com> References: <1510118764-29697-1-git-send-email-hejianet@gmail.com> <1510134881-22987-1-git-send-email-hejianet@gmail.com> Subject: [dpdk-dev] [PATCH v4 2/4] ring: guarantee load/load order in enqueue and dequeue 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: Wed, 08 Nov 2017 10:32:12 -0000 We watched a rte panic of mbuf_autotest in our qualcomm arm64 server. 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. Signed-off-by: Jia He Signed-off-by: jie2.liu@hxt-semitech.com Signed-off-by: bing.zhao@hxt-semitech.com --- lib/librte_ring/rte_ring.h | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h index 5e9b3b7..3e8085a 100644 --- a/lib/librte_ring/rte_ring.h +++ b/lib/librte_ring/rte_ring.h @@ -409,6 +409,11 @@ __rte_ring_move_prod_head(struct rte_ring *r, int is_sp, n = max; *old_head = r->prod.head; + + /* add rmb barrier to avoid load/load reorder in weak + * memory model. It is noop on x86 */ + rte_smp_rmb(); + const uint32_t cons_tail = r->cons.tail; /* * The subtraction is done between two unsigned 32bits value @@ -517,6 +522,11 @@ __rte_ring_move_cons_head(struct rte_ring *r, int is_sc, n = max; *old_head = r->cons.head; + + /* add rmb barrier to avoid load/load reorder in weak + * memory model. It is noop on x86 */ + rte_smp_rmb(); + const uint32_t 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.7.4