Re: [dpdk-dev] [PATCH v3 9/9] net/ionic: minor logging fixups

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 12/9/2020 7:26 PM, Andrew Boyer wrote:
> 
> 
>> On Dec 9, 2020, at 10:42 AM, Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>>
>> On 12/9/2020 2:45 PM, Andrew Boyer wrote:
>>>> On Dec 9, 2020, at 8:47 AM, Ferruh Yigit <ferruh.yigit@intel.com <mailto:ferruh.yigit@intel.com>> wrote:
>>>>
>>>> On 12/4/2020 8:16 PM, Andrew Boyer wrote:
>>>>> Expose ionic_opcode_to_str() so it can be used for dev cmds, too.
>>>>> Store the device name in struct adapter.
>>>>> Switch to memcpy() to work around gcc false positives.
>>>>> Signed-off-by: Andrew Boyer <aboyer@pensando.io <mailto:aboyer@pensando.io>>
>>>>> ---
>>>>>   drivers/net/ionic/ionic.h         |  1 +
>>>>>   drivers/net/ionic/ionic_dev.c     |  5 +++
>>>>>   drivers/net/ionic/ionic_dev.h     |  2 +
>>>>>   drivers/net/ionic/ionic_ethdev.c  |  4 +-
>>>>>   drivers/net/ionic/ionic_lif.c     | 68 ++++++++++++++++---------------
>>>>>   drivers/net/ionic/ionic_mac_api.c |  4 +-
>>>>>   drivers/net/ionic/ionic_main.c    | 32 ++++++++-------
>>>>>   drivers/net/ionic/ionic_rxtx.c    | 41 ++++++++-----------
>>>>>   8 files changed, 84 insertions(+), 73 deletions(-)
>>>>
>>>> <...>
>>>>
>>>>> @@ -1217,12 +1221,11 @@ ionic_lif_notifyq_init(struct ionic_lif *lif)
>>>>> }
>>>>> };
>>>>>   -IONIC_PRINT(DEBUG, "notifyq_init.index %d",
>>>>> -ctx.cmd.q_init.index);
>>>>> -IONIC_PRINT(DEBUG, "notifyq_init.ring_base 0x%" PRIx64 "",
>>>>> -ctx.cmd.q_init.ring_base);
>>>>> +IONIC_PRINT(DEBUG, "notifyq_init.index %d", q->index);
>>>>> +IONIC_PRINT(DEBUG, "notifyq_init.ring_base %#jx", q->base_pa);
>>>>
>>>> There are lots of similar PRIx64 -> %j change in this patch,
>>>> '%j' specifier is for 'intmax_t' and which seems 64bit storage, so this should work with 64 bit variable 'q->base_pa',
>>>> but the variable is explicitly uint64_t why replacing 'PRIx64' usage which is correct and more common usage in the DPDK? Why ionic is want to do this in its own way, I am not clear of the motivation of these changes really, can you please clarify?
>>> As best I know, I am following the (two different) contribute guidelines pages, both of which direct submitters to run checkpatch. One of things checkpatch flags is lines over 80 columns. Many of these lines were over 80 columns or oddly broken to meet the 80 column limit.
>>> %j is used in many other places in this PMD - as originally written by Alfredo, one of your core contributors. If we are allowed to use %j, I want to, since I much prefer it to the hideous PRIx64.
>>
>> %j is accepted, that is not an issue. But you are making an active effort to convert PRIx64 -> %j, which is very unnecessary in my opinion.
> 
> Ferruh, I made these changes months ago. Changing them back now is going to take at least a few hours - many other changes are layered on top.
> 
>> 80 column limit is not for log strings, but even if you are fixing them that is different thing from the PRIx64 -> %j conversion, you can keep PRIx64 and stay in 80 columns, and indeed lots of the cases the column limit seems not an issue at all.
>>
>> Andrew, this is a driver currently marked as 'UNMAINTAINED', I kindly suggest focusing your 70+ functional changes instead of this PRIx64 -> %j syntax changes, but it is all up to you of course.
> 
> Apparently it is not up to me, though, is it? I would very much appreciate if you would respond to my request for a meeting, at any time you find convenient.
> 
> When I add new log messages in the future (including adding to these lists of FW values and response codes), should I use PRIx64 or %jx?

for the fixed size variables, like uint64_t or uint32_t, better to use PRInNN

> Should I expect your objection to a mix of PRIx64 and %jx in the same paragraph?
> Am I allowed to change from PRIx64 to %jx if I am also modifying the text or the value logged?
> 

If there is no real reason to change, like unless it is wrong/broken, please 
don't change them. So I think all PRIx64 -> %j changes in this patch can be dropped.

> This is going to involve respinning all of those functional patches, and since I am not a mind-reader it seems likely that this is going to take years.
> 

Discussing may take time, don't get down by it, it will be OK, it won't take 
years ;)
And I am aware rebasing can be hassle, but it can't be justification of a 
change, this is side affect of accumulating too many patches in the backlog 
unfortunately.

>>>> <...>
>>>>
>>>>> @@ -1448,8 +1450,9 @@ ionic_lif_set_name(struct ionic_lif *lif)
>>>>> },
>>>>> };
>>>>>   -snprintf(ctx.cmd.lif_setattr.name, sizeof(ctx.cmd.lif_setattr.name),
>>>>> -"%d", lif->port_id);
>>>>> +/* FW is responsible for NULL terminating this field */
>>>>> +memcpy(ctx.cmd.lif_setattr.name, lif->name,
>>>>> +sizeof(ctx.cmd.lif_setattr.name));
>>>>
>>>> Even though FW may be guaranting the string will be null terminated, won't it be nice to provide input as null terminated if this is the expectation?
>>> No, that is not the expectation. We prefer it to be this way.
>>
>> It is know that FW will add NULL terminate the string but you "prefer" to provide 'name' without NULL termination. Why?
>> "we prefer it to be this way" is not a good justification, please either change or explain in a logical way.
> 
> I will set the last character to NULL if that is what you want. I do not see how it serves any purpose.
> 
> -Andrew
>