From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout1.w1.samsung.com (mailout1.w1.samsung.com [210.118.77.11]) by dpdk.org (Postfix) with ESMTP id 572B81B203 for ; Fri, 5 Oct 2018 16:41:58 +0200 (CEST) Received: from eucas1p2.samsung.com (unknown [182.198.249.207]) by mailout1.w1.samsung.com (KnoxPortal) with ESMTP id 20181005144157euoutp01ed10248911fd98f9956bbf2fe7e4d34f~avXFXkWMH0195401954euoutp01p for ; Fri, 5 Oct 2018 14:41:57 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20181005144157euoutp01ed10248911fd98f9956bbf2fe7e4d34f~avXFXkWMH0195401954euoutp01p DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1538750517; bh=peE204DvhnhFzaykwDe9dfATXgqhkWJe3qUUYiP4l5k=; h=Subject:To:Cc:From:Date:In-Reply-To:References:From; b=M0ksPKy09G5XVdEN2KUQ2FJw8TXLGjM08tq7gsDenpiRvjyHOsYCIOJ/JLZQoh4Fp j2XcBHLf1UVa93b1rcf0gZB2N8z7RlukwZ66DBFghXMWiAooDF484wFg2j5LH03e4S zT7znjGARDik6F9XFwkHw1ZQZjhQu5lD2aVAjNgg= Received: from eusmges3new.samsung.com (unknown [203.254.199.245]) by eucas1p2.samsung.com (KnoxPortal) with ESMTP id 20181005144156eucas1p2550a14190d15d8967a39b0daa0a53892~avXE5sV9I2637926379eucas1p2k; Fri, 5 Oct 2018 14:41:56 +0000 (GMT) Received: from eucas1p2.samsung.com ( [182.198.249.207]) by eusmges3new.samsung.com (EUCPMTA) with SMTP id 96.72.04806.43877BB5; Fri, 5 Oct 2018 15:41:56 +0100 (BST) Received: from eusmtrp1.samsung.com (unknown [182.198.249.138]) by eucas1p1.samsung.com (KnoxPortal) with ESMTPA id 20181005144155eucas1p17ea3717e6772e390d02bc9ce44e50a8d~avXEH-nZ31850018500eucas1p1L; Fri, 5 Oct 2018 14:41:55 +0000 (GMT) Received: from eusmgms1.samsung.com (unknown [182.198.249.179]) by eusmtrp1.samsung.com (KnoxPortal) with ESMTP id 20181005144155eusmtrp19787076de3a4f5a07dded310ad259e2d~avXD1n0f81790617906eusmtrp1H; Fri, 5 Oct 2018 14:41:55 +0000 (GMT) X-AuditID: cbfec7f5-34dff700000012c6-19-5bb77834dadc Received: from eusmtip2.samsung.com ( [203.254.199.222]) by eusmgms1.samsung.com (EUCPMTA) with SMTP id C7.ED.04284.33877BB5; Fri, 5 Oct 2018 15:41:55 +0100 (BST) Received: from [106.109.129.180] (unknown [106.109.129.180]) by eusmtip2.samsung.com (KnoxPortal) with ESMTPA id 20181005144154eusmtip25b1babf729d73806965e94332e430598~avXDQxPxl0624606246eusmtip2L; Fri, 5 Oct 2018 14:41:54 +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: Fri, 5 Oct 2018 17:44:16 +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: H4sIAAAAAAAAA+NgFtrAKsWRmVeSWpSXmKPExsWy7djP87omFdujDVpuSlh0f2hhsrixyt7i 3aftTBZX2n+yW8xc8JnR4urx78wW7/8sYrGYvqGfzWLrmb+MFvufH2Z34PL4tWApq8fiPS+Z PPq2rGIMYI7isklJzcksSy3St0vgymibvIatYJZQxfneR+wNjPt5uxg5OSQETCQ2tv1n7mLk 4hASWMEo8XbJVCjnC6PEnYPdLBDOZ0aJ/+33mGBa/q36zAiRWM4o8XTlcSjnI6PEjL/fWUCq hAVsJe5cewJmiwhoSSz894YdpIhZ4CqTRMvBz+wgCTYBHYlTq48wgtgsAioSLU0f2EBsUYEI iSMPFoLFeQUEJU7OhBjECTS0ffMyMJtZQFyi6ctKVghbXmL72zlgh0sIbGOXaO9tBrqVA6i5 TOL//yyIs10kOs/OY4GwhSVeHd/CDmHLSJye3AMVr5e43/KSEWJOB6PE9EP/oH62l9jy+hw7 yExmAU2J9bv0IcKOEmentbCBhCUE+CRuvBWEOIdPYtK26cwQYV6JjjYhiGoVid8HlzND2FIS N999Zp/AqDQLyZOzkDw2C8ljsxD2LmBkWcUonlpanJueWmycl1quV5yYW1yal66XnJ+7iRGY jk7/O/51B+O+P0mHGAU4GJV4eF8ob4sWYk0sK67MPcQowcGsJMK7J357tBBvSmJlVWpRfnxR aU5q8SFGaQ4WJXHeZfM2RgsJpCeWpGanphakFsFkmTg4pRoYTx3pnRI+715+VnHP1FNrn7xt VDR5bTvXetPK1PUcvo2c/tE1KQEHZLqKZvzf+qDpr7RA0WHG214/lYxKTJNXXdjVOj99atza S2eML85p5l73q2nr32aWZ0zrn4t/L3IKfKXt/X/dkR+q2/ravLbcvvci7v7T7o23a3fNUZM/ uXb14Svmmz/ndyuxFGckGmoxFxUnAgBL59yiQwMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRmVeSWpSXmKPExsVy+t/xe7rGFdujDX5fV7Do/tDCZHFjlb3F u0/bmSyutP9kt5i54DOjxdXj35kt3v9ZxGIxfUM/m8XWM38ZLfY/P8zuwOXxa8FSVo/Fe14y efRtWcUYwBylZ1OUX1qSqpCRX1xiqxRtaGGkZ2hpoWdkYqlnaGwea2VkqqRvZ5OSmpNZllqk b5egl9E2eQ1bwSyhivO9j9gbGPfzdjFyckgImEj8W/WZEcQWEljKKHHjfBREXErix68LrBC2 sMSfa11sEDXvGSV2H60FsYUFbCXuXHvCAmKLCGhJLPz3hh3EZha4ziSx9H9EFyMXUP0rJokV u5YwgyTYBHQkTq0+AraMV8BOYvqyiWALWARUJFqaPoAtEBWIkFi9/AUrRI2gxMmZEAs4gZa1 b17GArFAXeLPvEvMELa4RNOXlawQtrzE9rdzmCcwCs1C0j4LScssJC2zkLQsYGRZxSiSWlqc m55bbKhXnJhbXJqXrpecn7uJERh924793LyD8dLG4EOMAhyMSjy8L5S3RQuxJpYVV+YeYpTg YFYS4d0Tvz1aiDclsbIqtSg/vqg0J7X4EKMp0HMTmaVEk/OBiSGvJN7Q1NDcwtLQ3Njc2MxC SZz3vEFllJBAemJJanZqakFqEUwfEwenVAPjJLe6m4HNC7R4fNalKRfaGS+uPb1068oYrmz2 KzlSdqV3tEJSXs35v0n3KTfPzCeLLftXzp6ZPP3BhsIdplye11rdQy3uSE7fm2bcvPDNir/G ftXPG6Yt1dxqVnX5Ekvpn4MCt0s+bjcrPB3U9Urzeunu10feMrccK/hVXStTsM108fR7uvKc SizFGYmGWsxFxYkAkNQUytQCAAA= Message-Id: <20181005144155eucas1p17ea3717e6772e390d02bc9ce44e50a8d~avXEH-nZ31850018500eucas1p1L@eucas1p1.samsung.com> X-CMS-MailID: 20181005144155eucas1p17ea3717e6772e390d02bc9ce44e50a8d X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20180903144311eucas1p2b6499c49dbd0d54334e973113cdc5ad6 X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20180903144311eucas1p2b6499c49dbd0d54334e973113cdc5ad6 References: <20180831124358eucas1p22a0f8a7d0ae34dfad73b3b9e819366ec~P_LFZr9ro1664316643eucas1p2m@eucas1p2.samsung.com> <20180903144311eucas1p2b6499c49dbd0d54334e973113cdc5ad6~Q6vBsFYRm1033710337eucas1p2D@eucas1p2.samsung.com> Subject: Re: [dpdk-dev] [PATCH v1 0/2] CPU non-blocking delay 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: Fri, 05 Oct 2018 14:41:58 -0000 On 05.10.2018 17:09, Wiles, Keith wrote: > > >> On Sep 3, 2018, at 9:44 AM, Ilya Maximets wrote: >> >> For meson build without deprecation warnings following >> patch should be applied first: >> http://patches.dpdk.org/patch/44129/ > > Not to be super picky (OK I am super picky sometimes) can we change the name of the function rte_delay_us_sleep() to rte_sleep_us() the reason is delay and sleep conflict IMO. The rte_sleep_us() tells me it sleeps, which is a form of delay, but delay in DPDK assume busy wait. I'm not sure about this, because this function intended to be used as 'rte_delay_us_callback', i.e. as implementation of 'rte_delay_us()'. IMO, it should state that it is the part of this API and that it sleeps internally at the same time. So I tried to combine both "delay" and "sleep" in one function name. If we'll change the name to 'rte_sleep_us' it will look like alternative to 'rte_delay_us', but it's one of its implementations. 'rte_delay_us_sleep' should be alternative to 'rte_delay_us_block()'. I'd like to call it 'rte_delay_us_nonblock()', but it may be way more confusing. What do you think? >> >> Ilya Maximets (2): >> eal: add nanosleep based delay function >> drivers/net: use sleep delay by default for intel NICs >> >> 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/e1000/meson.build | 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 +- >> drivers/net/ixgbe/meson.build | 3 +- >> lib/librte_eal/common/eal_common_timer.c | 19 +++++++ >> .../common/include/generic/rte_cycles.h | 11 ++++ >> lib/librte_eal/rte_eal_version.map | 1 + >> test/test/autotest_data.py | 6 +++ >> test/test/meson.build | 1 + >> test/test/test_cycles.c | 51 ++++++++++++++----- >> 15 files changed, 89 insertions(+), 23 deletions(-) >> >> -- >> 2.17.1 >> > > Regards, > Keith > > >