On 27-Feb-19 11:10, Leon Romanovsky wrote:
> On Wed, Feb 27, 2019 at 10:57:16AM +0200, Gal Pressman wrote:
>> On 27-Feb-19 10:36, Leon Romanovsky wrote:
>>> On Wed, Feb 27, 2019 at 10:31:29AM +0200, Gal Pressman wrote:
>>>> On 26-Feb-19 21:32, Leon Romanovsky wrote:
>>>>> On Thu, Feb 21, 2019 at 05:33:10PM +0200, Gal Pressman wrote:
>>>>>> Add the EFA common commands implementation.
>>>>>>
>>>>>> Signed-off-by: Gal Pressman <galpress@xxxxxxxxxx>
>>>>>> ---
>>>
>>> <...>
>>>
>>>>>> + err = efa_com_cmd_exec(aq,
>>>>>> + (struct efa_admin_aq_entry *)&create_qp_cmd,
>>>>>> + sizeof(create_qp_cmd),
>>>>>> + (struct efa_admin_acq_entry *)&cmd_completion,
>>>>>> + sizeof(cmd_completion));
>>>>>> + if (unlikely(err)) {
>>>>>
>>>>> There is no need to add likely/unlikely not in data path.
>>>>
>>>> Doesn't hurt though, right?
>>>
>>> Right, if readability is not important, it won't hurt.
>>
>> Actually, I find likely/unlikely easier to read as it helps you identify the
>> main flows.
>> In this case the main flow is clear, but I wouldn't say that it hurts readability.
>
> Can you please point me the place in the code where "err" is expected
> behaviour and such place needs extra help to identify the main flow,
> instead of naming "err" to be something else, more descriptive?
My point was that these annotations are a hint to the reader as well, not just
the compiler.
In many places the hint is obvious, but that doesn't make the code less readable.
