RE: [PATCH iproute2-next v2] tc: add skip_hw and skip_sw to control action offload

[Baowen Zheng <baowen.zheng@corigine.com>]

On February 16, 2022 10:18 PM, Roi wrote:
>On 2022-02-16 2:51 PM, Jamal Hadi Salim wrote:
>> On 2022-02-11 05:01, Baowen Zheng wrote:
>>> Hi Jamal:
>>> Sorry for the delay of the reply.
>>>
>>
>> I guess it is my turn to say sorry for the latency ;->
>>
>>> On February 2, 2022 7:47 PM, Jamal wrote:
>>>> On 2022-02-02 04:37, Baowen Zheng wrote:
>>>>> Hi Roi:
>>>>> Thanks for bring this to us, please see the inline comments.
>>>>>
>>
>> [..]
>>>>
>>>> Probably the language usage is causing the confusion and I missed
>>>> this detail in the output as well. Let me see if i can break this
>>>> down.
>>>>
>>>> Either both action and  filter are in h/w or they are not. i.e
>>>>
>>>> action in h/w  + filter in h/w == GOOD action in h/w  + filter in
>>>> s/w == BAD action in s/w  + filter in h/w == BAD action in s/w  +
>>>> filter in s/w == GOOD
>>>>
>>>> The kernel patches did have those rules in place - and Baowen added
>>>> tdc tests to check for this.
>>>>
>>>> Now on the workflow:
>>>> 1) If you add an action independently to offload before you add a
>>>> filter when you dump actions it should say "skip_sw, ref 1 bind 0"
>>>> i.e information is sufficient here to know that the action is
>>>> offloaded but there is no filter attached.
>>>>
>>>> 2) If you bind this action after to a filter which _has to be
>>>> offloaded_ (otherwise the filter will be rejected) then when you
>>>> dump the actions you should see "skip_sw ref 2 bind 1"; when you
>>>> dump the filter you should see the same on the filter.
>>>>
>>>> 3) If you create a skip_sw filter without step #1 then when you dump
>>>> you should see "skip_sw ref 1 bind 1" both when dumping in IOW, the
>>>> not_in_hw is really unnecessary.
>>>>
>>>> So why not just stick with skip_sw and not add some new language?
>>>>
>>> If I do not misunderstand, you mean we just show the skip_sw flag and
>>> do not show other information(in_hw, not_in_hw and in_hw_count), I
>>> think it is reasonable to show the action information as your
>>> suggestion if the action is dumped along with the filters.
>>>
>>
>> Yes, thats what i am saying - it maintains the existing semantics
>> people are aware of for usability.
>>
>>> But as we discussed previously, we added the flags of skip_hw,
>>> skip_sw, in_hw_count mainly for the action dump command(tc -s -d
>>> actions list action xxx).
>>> We know that the action can be created with three flags case:
>>> skip_sw, skip_hw and no flag.
>>> Then when the actions are dumped independently, the information of
>>> skip_hw, skip_sw, in_hw_count will become important for the user to
>>> distinguish if the action is offloaded or not.
>>>
>>> So does that mean we need to show different item when the action is
>>> dumped independent or along with the filter?
>>>
>>
>> I see your point. I am trying to visualize how we deal with the
>> tri-state  in filters and we never considered what you are suggesting.
>> Most people either skip_sw or skip_hw in presence of offloadable hw.
>> In absence of hardware nobody specifies a flag, so nothing is displayed.
>> My eyes are used to how filters look like. Not sure anymore tbh. Roi?
>>
>
>Hi,
>
>Is the question here if to show different information when actions are
>dumped independently or with a filter?
>
>then I think yes. when actions are dumped as part of the filter skip showing
>skip_sw/skip_hw/in_hw/not_in_hw flags as it's redundant and it's always
>whatever the filter state is.
>
>I also noticed we can improve extack msgs when a user will try to mix the state
>like adding a filter without skip_hw flag but use action index that is created
>with skip_hw.
>I noticed currently there is no informative extack msg back to the user.
Thanks Roi and Jamal, we will think about how to display different information in action dump independently or along with the filter. 
Also for the extack msg enhancement for the user.

>
>Thanks,
>Roi
>
>
>> cheers,
>> jamal
>>
>>