From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 8BA515F32 for ; Tue, 8 Jan 2019 10:20:08 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2019 01:20:07 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,453,1539673200"; d="scan'208";a="124279279" Received: from dhunt5-mobl2.ger.corp.intel.com (HELO [10.237.210.24]) ([10.237.210.24]) by orsmga002.jf.intel.com with ESMTP; 08 Jan 2019 01:20:06 -0800 To: "Yao, Lei A" , "dev@dpdk.org" References: <20190107113920.37748-1-david.hunt@intel.com> <2DBBFF226F7CF64BAFCA79B681719D95496063E4@shsmsx102.ccr.corp.intel.com> From: "Hunt, David" Message-ID: <450fa9eb-fedd-969a-fbb4-c98472cdb1f5@intel.com> Date: Tue, 8 Jan 2019 09:20:02 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <2DBBFF226F7CF64BAFCA79B681719D95496063E4@shsmsx102.ccr.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [dpdk-dev] [PATCH] examples/power: fix wrong core_id with JSON cmds 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: Tue, 08 Jan 2019 09:20:09 -0000 Hi Lei, On 8/1/2019 2:02 AM, Yao, Lei A wrote: > >> -----Original Message----- >> From: Hunt, David >> Sent: Monday, January 7, 2019 7:39 PM >> To: dev@dpdk.org >> Cc: Hunt, David ; Yao, Lei A >> Subject: [PATCH] examples/power: fix wrong core_id with JSON cmds >> >> This patch fixes a bug introduced in the 64-core limtation >> enhancement where the core_id is inadvertently converted from >> virtual to physical even though it may already be a physical >> core_id. >> >> We should be using the core_type field, and only converting via >> hypervisor when core_type is set to CORE_TYPE_VIRTUAL >> >> Fixes: 5776b7a371d1 ("examples/power: allow VM to use lcores over 63") >> >> Signed-off-by: David Hunt >> --- >> examples/vm_power_manager/channel_monitor.c | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/examples/vm_power_manager/channel_monitor.c >> b/examples/vm_power_manager/channel_monitor.c >> index 85622e7cb..1a3a0fa76 100644 >> --- a/examples/vm_power_manager/channel_monitor.c >> +++ b/examples/vm_power_manager/channel_monitor.c >> @@ -640,7 +640,10 @@ process_request(struct channel_packet *pkt, struct >> channel_info *chan_info) >> if (pkt->command == CPU_POWER) { >> unsigned int core_num; >> >> - core_num = get_pcpu(chan_info, pkt->resource_id); >> + if (pkt->core_type == CORE_TYPE_VIRTUAL) >> + core_num = get_pcpu(chan_info, pkt->resource_id); > Hi, Dave > > Now in DPDK code, only command send from VM(guest_cli sample) will set the > pkt- we always won't hit this branch. Because parse_json_to_pkt() will always set the > core_type to CORE_TYPE_PHYSICAL. > If resource_id in instruction format JSON file will always be treated as Pcpu, it's the > same as core_list behavior. Yes, that's correct.  But I believe it's OK for the moment. Currently the only way for the guest app to send commands and policies to the host is via the virtio-serial interface, which takes a different code path. There is no way currently for the guest app to send a JSON string to the host, so that code path will never be hit. However, now that the JSON functionality is in the host, we plan to add that same functionality to the guest, and when we do that we will ensure that core_type is handled appropriately. Regards, Dave. >> + else >> + core_num = pkt->resource_id; >> >> switch (pkt->unit) { >> case(CPU_POWER_SCALE_MIN): >> -- >> 2.17.1 > >