From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by dpdk.org (Postfix) with ESMTP id E494F5F2C for ; Mon, 3 Sep 2018 17:31:33 +0200 (CEST) Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20180903153132euoutp027ad12aa097457633478bc8a8a2812acf~Q7ZP89Eou2533825338euoutp02e for ; Mon, 3 Sep 2018 15:31:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20180903153132euoutp027ad12aa097457633478bc8a8a2812acf~Q7ZP89Eou2533825338euoutp02e DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1535988692; bh=cbrYOkkUMYoU8Hd7gGmm60yIJeZ/UfoLqJpAba6gSXQ=; h=Subject:To:Cc:From:Date:In-Reply-To:References:From; b=mqLxwV9MS5B+3AECUHLbqknPNX5UJCOSk3QDpK6QfTi0nUuS/Ptgj3gb9VIQRTNj+ tjIk/Lwkcy2ojjPr341H25E/VpHU/yhITG1DXMSjXBYPvCCiuGytmMtfGM+uvsiMrS qLQHzcLbrGxARvL9SIT0fMVYHNkKHKnqGVRRfzwI= Received: from eusmges1new.samsung.com (unknown [203.254.199.242]) by eucas1p1.samsung.com (KnoxPortal) with ESMTP id 20180903153132eucas1p1685ff8ef3181873d51b4a846c73f2cfb~Q7ZPRulw_0153301533eucas1p1M; Mon, 3 Sep 2018 15:31:32 +0000 (GMT) Received: from eucas1p2.samsung.com ( [182.198.249.207]) by eusmges1new.samsung.com (EUCPMTA) with SMTP id 43.18.04441.3D35D8B5; Mon, 3 Sep 2018 16:31:31 +0100 (BST) Received: from eusmtrp1.samsung.com (unknown [182.198.249.138]) by eucas1p1.samsung.com (KnoxPortal) with ESMTPA id 20180903153131eucas1p122e24d751d0f87d0cff88f3360c50e37~Q7ZOaSu4X0341203412eucas1p1A; Mon, 3 Sep 2018 15:31:31 +0000 (GMT) Received: from eusmgms1.samsung.com (unknown [182.198.249.179]) by eusmtrp1.samsung.com (KnoxPortal) with ESMTP id 20180903153130eusmtrp16bd58ed7885df02eb32109408d8de122~Q7ZOH9jw33081430814eusmtrp15; Mon, 3 Sep 2018 15:31:30 +0000 (GMT) X-AuditID: cbfec7f2-5c9ff70000001159-a0-5b8d53d3ee81 Received: from eusmtip2.samsung.com ( [203.254.199.222]) by eusmgms1.samsung.com (EUCPMTA) with SMTP id F5.5E.04284.2D35D8B5; Mon, 3 Sep 2018 16:31:30 +0100 (BST) Received: from [106.109.129.180] (unknown [106.109.129.180]) by eusmtip2.samsung.com (KnoxPortal) with ESMTPA id 20180903153130eusmtip28fe6aa3304ca87639c54e1a0856a2b91~Q7ZNeeSKh1843318433eusmtip2S; Mon, 3 Sep 2018 15:31:30 +0000 (GMT) To: "Wiles, Keith" Cc: "dev@dpdk.org" , "Wu, Jingjing" , "Ananyev, Konstantin" , "Lu, Wenzhuo" , "Xing, Beilei" , "Zhang, Qi Z" , "Wang, Xiao W" , "Richardson, Bruce" From: Ilya Maximets Date: Mon, 3 Sep 2018 18:33:01 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA02SaUhUURTHu++9cZ6DY9fR8mhiNEiUuC/0oMWEIj8KEZTzwSbnuZDjMs9x o3BBTDQtNJicTLRyNEtLcUmN1GlSTLPVGiEwQjM111HC3PL5kvz2O///OfcsXJqU1Ymc6Zi4 JFYTp4yVW0molp7lt54fzxYqfMy9nkzBXA7BmGuDmJmFVoL5dG1ZzJRWWBAz1PubZGZX71GM 7ukNK6Z5YA0xneMvxSclIX8qqkQh959PECFFTbUolAyTHFOxsTHJrMb7xEVJ9K3i76KEDe/U OV1oJuo4lI+sacAB8KW8nchHElqGaxDU9HWKhGARwc9xA5WP6M3AgiA3cLvgVd06EnKqEdxe 2iB4Q4bnEQy/O8CzPQ6DsdY7JM8O2B0q13+J+QISDxGQ020R84YV9oDXj0yIZwq7QUnD0pa+ B58H07fKLV2K7aCvdJTi2Rofh8myciueSewI2YsPRQLvh9bpMpJvALhFDPNtFpFQnAxTxQOU MPYpGKqfIwW2h8neJrHALtBfcv1fTgaM5Ewg4aE8BDrjOiEYQdA0NSjmT0Hiw/Ck3VuQg6Fq eoDgZcC2YJ62E+axheIWHSnIUsjLlQnZbrDSXf1vAmcYnrGIbyK5fseW+h2b6Xdspv/ftwJR tciR1XLqKJbzjWNTvDilmtPGRXlFxKsb0eYn6l/vXXiGlj5cMiJMI7mNNNSnUCETKZO5NLUR AU3KHaRZZzYlqUqZls5q4sM12liWM6J9NCV3lNq6RypkOEqZxF5m2QRWs+0StLVzJiox+Tnq /VcOPsirv6swzniEy3YPH82YJKArsYfV7Wq0tF2xWfFfTHHoSm1VaXpGDE4klz7enNWy9sI2 u+hH0FW9q9PjMVNAR5+qwpAp80vpPx0Yb5499z40Uj2ZqAx0rkmNeDNKGfaujpjWmi+4NGiD 5wc/Fwx+VY24uoYcWZVTXLTS153UcMq/YnLs7kADAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrEIsWRmVeSWpSXmKPExsVy+t/xe7qXgnujDSa80LXo/tDCZHFjlb3F u0/bmSyutP9kt5i54DOjxdXj35kt3v9ZxGIxfUM/m8XWM38ZLfY/P8zuwOXxa8FSVo/Fe14y efRtWcUYwBylZ1OUX1qSqpCRX1xiqxRtaGGkZ2hpoWdkYqlnaGwea2VkqqRvZ5OSmpNZllqk b5eglzFl0iPWgv/6FR+mBzQw7tboYuTkkBAwkTi69h9jFyMXh5DAUkaJF9/eMUIkpCR+/LrA CmELS/y51sUGUfSeUaLn0T4mkISwQJTEmhlTwYpEBLQkFv57ww5iMwtcZ5JY+j8ComE9k8SC 51fAEmwCOhKnVh8B28ArYCexaNccZhCbRUBFYvLGr2A1ogIREquXv2CFqBGUODnzCQuIzSlg K/Fqzjw2iAXqEn/mXWKGsMUlmr6sZIWw5SW2v53DPIFRaBaS9llIWmYhaZmFpGUBI8sqRpHU 0uLc9NxiQ73ixNzi0rx0veT83E2MwPjbduzn5h2MlzYGH2IU4GBU4uENMOiNFmJNLCuuzD3E KMHBrCTC2+gOFOJNSaysSi3Kjy8qzUktPsRoCvTcRGYp0eR8YGrIK4k3NDU0t7A0NDc2Nzaz UBLnPW9QGSUkkJ5YkpqdmlqQWgTTx8TBKdXAWHTj/cbqe9mWwYlfew87Ge4IPnngW82hrJ3b e5d93RuefEHuaA6D/53kpcI1FTK/n9kuvlcfUxWlUxC6in/WRM1wq1euV7qW/fKZdMxiNjPT lxxGyXw3fzPXjU4MupLnAj7cNSv/cOLeSv67zCfNZeuMfgXs33b9crZQWL3orZWr6ksu5Ghb KrEUZyQaajEXFScCAP61RZjVAgAA Message-Id: <20180903153131eucas1p122e24d751d0f87d0cff88f3360c50e37~Q7ZOaSu4X0341203412eucas1p1A@eucas1p1.samsung.com> X-CMS-MailID: 20180903153131eucas1p122e24d751d0f87d0cff88f3360c50e37 X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20180831124404eucas1p20daff43600dfe450c9106616f886eab4 X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20180831124404eucas1p20daff43600dfe450c9106616f886eab4 References: <20180831124517.27619-1-i.maximets@samsung.com> <20180831124404eucas1p20daff43600dfe450c9106616f886eab4~P_LLRV5aM1664316643eucas1p2w@eucas1p2.samsung.com> Subject: Re: [dpdk-dev] [RFC 2/2] drivers/net: use sleep delay by default for intel NICs 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: Mon, 03 Sep 2018 15:31:34 -0000 On 03.09.2018 18:14, Wiles, Keith wrote: > > >> On Aug 31, 2018, at 1:45 PM, Ilya Maximets wrote: >> >> NICs uses different delays up to a second during their >> configuration. It makes no sense to busy-wait so long wasting >> CPU cycles and preventing any other threads to execute on the >> same CPU core. These busy polling are the rudiments that came >> from the kernel drivers where you can not sleep in interrupt >> context, but as we're in userspace, we're able and should >> sleep to allow other threads to run. >> Delays never called on rx/tx path, so this should not affect >> performance. > > I have a question, the only thread being effected by the busy wait is the thread assigned to the core or the master lcore in the case of rte_eal_init(). It should not effect other threads running on other cores, right? If you do have other threads running in the same code then I see the need, please help me understand the use and how it is effecting DPDK. Originally, this patch comes from this issue: http://mails.dpdk.org/archives/dev/2018-August/110640.html non-EAL threads is one of the answers. For example, main thread in OVS periodically checks the link statuses and hangs there busy waiting on different NIC configuration operations. Also, main OVS tread is responsible for port configuration and re-configuration. There are few other in-dpdk threads like interrupts handling thread (alarm handling thread). vhost_thread is working on the same lcores and wants some time to work too. In case of hyperthreading busy-waiting will significantly affect threads on the siblings. Best regards, Ilya Maximets. >> >> Signed-off-by: Ilya Maximets >> --- >> drivers/net/avf/Makefile | 1 + >> drivers/net/avf/base/avf_osdep.h | 4 ++-- >> drivers/net/e1000/Makefile | 1 + >> drivers/net/e1000/base/e1000_osdep.h | 2 +- >> drivers/net/i40e/base/i40e_osdep.h | 6 +++--- >> drivers/net/ifc/base/ifcvf_osdep.h | 2 +- >> drivers/net/ixgbe/base/ixgbe_osdep.h | 2 +- >> 7 files changed, 10 insertions(+), 8 deletions(-) >> >> diff --git a/drivers/net/avf/Makefile b/drivers/net/avf/Makefile >> index 3f815bbc4..8ee707529 100644 >> --- a/drivers/net/avf/Makefile >> +++ b/drivers/net/avf/Makefile >> @@ -9,6 +9,7 @@ include $(RTE_SDK)/mk/rte.vars.mk >> LIB = librte_pmd_avf.a >> >> CFLAGS += -O3 >> +CFLAGS += -DALLOW_EXPERIMENTAL_API >> LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool -lrte_ring >> LDLIBS += -lrte_ethdev -lrte_net -lrte_kvargs -lrte_hash >> LDLIBS += -lrte_bus_pci >> diff --git a/drivers/net/avf/base/avf_osdep.h b/drivers/net/avf/base/avf_osdep.h >> index 9ef45968e..442a5acd0 100644 >> --- a/drivers/net/avf/base/avf_osdep.h >> +++ b/drivers/net/avf/base/avf_osdep.h >> @@ -93,8 +93,8 @@ typedef uint64_t u64; >> #define avf_memset(a, b, c, d) memset((a), (b), (c)) >> #define avf_memcpy(a, b, c, d) rte_memcpy((a), (b), (c)) >> >> -#define avf_usec_delay(x) rte_delay_us(x) >> -#define avf_msec_delay(x) rte_delay_us(1000*(x)) >> +#define avf_usec_delay(x) rte_delay_us_sleep(x) >> +#define avf_msec_delay(x) avf_usec_delay(1000 * (x)) >> >> #define AVF_PCI_REG(reg) rte_read32(reg) >> #define AVF_PCI_REG_ADDR(a, reg) \ >> diff --git a/drivers/net/e1000/Makefile b/drivers/net/e1000/Makefile >> index 9c87e883b..0ed627656 100644 >> --- a/drivers/net/e1000/Makefile >> +++ b/drivers/net/e1000/Makefile >> @@ -10,6 +10,7 @@ LIB = librte_pmd_e1000.a >> >> CFLAGS += -O3 >> CFLAGS += $(WERROR_FLAGS) >> +CFLAGS += -DALLOW_EXPERIMENTAL_API >> LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool -lrte_ring >> LDLIBS += -lrte_ethdev -lrte_net -lrte_kvargs >> LDLIBS += -lrte_bus_pci >> diff --git a/drivers/net/e1000/base/e1000_osdep.h b/drivers/net/e1000/base/e1000_osdep.h >> index b8868049f..5958ea157 100644 >> --- a/drivers/net/e1000/base/e1000_osdep.h >> +++ b/drivers/net/e1000/base/e1000_osdep.h >> @@ -48,7 +48,7 @@ >> >> #include "../e1000_logs.h" >> >> -#define DELAY(x) rte_delay_us(x) >> +#define DELAY(x) rte_delay_us_sleep(x) >> #define usec_delay(x) DELAY(x) >> #define usec_delay_irq(x) DELAY(x) >> #define msec_delay(x) DELAY(1000*(x)) >> diff --git a/drivers/net/i40e/base/i40e_osdep.h b/drivers/net/i40e/base/i40e_osdep.h >> index 8e5c593c9..a6072e153 100644 >> --- a/drivers/net/i40e/base/i40e_osdep.h >> +++ b/drivers/net/i40e/base/i40e_osdep.h >> @@ -233,9 +233,9 @@ struct i40e_spinlock { >> #define i40e_memcpy(a, b, c, d) rte_memcpy((a), (b), (c)) >> >> #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d)) >> -#define DELAY(x) rte_delay_us(x) >> -#define i40e_usec_delay(x) rte_delay_us(x) >> -#define i40e_msec_delay(x) rte_delay_us(1000*(x)) >> +#define DELAY(x) rte_delay_us_sleep(x) >> +#define i40e_usec_delay(x) DELAY(x) >> +#define i40e_msec_delay(x) DELAY(1000 * (x)) >> #define udelay(x) DELAY(x) >> #define msleep(x) DELAY(1000*(x)) >> #define usleep_range(min, max) msleep(DIV_ROUND_UP(min, 1000)) >> diff --git a/drivers/net/ifc/base/ifcvf_osdep.h b/drivers/net/ifc/base/ifcvf_osdep.h >> index cf151ef52..6aef25ea4 100644 >> --- a/drivers/net/ifc/base/ifcvf_osdep.h >> +++ b/drivers/net/ifc/base/ifcvf_osdep.h >> @@ -17,7 +17,7 @@ >> #define DEBUGOUT(S, args...) RTE_LOG(DEBUG, PMD, S, ##args) >> #define STATIC static >> >> -#define msec_delay rte_delay_ms >> +#define msec_delay(x) rte_delay_us_sleep(1000 * (x)) >> >> #define IFCVF_READ_REG8(reg) rte_read8(reg) >> #define IFCVF_WRITE_REG8(val, reg) rte_write8((val), (reg)) >> diff --git a/drivers/net/ixgbe/base/ixgbe_osdep.h b/drivers/net/ixgbe/base/ixgbe_osdep.h >> index bb5dfd2af..94ede9bc2 100644 >> --- a/drivers/net/ixgbe/base/ixgbe_osdep.h >> +++ b/drivers/net/ixgbe/base/ixgbe_osdep.h >> @@ -51,7 +51,7 @@ >> >> #define ASSERT(x) if(!(x)) rte_panic("IXGBE: x") >> >> -#define DELAY(x) rte_delay_us(x) >> +#define DELAY(x) rte_delay_us_sleep(x) >> #define usec_delay(x) DELAY(x) >> #define msec_delay(x) DELAY(1000*(x)) >> >> -- >> 2.17.1 >> > > Regards, > Keith > > >