On 26-Jun-18 2:25 PM, Zhang, Qi Z wrote:
-----Original Message-----
From: Burakov, Anatoly
Sent: Tuesday, June 26, 2018 9:21 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 v4 06/24] ethdev: enable hotplug on multi-process
On 26-Jun-18 1:58 PM, Zhang, Qi Z wrote:
my understand is peer is identified by a string (or filename) what I
mean is clone the content of the buffer that peer point to , So I
don't need to worry if the original peer be used to point to some
other data
As far as the application is concerned, peer is an opaque pointer, and should
be treated as such. Peeking behind a void pointer that is not designed for this
purpose is not a good idea, even if technically you know what's in there.
We can expose a clone interface, like MP_PEER_CLONE, so we don't need to know
what's inside, just need to know that it can be used on another thread?
Well, that can probably work. Feels like a hacky workaround though.
Another way to do the same thing would be to store peer information
right in the message, as opposed to providing it separately. Still a
hack though, and will require far more changes, but it could be a better
solution as (if done right) it would allow identifying which reply came
from which peer.
Of course, an even better approach would be to devise some kind of
addressing scheme (uuid?), so that peer addresses are no longer opaque
pointers but rather are valid data types.
Thoughts?
--
Thanks,
Anatoly
