Re: [dpdk-dev] [PATCH] app/testpmd: support QinQ strip offload

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

On 7/22/2019 6:03 PM, Iremonger, Bernard wrote:
> Hi Ferruh,
> 
> <snip>
> 
>>>>>> Subject: Re: [dpdk-dev] [PATCH] app/testpmd: support QinQ strip
>>>>>> offload
>>>>>>
>>>>>> On 7/17/2019 8:45 AM, viveksharma@marvell.com wrote:
>>>>>>> From: Vivek Sharma <viveksharma@marvell.com>
>>>>>>>
>>>>>>> Support QinQ strip RX offload configuration through testpmd
>>>>>>> command line and boot time arguments.
>>>>>>
>>>>>> For the testpmd command part, unfortunately there are two set of
>>>>>> commands for same purpose, the new ones are (lets both port and
>>>> queue
>>>>>> level):
>>>>>> "port config <port_id> rx_offload ..."
>>>>>> "port (port_id) rxq (queue_id) rx_offload ..."
>>>>>> "port config (port_id) tx_offload ..."
>>>>>> "port (port_id) txq (queue_id) tx_offload ..."
>>>>>>
>>>>>> These are better implementation comparing the old one:
>>>>>> "port config all ..."
>>>>>>
>>>>>> Would you mind sending a patch to remove "port config all ..."
>>>>>> variant of setting offloads?
>>>>>> And you can make your changes to the new commands above.
>>>>>
>>>>> Is it ok to remove "port config all ..." commands as they may be in
>>>>> use by
>>>> the community?
>>>>
>>>> Since there is a command that replaces the removed functionality I
>>>> think it is OK.
>>>>
>>>> Also I am not sure what level of backward compatibility we should
>>>> provide for testpmd commands.
>>>
>>> It might be better to leave "port config all ..." commands  as they are for
>> now and provide a separate patchset for the new style port setting offloads
>> commands.
>>>
>>> If they are to be removed there should at least  be something to announce
>> this in the release notes.  There is a deprecation process which is used for the
>> rest of the code, why not follow that process.
>>
>> Deprecation process is for ABI/API changes.
>>
>> I can see testpmd commands also a kind of user interface, but this is a test
>> application at the end, deprecation process can be overkill here.
>> Although +1 to be cautious on command consistency and keep some level of
>> stability on them.
> 
>>>>>> For the application argument, ``--enable-hw-vlan-extend``, instead
>>>>>> of adding a parameter of each offload argument, (and event it is
>>>>>> not clear if it is only for Rx or Tx), have a "--rx-offloads"
>>>>>> argument and feed
>>>> the list via this, like:
>>>>>> "--rx-ofloads=disable-crc-strip,enable-rx-timestamp"
>>>>>>
>>>>>>
>>>>>>
>>>>>> And lastly for the  "vlan set ..." update, I think "qinq" was
>>>>>> already defined but it was calling 'vlan_extend_set()', now you are
>>>>>> changing it and making it call 'rx_vlan_qinq_strip_set()', I think
>>>>>> this is OK, but can you please update the 'cmd_help_long_parsed()'
>> accordingly?
>>>>>
>>>>> 'vlan_extend_set()'  and 'rx_vlan_qinq_strip_set()'  are different
>>>> commands.
>>>>> vlan_extend_set()  is for adding the second vlan  and
>>>> rx_vlan_qinq_strip_set() is for removing the second vlan.
>>>>
>>>> yes they are different, I think nobody said they are same.
>>>> What is the concern here, can you please detail more?
>>>
>>> In the previous paragraph, you mentioned that "I think "qinq" was
>>> already defined but it was calling 'vlan_extend_set()', now you are
>>> changing  it and making it call 'rx_vlan_qinq_strip_set()' "
>>>
>>> vlan_extend_set() is not being changed, rx_vlan_qinq_strip_set() is being
>> added.
>>
>> Before this patch,
>> "vlan set qinq" calls 'vlan_extend_set()'
>>
>> After patch,
>> "vlan set qinq" calls 'rx_vlan_qinq_strip_set()'
> 
>> And again after this patch,
>> "vlan set extend" added and which calls 'vlan_extend_set()'
>>
>> so the patch looks like adding "vlan set extend" command, but practically it
>> does fix "vlan set qinq", I said "I think this is OK" and asked for help string &
>> documentation update accordingly.
>>
>> I hope it is clear now.
> 
> Yes, I see what you mean now (well spotted). 
> Previously the "qinq" keyword mapped to extend now it maps to qinq_strip. It would be better to leave the function of the "qinq" keyword as it was add a "qinqstrip" keyword instead of adding the "extend" keyword.
> 
>>>>>> And in original 'cmd_help_long_parsed()' for 'vlan set ...", it
>>>>>> doesn't need to have separate lines for "strip, filter & qinq", can
>>>>>> you please merge them, and later the 'extend' one?
>>>>>> Than change needs to be documented on "testpmd_funcs.rst"
>>>>>>
>>>>>>
>>>>>> And as a last thing, can you please send this as multiple patches:
>>>>>> 1) Command line change for setting qinq offload
>>>>>> 2) Application argument change
>>>>>> 3) "vlan set " related changes
>>>>>>
>>>>>>>
>>>>>>> Signed-off-by: Vivek Sharma <viveksharma@marvell.com>
>>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Bernard
>>>>>
>>> In my opinion this patch was fine for the "port config all ..." style
>> commands.
>>
>> Duplication is bad, it is bad to have two different ways to do same thing.
>> I am not sure if Vivek is aware of duplicated functions but explicitly prefers to
>> update old versions.
>> I suggest lets stop improving these ones and get rid of them asap.
> 
> Testpmd is widely used so removing commands without notice will  probably not go down too well with the community.

We can make sure release notes is updated for removed commands and what is
replacing them, also can have same thing in the commit log, these can help user.

But I am dubious to follow deprecation process for testpmd commands.

>  
>> Also as you can see commit log doesn't mention from "vlan set ..." changes at
>> all, that is why I asked for splitting this into 3 patches for 3 separate thing it
>> does.
> 
> Ok,  it should describe the "vlan set ...." changes.
> 
>>> A separate patch set should be submitted for the new style setting offloads
>> commands.
>>>
>>> Regards,
>>>
>>> Bernard
>>>
> 
> Regards,
> 
> Bernard
>