From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 59E881BE0D for ; Wed, 4 Jul 2018 03:11:20 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jul 2018 18:11:18 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,306,1526367600"; d="scan'208";a="51823551" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga007.fm.intel.com with ESMTP; 03 Jul 2018 18:11:18 -0700 Received: from fmsmsx158.amr.corp.intel.com (10.18.116.75) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 3 Jul 2018 18:11:01 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx158.amr.corp.intel.com (10.18.116.75) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 3 Jul 2018 18:11:00 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.124]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.17]) with mapi id 14.03.0319.002; Wed, 4 Jul 2018 09:08:33 +0800 From: "Zhang, Qi Z" To: Thomas Monjalon CC: "dev@dpdk.org" , "Burakov, Anatoly" , "Ananyev, Konstantin" , "Richardson, Bruce" , "Yigit, Ferruh" , "Shelton, Benjamin H" , "Vangati, Narender" Thread-Topic: [dpdk-dev] [PATCH v8 02/19] eal: enable multi process init callback Thread-Index: AQHUEcfCcYYh8URWxEq1ktWm4RGmsaR8tnwAgADl0YD//+npgIAAukkg Date: Wed, 4 Jul 2018 01:08:32 +0000 Message-ID: <039ED4275CED7440929022BC67E7061153249C86@shsmsx102.ccr.corp.intel.com> References: <20180607123849.14439-1-qi.z.zhang@intel.com> <3358274.MJj7BZBBQ7@xps> <039ED4275CED7440929022BC67E7061153243598@SHSMSX103.ccr.corp.intel.com> <2121919.otauVgk3WW@xps> In-Reply-To: <2121919.otauVgk3WW@xps> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjUwNzNmZjUtN2RlZC00YjNiLTkyMjUtMmJiZDdlY2FlZmIxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiSFMyNVJ2b0ozRW9tMmU5K2o5Y0tPVEQ2cHk0MWc0Mis5MHcxck5oMzZPbERrYUgzcGRndFBOeHppSUpSREpabSJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v8 02/19] eal: enable multi process init callback 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: Wed, 04 Jul 2018 01:11:21 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Wednesday, July 4, 2018 5:51 AM > To: Zhang, Qi Z > Cc: dev@dpdk.org; Burakov, Anatoly ; Ananyev, > Konstantin ; Richardson, Bruce > ; Yigit, Ferruh ; She= lton, > Benjamin H ; Vangati, Narender > > Subject: Re: [dpdk-dev] [PATCH v8 02/19] eal: enable multi process init c= allback >=20 > 03/07/2018 17:16, Zhang, Qi Z: > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > > > > Hi Qi, > > > > > > Sorry I do not understand neither the commit log, nor the doxygen. > > > If it can help, consider your reader is in a bad mood and needs a > > > pleasant description. > > > > OK, I think is not a grammar issue since it almost passed a grammar > > check :) > > > > So more explanation: > > Basically we need to register mp action callback in ethdev layer, >=20 > What is "mp action callback"? rte_mp_action_register(ETH_DEV_MP_ACTION_REQUEST, handle_secondary_request)= ; in this case ETH_DEV_MP_ACTION_REQUEST is the action, and handle_secondary_request is the callback which will be invoked when the= action received from another process. > Why do you need it in ethdev? Based on current implementation, IPC is required during dev_attach/dev_deta= ch. so we need to make sure callback is registered before that happen. >=20 > > but this should happens during rte_eal_init >=20 > Why it should be done in rte_eal_init? Either we can expose an ethdev API like rte_eth_dev_mp_init, to let applica= tion do this explicitly, or we can let application assume all necessary cal= lback has been registered when DPDK is initialized. (rte_eal_init) >=20 > > ethdev don't have a general init function that can be invoked by eal > > during rte_eal_init, actually I guess, all no-eal module don't have >=20 > What is "no-eal module"? A module like lib_ethdev which lib_eal should not depend on. >=20 > > in vdev bus, it register the mp action at the first bus scan happen. > > but in ethdev, we can't do that way, because, we don' t know when > > device will be attached or detached. > > so we need that function to help register a callback function which wil= l be > invoked during rte_eal_init. > > > > > > > > > > 02/07/2018 07:44, Qi Zhang: > > > > Introduce new API rte_eal_register_mp_init that help to register a > > > > callback function which will be invoked right after multi-process > > > > channel be established (rte_mp_channel_init). Typically the API > > > > will be used by other module that want it's mp channel action > > > > callbacks can be registered during rte_eal_init automatically. > > > [...] > > > > +/** > > > > + * @warning > > > > + * @b EXPERIMENTAL: this API may change without prior notice > > > > + * > > > > + * Register a callback function that will be invoked right after > > > > + * multi-process channel be established (rte_mp_channel_init). > > > > +Typically > > > > + * the function is used by other module that want it's mp channel > > > > + * action callbacks can be registered during rte_eal_init automati= cally. > > > > + * > > > > + * @note > > > > + * This function only take effect when be called before rte_eal_= init, > > > > + * and all registered callback will be clear during rte_eal_clea= nup. >=20 >=20