[dpdk-dev] [PATCH v3 2/3] eal: add synchronous multi-process communication

[Ananyev, Konstantin]

> -----Original Message-----
> From: Burakov, Anatoly
> Sent: Thursday, January 25, 2018 12:26 PM
> To: Ananyev, Konstantin <konstantin.ananyev at intel.com>; Tan, Jianfeng <jianfeng.tan at intel.com>; dev at dpdk.org
> Cc: Richardson, Bruce <bruce.richardson at intel.com>; thomas at monjalon.net
> Subject: Re: [PATCH v3 2/3] eal: add synchronous multi-process communication
> 
> On 25-Jan-18 12:19 PM, Ananyev, Konstantin wrote:
> >
> >
> >> -----Original Message-----
> >> From: Burakov, Anatoly
> >> Sent: Thursday, January 25, 2018 12:00 PM
> >> To: Tan, Jianfeng <jianfeng.tan at intel.com>; dev at dpdk.org
> >> Cc: Richardson, Bruce <bruce.richardson at intel.com>; Ananyev, Konstantin <konstantin.ananyev at intel.com>; thomas at monjalon.net
> >> Subject: Re: [PATCH v3 2/3] eal: add synchronous multi-process communication
> >>
> >> On the overall patch,
> >>
> >> Reviewed-by: Anatoly Burakov <anatoly.burakov at intel.com>
> >>
> >> For request(), returning number of replies received actually makes
> >> sense, because now we get use the value to read our replies, if we were
> >> a primary process sending messages to secondary processes.
> >
> > Yes, I also think it is good to return number of sends.
> > Then caller can compare number of sended requests with number of
> > received replies and decide should it be considered a failure or no.
> >
> 
> Well, OK, that might make sense. However, i think it would've be of more
> value to make the API consistent (0/-1 on success/failure) and put
> number of sent messages into the reply, like number of received. I.e.
> something like
> 
> struct reply {
>     int nb_sent;
>     int nb_received;
> };
> 
> We do it for the latter already, so why not the former?

The question is what treat as success/failure?
Let say we sent 2 requests (of 3 possible), got back 1 response...
Should we consider it as success or failure?