From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 94DC7A04DD; Wed, 28 Oct 2020 17:21:58 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 10AFA68C3; Wed, 28 Oct 2020 17:21:57 +0100 (CET) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 769FE3976 for ; Wed, 28 Oct 2020 17:21:54 +0100 (CET) IronPort-SDR: I8h/t4UXShQBrWLGF+F8zHdPmrMyLa3A7bFockO5+GA68NMcmvylGQVnCMqhCyEcXS/O1goW3z WHAc5+L1nZWg== X-IronPort-AV: E=McAfee;i="6000,8403,9788"; a="232468077" X-IronPort-AV: E=Sophos;i="5.77,427,1596524400"; d="scan'208";a="232468077" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Oct 2020 09:21:52 -0700 IronPort-SDR: FsNh42mnT0XC95oM+Hl5HZSkQyDb3n4MPR8e3M+Pj8pnRTmbOKhpuJBbeSQm2lYr8q+V35IDGd Ee65uLherqWg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,427,1596524400"; d="scan'208";a="536294057" Received: from irvmail001.ir.intel.com ([163.33.26.43]) by orsmga005.jf.intel.com with ESMTP; 28 Oct 2020 09:21:48 -0700 Received: from sivswdev09.ir.intel.com (sivswdev09.ir.intel.com [10.237.217.48]) by irvmail001.ir.intel.com (8.14.3/8.13.6/MailSET/Hub) with ESMTP id 09SGLmua022525; Wed, 28 Oct 2020 16:21:48 GMT Received: from sivswdev09.ir.intel.com (localhost [127.0.0.1]) by sivswdev09.ir.intel.com with ESMTP id 09SGLlGZ014543; Wed, 28 Oct 2020 16:21:47 GMT Received: (from lma25@localhost) by sivswdev09.ir.intel.com with LOCAL id 09SGLlmt014508; Wed, 28 Oct 2020 16:21:47 GMT Date: Wed, 28 Oct 2020 16:21:47 +0000 From: "Liang, Ma" To: Jerin Jacob Cc: "Ananyev, Konstantin" , Thomas Monjalon , dpdk-dev , "Ruifeng Wang (Arm Technology China)" , "Wang, Haiyue" , "Richardson, Bruce" , "Hunt, David" , Neil Horman , "McDaniel, Timothy" , "Eads, Gage" , Marcin Wojtas , Guy Tzalik , Ajit Khaparde , Harman Kalra , John Daley , "Wei Hu (Xavier" , Ziyang Xuan , "matan@nvidia.com" , Yong Wang , "david.marchand@redhat.com" Message-ID: <20201028162147.GF29706@sivswdev09.ir.intel.com> References: <1603494392-7181-1-git-send-email-liang.j.ma@intel.com> <20201028133507.GC29706@sivswdev09.ir.intel.com> <2373759.1G5EZAqFcn@thomas> <20201028153026.GD29706@sivswdev09.ir.intel.com> <20201028154440.GE29706@sivswdev09.ir.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [PATCH v10 0/9] Add PMD power mgmt 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 28 Oct 21:31, Jerin Jacob wrote: > On Wed, Oct 28, 2020 at 9:14 PM Liang, Ma wrote: > > > > On 28 Oct 21:06, Jerin Jacob wrote: > > > On Wed, Oct 28, 2020 at 9:00 PM Liang, Ma wrote: > > > > > > > > On 28 Oct 20:44, Jerin Jacob wrote: > > > > > On Wed, Oct 28, 2020 at 8:27 PM Ananyev, Konstantin > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > 28/10/2020 14:49, Jerin Jacob: > > > > > > > > On Wed, Oct 28, 2020 at 7:05 PM Liang, Ma wrote: > > > > > > > > > > > > > > > > > > Hi Thomas, > > > > > > > > > I think I addressed all of the questions in relation to V9. I don't think I can solve the issue of a generic API on my own. From the > > > > > > > Community Call last week Jerin also said that a generic was investigated but that a single solution wasn't feasible. > > > > > > > > > > > > > > > > I think, From the architecture point of view, the specific > > > > > > > > functionally of UMONITOR may not be abstracted. > > > > > > > > But from the ethdev callback point of view, Can it be abstracted in > > > > > > > > such a way that packet notification available through > > > > > > > > checking interrupt status register or ring descriptor location, etc by > > > > > > > > the driver. Use that callback as a notification mechanism rather > > > > > > > > than defining a memory-based scheme that UMONITOR expects? or similar > > > > > > > > thoughts on abstraction. > > > > > > > > > > > > I think there is probably some sort of misunderstanding. > > > > > > This API is not about providing acync notification when next packet arrives. > > > > > > This is about to putting core to sleep till some event (or timeout) happens. > > > > > > From my perspective the closest analogy: cond_timedwait(). > > > > > > So we need PMD to tell us what will be the address of the condition variable > > > > > > we should sleep on. > > > > > > > > > > > > > I agree with Jerin. > > > > > > > The ethdev API is the blocking problem. > > > > > > > First problem: it is not well explained in doxygen. > > > > > > > Second problem: it is probably not generic enough (if we understand it well) > > > > > > > > > > > > It is an address to sleep(/wakeup) on, plus expected value. > > > > > > Honestly, I can't think-up of anything even more generic then that. > > > > > > If you guys have something particular in mind - please share. > > > > > > > > > > Current PMD callback: > > > > > typedef int (*eth_get_wake_addr_t)(void *rxq, volatile void > > > > > **tail_desc_addr, + uint64_t *expected, uint64_t *mask, uint8_t > > > > > *data_sz); > > > > > > > > > > Can we make it as > > > > > typedef void (*core_sleep_t)(void *rxq) > > > > How about void (*eth_core_sleep_helper_t)(void *rxq, enum scheme, void *paramter) > > > > by this way, PMD can cast the parameter accorind to the scheme. > > > > e.g. if scheme MEM_MONITOR then cast to umwait way. > > > > however, this will introduce another problem. > > > > we need add PMD query callback to figure out if PMD support this scheme. > > > > > > I thought scheme/policy something that "application cares" like below > > > not arch specifics > > > 1) wakeup up on first packet, > > > 2) wake me up on first packet or timeout 100 us etc > > I need clarify about current design a bit. the purposed API just get target address. > > the API itself(include the PMD callback) will not demand the processor to idle/sleep. > > we use the post rx callback to do that. for ethdev layer, this API only is used to > > fetch target address from PMD, which make minmal impact to existing code. > > I understand that. But if we move that logic to common code in ethdev > as a set of internal > PMD helper functions(Helper functions for class of devices and/or > arch) then it should be > possible. Right? Although that's possible, but power manangment logic will be duplicated in all related PMD. Advantage of current design is decouple power mgmt logic with PMD, just need minmal help from PMD. there are 3 scheme already which are implemented as post rx callback. Put all power mgmt logic into PMD is way too heavy. Also current design is very easy to extend. Any new scheme has no impact to ethdev layer unless it need some kind of help from PMD. we have another 2 scheme, PAUSE and Freq Scale dont not need any PMD help. > I do understand that, It will call for some rework in the code. I will > leave up to ethdev maintainers > on specifics. > > > > > > > Yes. We can have query on type of the policies supported. > > > > > > > > > > > > > > > > if we do such abstraction and "move the polling on memory by HW/CPU" > > > > > to the driver using a helper function then > > > > > I can think of abstracting in some way in all PMDs. > > > > > > > > > > Note: core_sleep_t can take some more arguments such as enumerated > > > > > policy if something more needs to be pushed to the driver. > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > > > > > > > > > > This API is experimental and other vendor support can be added as needed. If there are any other open issue let me know? > > > > > > > > > > > > > > Being experimental is not an excuse to throw something > > > > > > > which is not satisfying. > > > > > > > > > > > > > > > > > > > >