From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5F80BC73C50 for ; Tue, 9 Jul 2019 15:12:38 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id F2F312166E for ; Tue, 9 Jul 2019 15:12:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F2F312166E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A2D4B1B99F; Tue, 9 Jul 2019 17:12:33 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id EAF701B997 for ; Tue, 9 Jul 2019 17:12:31 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jul 2019 08:12:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,470,1557212400"; d="scan'208";a="165789318" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.237.220.82]) ([10.237.220.82]) by fmsmga008.fm.intel.com with ESMTP; 09 Jul 2019 08:12:28 -0700 To: David Hunt , dev@dpdk.org Cc: lukaszx.gosiewski@intel.com, Marcin Hajkowski , Lukasz Krakowiak References: <20190613092117.7252-2-marcinx.hajkowski@intel.com> <20190709150753.15732-1-david.hunt@intel.com> From: "Burakov, Anatoly" Message-ID: Date: Tue, 9 Jul 2019 16:12:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20190709150753.15732-1-david.hunt@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v5] power: add fifo per core for JSON interface 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 09-Jul-19 4:07 PM, David Hunt wrote: > From: Marcin Hajkowski > > This patch implements a separate FIFO for each cpu core to improve the > previous functionality where anyone with access to the FIFO could affect > any core on the system. By using appropriate permissions, fifo interfaces > can be configured to only affect the particular cores. > > Because each FIFO is per core, the following fields have been removed > from the command JSON format: core_list, resource_id, name. > > Signed-off-by: Lukasz Krakowiak > Signed-off-by: Lukasz Gosiewski > Signed-off-by: Marcin Hajkowski > Tested-by: David Hunt > > --- > v2: > * updated handling vm_name (use proper buff size) > * rebase to master changes > > v3: > * improvement to coding style > > v4: > * rebase to tip of master > > v5: > * merged docs into same patch as the code, as per mailing list policy > * made changes out of review by Anatoly. > --- > - if (setup_host_channel_info(&chan_info, 0) < 0) { > - rte_free(chan_info); > - return 0; > + ret = fifo_path(socket_path, sizeof(socket_path), i); > + if (ret < 0) > + goto error; > + > + ret = mkfifo(socket_path, 0660); > + RTE_LOG(DEBUG, CHANNEL_MANAGER, "TRY CREATE fifo '%s'\n", > + socket_path); > + if ((errno != EEXIST) && (ret < 0)) { > + RTE_LOG(ERR, CHANNEL_MANAGER, "Cannot create fifo '%s' error: " > + "%s\n", socket_path, strerror(errno)); > + goto error; > + } > + chan_info = rte_malloc(NULL, sizeof(*chan_info), 0); > + if (chan_info == NULL) { > + RTE_LOG(ERR, CHANNEL_MANAGER, "Error allocating memory for " > + "channel '%s'\n", socket_path); > + goto error; > + } > + chan_infos[i] = chan_info; > + rte_strlcpy(chan_info->channel_path, socket_path, > + sizeof(chan_info->channel_path)); > + > + if (setup_host_channel_info(&chan_info, i) < 0) { > + rte_free(chan_info); > + chan_infos[i] = NULL; > + goto error; > + } > + num_channels_enabled++; > } > - num_channels_enabled++; > > return num_channels_enabled; > +error: > + /* Clean up the channels opened before we hit an error. */ > + for (i = 0; i < RTE_MAX_LCORE; i++) { You're going up to RTE_MAX_LCORE here, but up to ci->core_count in the original loop. Is that intentional? Other than that, Acked-by: Anatoly Burakov -- Thanks, Anatoly