From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by dpdk.org (Postfix) with ESMTP id 6FA4956B7 for ; Mon, 22 Feb 2016 11:15:49 +0100 (CET) Received: by mail-wm0-f49.google.com with SMTP id g62so164451519wme.1 for ; Mon, 22 Feb 2016 02:15:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=4T0HRrJC+8PaDJmrsRocq2kHlCxsqi3bSUQbzvVoMjk=; b=EbbIBmS2xZf0wzV+HtXK2zMbwPaE2ay0Ve3iXyf6ipHtHJKSTQth6aKN6H+obwR4sT 4WRshH/cwiUYNhUoQWhfasZWtES7iQTm/RsyNSdT7NeNr0orZOOaCqD7eVeIGGZuUyrv 1WhcYIS+DXBlpEZ1U6M4ADpOv9UdDfyHqREFVaflmI6NMq+2F5G6JomgZWOwV69TCQ4L BMo/nrSY191bNp5HgjutQuBrj/HwKSR7/MeSzBx7z+rHa8JbUdGELG4LB1Cy9oZG2Fp4 E/OrwNevhZJfYs0uUvr0C/oVmePAav5znMWPGIeUWiKPVwgBVRZhqkh49s3sn6kJUTgQ no6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=4T0HRrJC+8PaDJmrsRocq2kHlCxsqi3bSUQbzvVoMjk=; b=NAWLa9qwehYOkYivAaq8YRmRzAD+5x0l4JtXBZF/Mx53rhjWWALEu07jkMUE48Z0Dl Yz4LouCAaPB2FbW+bZYC3Kz5Gj6074AXUQqxOLi4nk1I7dx/kLjdJxQVwhDCailvrFLc dRbANklA5TrhtYSwzZTzf1SEKtgaHqbeKlcxt7ySkQkIYnFVhRpETDP9To62DVvcthEu /siHcnHqNKedOIw32sSpouHfmW4sEQG9Wd2Cc9RIsqPJmvnf7t8OTyLb07Y9XG4fPKtA NsUqk9msZ4NMyDO5KfZawsU13VaYjslQXfetIRkoUnku4uR8jX1PSfDI7cTZ5l8jDZmz OJ7w== X-Gm-Message-State: AG10YOS1RGoNWUboc+2RKNdgZzLCyXqOK+MNxvbSlldDUc4naP1T8T2U2RZeuuHDOh40syMi X-Received: by 10.194.63.242 with SMTP id j18mr31270231wjs.114.1456136149287; Mon, 22 Feb 2016 02:15:49 -0800 (PST) Received: from xps13.localnet (171.36.101.84.rev.sfr.net. [84.101.36.171]) by smtp.gmail.com with ESMTPSA id hh8sm23865759wjc.42.2016.02.22.02.15.48 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Feb 2016 02:15:48 -0800 (PST) From: Thomas Monjalon To: "Xie, Huawei" Date: Mon, 22 Feb 2016 11:14:14 +0100 Message-ID: <3343596.CjhAKlsm75@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: <1455863563-15751-1-git-send-email-i.maximets@samsung.com> <56C6DACA.7040109@samsung.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: Dyasly Sergey , dev@dpdk.org, Ilya Maximets Subject: Re: [dpdk-dev] [PATCH RFC 4/4] doc: add note about rte_vhost_enqueue_burst thread safety. 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, 22 Feb 2016 10:15:49 -0000 2016-02-22 02:07, Xie, Huawei: > On 2/19/2016 5:05 PM, Ilya Maximets wrote: > > On 19.02.2016 11:36, Xie, Huawei wrote: > >> On 2/19/2016 3:10 PM, Yuanhan Liu wrote: > >>> On Fri, Feb 19, 2016 at 09:32:43AM +0300, Ilya Maximets wrote: > >>>> Signed-off-by: Ilya Maximets > >>>> --- > >>>> doc/guides/prog_guide/thread_safety_dpdk_functions.rst | 1 + > >>>> 1 file changed, 1 insertion(+) > >>>> > >>>> diff --git a/doc/guides/prog_guide/thread_safety_dpdk_functions.rst b/doc/guides/prog_guide/thread_safety_dpdk_functions.rst > >>>> index 403e5fc..13a6c89 100644 > >>>> --- a/doc/guides/prog_guide/thread_safety_dpdk_functions.rst > >>>> +++ b/doc/guides/prog_guide/thread_safety_dpdk_functions.rst > >>>> The mempool library is based on the DPDK lockless ring library and therefore is also multi-thread safe. > >>>> +rte_vhost_enqueue_burst() is also thread safe because based on lockless ring-buffer algorithm like the ring library. > >>> FYI, Huawei meant to make rte_vhost_enqueue_burst() not be thread-safe, > >>> to aligh with the usage of rte_eth_tx_burst(). > >>> > >>> --yliu > >> I have a patch to remove the lockless enqueue. Unless there is strong > >> reason, i prefer vhost PMD to behave like other PMDs, with no internal > >> lockless algorithm. In future, for people who really need it, we could > >> have dynamic/static switch to enable it. > > Thomas, what is your opinion on this and my patch removing lockless enqueue? The thread safety behaviour is part of the API specification. If we want to enable/disable such behaviour, it must be done with an API function. But it would introduce a conditional statement in the fast path. That's why the priority must be to keep a simple and consistent behaviour and try to build around. An API complexity may be considered only if there is a real (measured) gain.