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 06E82A0548; Thu, 27 May 2021 15:06:43 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B97A640150; Thu, 27 May 2021 15:06:42 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mails.dpdk.org (Postfix) with ESMTP id 3301D40143 for ; Thu, 27 May 2021 15:06:41 +0200 (CEST) IronPort-SDR: kJQeeeYTFXbk/XjsG84ttY3sZTS8IsjP2gnLWQLmtfUXJF/62QrqFDBsbc2MfNSSOjclZAhY3K uFq74B7R2cig== X-IronPort-AV: E=McAfee;i="6200,9189,9996"; a="189844678" X-IronPort-AV: E=Sophos;i="5.82,334,1613462400"; d="scan'208";a="189844678" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 May 2021 06:06:39 -0700 IronPort-SDR: OIJlIa72wZTKP2GyqLUnL+pbbi4TY+GULjWwCdRVh04P/9tX++pbQEVYlKDHmAkaWQz64h29pk aHZUFOQyKHxw== X-IronPort-AV: E=Sophos;i="5.82,334,1613462400"; d="scan'208";a="477477045" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.213.228.168]) ([10.213.228.168]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 May 2021 06:06:36 -0700 To: "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" , "Ananyev, Konstantin" Cc: "Loftus, Ciara" References: <819ef1ace187365a615d3383e54579e3d9fb216e.1620747068.git.anatoly.burakov@intel.com> <4b05f3b389e04e098ab298f49b97d6a2@intel.com> From: "Burakov, Anatoly" Message-ID: Date: Thu, 27 May 2021 14:06:33 +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: <4b05f3b389e04e098ab298f49b97d6a2@intel.com> Content-Type: text/plain; charset=windows-1252; 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 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? -- Thanks, Anatoly