From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 35D621BB47 for ; Thu, 21 Jun 2018 11:06:24 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2018 02:06:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,251,1526367600"; d="scan'208";a="66010140" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.252.4.182]) ([10.252.4.182]) by fmsmga001.fm.intel.com with ESMTP; 21 Jun 2018 02:06:21 -0700 To: Qi Zhang , thomas@monjalon.net Cc: konstantin.ananyev@intel.com, dev@dpdk.org, bruce.richardson@intel.com, ferruh.yigit@intel.com, benjamin.h.shelton@intel.com, narender.vangati@intel.com References: <20180607123849.14439-1-qi.z.zhang@intel.com> <20180621020059.1198-1-qi.z.zhang@intel.com> <20180621020059.1198-7-qi.z.zhang@intel.com> From: "Burakov, Anatoly" Message-ID: <24f21c6f-e04c-0aa6-61fe-00893aa07a49@intel.com> Date: Thu, 21 Jun 2018 10:06:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180621020059.1198-7-qi.z.zhang@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2 06/22] ethdev: support attach or detach share device from secondary 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: Thu, 21 Jun 2018 09:06:25 -0000 On 21-Jun-18 3:00 AM, Qi Zhang wrote: > This patch cover the multi-process hotplug case when a share device > attach/detach request be issued from secondary process, the implementation > references malloc_mp.c. > > device attach on secondary: > a) secondary send async request to primary and wait on a condition > which will be released by matched response from primary. > b) primary receive the request and attach the new device if failed > goto i). > c) primary forward attach request to all secondary as async request > (because this in mp thread context, use sync request will deadlock) > d) secondary receive request and attach device and send reply. > e) primary check the reply if all success go to j). > f) primary send attach rollback async request to all secondary. > g) secondary receive the request and detach device and send reply. > h) primary receive the reply and detach device as rollback action. > i) send fail response to secondary, goto k). > j) send success response to secondary. > k) secondary process receive response and return. > > device detach on secondary: > a) secondary send async request to primary and wait on a condition > which will be released by matched response from primary. > b) primary receive the request and perform pre-detach check, if device > is locked, goto j). > c) primary send pre-detach async request to all secondary. > d) secondary perform pre-detach check and send reply. > e) primary check the reply if any fail goto j). > f) primary send detach async request to all secondary > g) secondary detach the device and send reply > h) primary detach the device. > i) send success response to secondary, goto k). > j) send fail response to secondary. > k) secondary process receive response and return. > > Signed-off-by: Qi Zhang > --- > > -static int handle_secondary_request(const struct rte_mp_msg *msg, const void *peer) > +static int > +check_reply(const struct eth_dev_mp_req *req, const struct rte_mp_reply *reply) > +{ > + struct eth_dev_mp_req *resp; > + int i; > + > + if (reply->nb_received != reply->nb_sent) > + return -EINVAL; > + > + for (i = 0; i < reply->nb_received; i++) { > + resp = (struct eth_dev_mp_req *)reply->msgs[i].param; > + > + if (resp->t != req->t) { > + ethdev_log(ERR, "Unexpected response to async request\n"); > + return -EINVAL; > + } > + > + if (resp->id != req->id) { > + ethdev_log(ERR, "response to wrong async request\n"); > + return -EINVAL; > + } > + > + if (resp->result) > + return resp->result; > + } > + > + return 0; > +} As far as i understand, return values from this will propagate all the way up to user return value. How would a user differentiate between -EINVAL returned from invalid parameters, and -EINVAL from failed reply? I think this error code should be different (don't know which one though :) ). (as a side note, you keep returning -EINVAL all over the place, even when problem is not in user's arguments - you should probably fix those too. for example, if request ID not found, return code should probably be something like -ENOENT) -- Thanks, Anatoly