From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 9D1C79189 for ; Thu, 25 May 2017 11:51:22 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga105.fm.intel.com with ESMTP; 25 May 2017 02:51:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,391,1491289200"; d="scan'208";a="91624344" Received: from yliu-dev.sh.intel.com ([10.239.67.162]) by orsmga002.jf.intel.com with ESMTP; 25 May 2017 02:51:12 -0700 From: Yuanhan Liu To: Kevin Traynor Cc: Yuanhan Liu , Maxime Coquelin , dpdk stable Date: Thu, 25 May 2017 17:48:36 +0800 Message-Id: <1495705809-21416-64-git-send-email-yuanhan.liu@linux.intel.com> X-Mailer: git-send-email 1.9.0 In-Reply-To: <1495705809-21416-1-git-send-email-yuanhan.liu@linux.intel.com> References: <1495705809-21416-1-git-send-email-yuanhan.liu@linux.intel.com> Subject: [dpdk-stable] patch 'vhost: fix false sharing' has been queued to stable release 17.02.1 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: Thu, 25 May 2017 09:51:23 -0000 Hi, FYI, your patch has been queued to stable release 17.02.1 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before 05/28/17. So please shout if anyone has objections. Thanks. --yliu --- >>From 14a3bbdf73ec7ebf07dd12e6a2c6592a3defcd33 Mon Sep 17 00:00:00 2001 From: Kevin Traynor Date: Thu, 23 Mar 2017 15:44:58 +0000 Subject: [PATCH] vhost: fix false sharing [ upstream commit 4e9474141e1115a3089896848f92b25b53cddfd9 ] The broadcast_rarp field in the virtio_net struct is checked in the dequeue datapath regardless of whether descriptors are available or not. As it is checked with cmpset leading to a write, false sharing on the virtio_net struct can happen between enqueue and dequeue datapaths regardless of whether a RARP is requested. In OVS, the issue can cause a uni-directional performance drop of up to 15%. Fix that by only performing the cmpset if a read of broadcast_rarp indicates that the cmpset is likely to succeed. Fixes: a66bcad32240 ("vhost: arrange struct fields for better cache sharing") Signed-off-by: Kevin Traynor Reviewed-by: Maxime Coquelin Acked-by: Yuanhan Liu --- lib/librte_vhost/virtio_net.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/lib/librte_vhost/virtio_net.c b/lib/librte_vhost/virtio_net.c index 337470d..d0a3b11 100644 --- a/lib/librte_vhost/virtio_net.c +++ b/lib/librte_vhost/virtio_net.c @@ -1056,9 +1056,21 @@ rte_vhost_dequeue_burst(int vid, uint16_t queue_id, * array, to looks like that guest actually send such packet. * * Check user_send_rarp() for more information. + * + * broadcast_rarp shares a cacheline in the virtio_net structure + * with some fields that are accessed during enqueue and + * rte_atomic16_cmpset() causes a write if using cmpxchg. This could + * result in false sharing between enqueue and dequeue. + * + * Prevent unnecessary false sharing by reading broadcast_rarp first + * and only performing cmpset if the read indicates it is likely to + * be set. */ - if (unlikely(rte_atomic16_cmpset((volatile uint16_t *) - &dev->broadcast_rarp.cnt, 1, 0))) { + + if (unlikely(rte_atomic16_read(&dev->broadcast_rarp) && + rte_atomic16_cmpset((volatile uint16_t *) + &dev->broadcast_rarp.cnt, 1, 0))) { + rarp_mbuf = rte_pktmbuf_alloc(mbuf_pool); if (rarp_mbuf == NULL) { RTE_LOG(ERR, VHOST_DATA, -- 1.9.0