Thread (13 messages) 13 messages, 5 authors, 2022-02-17

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

From: Roi Dayan <hidden>
Date: 2022-02-16 14:18:14


On 2022-02-16 2:51 PM, Jamal Hadi Salim wrote:
On 2022-02-11 05:01, Baowen Zheng wrote:
quoted
Hi Jamal:
Sorry for the delay of the reply.
I guess it is my turn to say sorry for the latency ;->
quoted
On February 2, 2022 7:47 PM, Jamal wrote:
quoted
On 2022-02-02 04:37, Baowen Zheng wrote:
quoted
Hi Roi:
Thanks for bring this to us, please see the inline comments.
[..]
quoted
quoted
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.
quoted
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

cheers,
jamal
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help