From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6C7C8A0524; Tue, 1 Jun 2021 16:21:40 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E107140DF7; Tue, 1 Jun 2021 16:21:39 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by mails.dpdk.org (Postfix) with ESMTP id E277740689 for ; Tue, 1 Jun 2021 16:21:38 +0200 (CEST) IronPort-SDR: Yia0VaR82967lzeOSKEYDFq01oGNc4yo0d38OlR4pDcCzbGpZuhm5O0hCXuZct1s+gnj4d15xH JZDEIzUi0dxg== X-IronPort-AV: E=McAfee;i="6200,9189,10002"; a="289176145" X-IronPort-AV: E=Sophos;i="5.83,240,1616482800"; d="scan'208";a="289176145" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jun 2021 07:21:38 -0700 IronPort-SDR: JeoyiJtA356HM/LFyUj1/phCXdD+O0Lh2D2vDCe3+Ge9lkndVgYXUC6eSAf8a4gbXmsDmI4N5u 1N8nALRcan7A== X-IronPort-AV: E=Sophos;i="5.83,240,1616482800"; d="scan'208";a="474263876" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.213.212.41]) ([10.213.212.41]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jun 2021 07:21:35 -0700 To: "Ananyev, Konstantin" , "Liu, Yong" , "dev@dpdk.org" , "McDaniel, Timothy" , "Xing, Beilei" , "Wu, Jingjing" , "Yang, Qiming" , "Zhang, Qi Z" , "Wang, Haiyue" , Matan Azrad , Shahaf Shuler , Viacheslav Ovsiienko , "Richardson, Bruce" , "Li, Miao" Cc: "Loftus, Ciara" References: <819ef1ace187365a615d3383e54579e3d9fb216e.1620747068.git.anatoly.burakov@intel.com> <4b05f3b389e04e098ab298f49b97d6a2@intel.com> From: "Burakov, Anatoly" Message-ID: <88964ff5-7efb-87ae-90ba-4f0288361a21@intel.com> Date: Tue, 1 Jun 2021 15:21:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [21.08 PATCH v1 1/2] power: invert the monitor check X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 28-May-21 10:09 AM, Ananyev, Konstantin wrote: > >>> >>> On 25-May-21 10:15 AM, Liu, Yong wrote: >>>> >>>> >>>>> -----Original Message----- >>>>> From: dev On Behalf Of Anatoly Burakov >>>>> Sent: Tuesday, May 11, 2021 11:32 PM >>>>> To: dev@dpdk.org; McDaniel, Timothy ; >>> Xing, >>>>> Beilei ; Wu, Jingjing ; Yang, >>>>> Qiming ; Zhang, Qi Z ; >>>>> Wang, Haiyue ; Matan Azrad >>>>> ; Shahaf Shuler ; Viacheslav >>>>> Ovsiienko ; Richardson, Bruce >>>>> ; Ananyev, Konstantin >>>>> >>>>> Cc: Loftus, Ciara >>>>> Subject: [dpdk-dev] [21.08 PATCH v1 1/2] power: invert the monitor check >>>>> >>>>> Previously, the semantics of power monitor were such that we were >>>>> checking current value against the expected value, and if they matched, >>>>> then the sleep was aborted. This is somewhat inflexible, because it only >>>>> allowed us to check for a specific value. >>>>> >>>>> We can reverse the check, and instead have monitor sleep to be aborted >>>>> if the expected value *doesn't* match what's in memory. This allows us >>>>> to both implement all currently implemented driver code, as well as >>>>> support more use cases which don't easily map to previous semantics >>>>> (such as waiting on writes to AF_XDP counter value). >>>>> >>>> >>>> Hi Anatoly, >>>> In virtio spec, packed formatted descriptor utilizes two bits for representing >>> the status. One bit for available status, one bit for used status. >>>> For checking the status more precisely, it is need to check value against the >>> expected value. >>>> The monitor function in virtio datapath still can work with new semantics, >>> but it may lead to some useless io call. >>>> Base on that, I'd like to keep previous semantics. >>>> >>>> Regards, >>>> Marvin >>>> >>> >>> Thanks for your feedback! Would making this an option make things >>> better? Because we need the inverted semantics for AF_XDP, it can't work >>> without it. So, we either invert all of them, or we have an option to do >>> regular or inverted check on a per-condition basis. Would that work? >>> >> >> That will be great if we can select the check type based on input parameter. >> Just in virtio datapath, we need both inverted and original semantics for different ring formats. >> > > Should we probably the consider introducing _check_ callback to be provided by PMD? > So we can leave these various check details inside PMD itself. > And monitor will just read the specified address and call the callback. > Konstantin > Getting monitor condition *is* "the check" IMO. I think adding an option to the comparison should cover pretty much all worthwhile use cases without overcomplicating things. In any case, patches already sent [1] :) [1] http://patches.dpdk.org/project/dpdk/list/?series=17191 -- Thanks, Anatoly