On 21-Jun-18 1:50 PM, Zhang, Qi Z wrote:
-----Original Message-----
From: Burakov, Anatoly
Sent: Thursday, June 21, 2018 5:06 PM
To: Zhang, Qi Z <qi.z.zh...@intel.com>; tho...@monjalon.net
Cc: Ananyev, Konstantin <konstantin.anan...@intel.com>; dev@dpdk.org;
Richardson, Bruce <bruce.richard...@intel.com>; Yigit, Ferruh
<ferruh.yi...@intel.com>; Shelton, Benjamin H
<benjamin.h.shel...@intel.com>; Vangati, Narender
<narender.vang...@intel.com>
Subject: Re: [PATCH v2 06/22] ethdev: support attach or detach share device
from secondary
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 <qi.z.zh...@intel.com>
---
<snip>
-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.
Yes
How would a user differentiate between -EINVAL returned
from invalid parameters, and -EINVAL from failed reply?
My understanding is if
(resp->t != req->t) or (resp->id != req->id) is not expected to happen at any
condition.
there should be a bug if it does happen.
So the return value is not necessary to be sensitive.
Am I right?
You're right, it won't happen under normal conditions. However, on the
off-chance that it does, the error return should still be meaningful.
Under normal conditions, malloc() doesn't fail either :)
--
Thanks,
Anatoly
