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 C37AEA0C40; Tue, 8 Jun 2021 14:36:27 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6305B40689; Tue, 8 Jun 2021 14:36:27 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id 767B14067A for ; Tue, 8 Jun 2021 14:36:26 +0200 (CEST) IronPort-SDR: 0tv+LDgiuDfdrJBUSA/SSQThw3V+XyLkJFw4+BNqmRwPMdS3MoNWlCzOAQmRNzLfG1VvvTVKYd phc3sQ8LRbSQ== X-IronPort-AV: E=McAfee;i="6200,9189,10008"; a="265986182" X-IronPort-AV: E=Sophos;i="5.83,258,1616482800"; d="scan'208";a="265986182" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2021 05:36:25 -0700 IronPort-SDR: UN3ecsBFWvtj28YdpeS47Ufoc51c3hFTCIvhg/DfMHEG0dVWEojdThDY+6d2nEAD7EOcwt9CM/ /31xHtAzFcfA== X-IronPort-AV: E=Sophos;i="5.83,258,1616482800"; d="scan'208";a="481931357" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.215.30]) ([10.213.215.30]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2021 05:36:23 -0700 To: Andrew Rybchenko , Thomas Monjalon , "Min Hu (Connor)" Cc: dev@dpdk.org, aman.deep.singh@intel.com, Anatoly Burakov References: <1614906276-34293-1-git-send-email-oulijun@huawei.com> <1619054288-17556-1-git-send-email-humin29@huawei.com> <2e30c1c4-4b6b-336f-3a31-a84979b7150f@oktetlabs.ru> <2021092.ZKMin5vSrh@thomas> <65e42e1c-8fb0-54f0-3bbb-daf4d19ac9af@oktetlabs.ru> From: Ferruh Yigit X-User: ferruhy Message-ID: <4507482e-d983-5658-b92a-fc53a847b3c3@intel.com> Date: Tue, 8 Jun 2021 13:36:19 +0100 MIME-Version: 1.0 In-Reply-To: <65e42e1c-8fb0-54f0-3bbb-daf4d19ac9af@oktetlabs.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v13] app/testpmd: support multi-process 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 6/8/2021 11:39 AM, Andrew Rybchenko wrote: > On 6/8/21 1:22 PM, Thomas Monjalon wrote: >> 08/06/2021 10:42, Andrew Rybchenko: >>> On 4/22/21 4:18 AM, Min Hu (Connor) wrote: >>>> --- a/doc/guides/testpmd_app_ug/run_app.rst >>>> +++ b/doc/guides/testpmd_app_ug/run_app.rst >> [...] >>>> +All the dev ops is supported in primary process. While secondary process is not permitted >>>> +to allocate or release shared memory, so some ops are not supported as follows:: >>>> +``dev_configure`` >>>> +``dev_start`` >>>> +``dev_stop`` >>>> +``rx_queue_setup`` >>>> +``tx_queue_setup`` >>>> +``rx_queue_release`` >>>> +``tx_queue_release`` >>> >>> @Thomas, @Ferrh, shouldn't it be handled on ethdev level as >>> well if it is really that strict. >> >> Yes it should be documented at ethdev level, not testpmd. >> I think it was kept fuzzy for too long. > > To document is good, but I'm talking about more - > add checks in corresponding API functions and > return error. > +Anatoly as multi process maintainer. There are already some PMDs have these checks in the PMD level. But current approach is providing more flexibility, if application takes care of the synchronization, is there any reason some of above APIs can't be used by the secondary process? I am not sure if this flexibility is used or needed, if not needed +1 have the checks in the ethdev layer and remove the PMD ones.