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 8652CA04B6; Mon, 12 Oct 2020 11:28:41 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3050D1D5F0; Mon, 12 Oct 2020 11:28:40 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 2F9321BCC5 for ; Mon, 12 Oct 2020 11:28:38 +0200 (CEST) IronPort-SDR: Nf3+bqyQR7dfmljLT0f9E9M51Z40x4JD9rNl3iaTF11G+lpM5PUO9ZuIdL9ehVlkLW59307ajy lh8tWiulqdYw== X-IronPort-AV: E=McAfee;i="6000,8403,9771"; a="153543652" X-IronPort-AV: E=Sophos;i="5.77,366,1596524400"; d="scan'208";a="153543652" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Oct 2020 02:28:36 -0700 IronPort-SDR: 6fac/M4rdneUhriJm6hP86kYVNfoTQ29/tvSeDuSl5GdzN83ZJF0RwMrxaM+h7OPPSfkS2Wi6O YjccInmFuxRA== X-IronPort-AV: E=Sophos;i="5.77,366,1596524400"; d="scan'208";a="344813114" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.213.195.67]) ([10.213.195.67]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Oct 2020 02:28:33 -0700 To: "Wang, Haiyue" , "dev@dpdk.org" Cc: "Ma, Liang J" , "Guo, Jia" , "Hunt, David" , "Ananyev, Konstantin" , "jerinjacobk@gmail.com" , "Richardson, Bruce" , "thomas@monjalon.net" , "McDaniel, Timothy" , "Eads, Gage" , "Macnamara, Chris" References: <1601647919-25312-1-git-send-email-liang.j.ma@intel.com> From: "Burakov, Anatoly" Message-ID: <3325ec05-e7e6-ccf3-75e5-98c02fe741e5@intel.com> Date: Mon, 12 Oct 2020 10:28:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 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] [PATCH v5 06/10] net/ixgbe: implement power management API 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 12-Oct-20 9:09 AM, Wang, Haiyue wrote: > Hi Liang, > >> -----Original Message----- >> From: Burakov, Anatoly >> Sent: Saturday, October 10, 2020 00:02 >> To: dev@dpdk.org >> Cc: Ma, Liang J ; Guo, Jia ; Wang, Haiyue >> ; Hunt, David ; Ananyev, Konstantin >> ; jerinjacobk@gmail.com; Richardson, Bruce ; >> thomas@monjalon.net; McDaniel, Timothy ; Eads, Gage ; >> Macnamara, Chris >> Subject: [PATCH v5 06/10] net/ixgbe: implement power management API >> >> From: Liang Ma >> >> Implement support for the power management API by implementing a >> `get_wake_addr` function that will return an address of an RX ring's >> status bit. >> >> Signed-off-by: Anatoly Burakov >> Signed-off-by: Liang Ma >> --- >> drivers/net/ixgbe/ixgbe_ethdev.c | 1 + >> drivers/net/ixgbe/ixgbe_rxtx.c | 22 ++++++++++++++++++++++ >> drivers/net/ixgbe/ixgbe_rxtx.h | 2 ++ >> 3 files changed, 25 insertions(+) >> > > >> >> +int ixgbe_get_wake_addr(void *rx_queue, volatile void **tail_desc_addr, >> +uint64_t *expected, uint64_t *mask) >> +{ >> +volatile union ixgbe_adv_rx_desc *rxdp; >> +struct ixgbe_rx_queue *rxq = rx_queue; >> +uint16_t desc; >> + >> +desc = rxq->rx_tail; >> +rxdp = &rxq->rx_ring[desc]; >> +/* watch for changes in status bit */ >> +*tail_desc_addr = &rxdp->wb.upper.status_error; >> + >> +/* >> + * we expect the DD bit to be set to 1 if this descriptor was already >> + * written to. >> + */ >> +*expected = rte_cpu_to_le_32(IXGBE_RXDADV_STAT_DD); >> +*mask = rte_cpu_to_le_32(IXGBE_RXDADV_STAT_DD); >> + > > Seems have one issue about the byte endian: > Like for BIG endian: > *expected = rte_bswap32(IXGBE_RXDADV_STAT_DD) > != > *expected = rte_bswap64(IXGBE_RXDADV_STAT_DD) > > And in API 'rte_power_monitor', use uint64_t type to access the wake up > data: > > static inline void rte_power_monitor(const volatile void *p, > const uint64_t expected_value, const uint64_t value_mask, > const uint64_t tsc_timestamp) > { > if (value_mask) { > const uint64_t cur_value = *(const volatile uint64_t *)p; > const uint64_t masked = cur_value & value_mask; > /* if the masked value is already matching, abort */ > if (masked == expected_value) > return; > } > > > So that we need the wake up address type like 16/32/64b ? Endian differences strike again! You're right of course. I suspect casting everything to CPU endinanness would fix it, would it not? > >> -- >> 2.17.1 -- Thanks, Anatoly