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: Baowen Zheng <hidden>
Date: 2022-02-17 01:52:05

On February 16, 2022 10:18 PM, Roi wrote:
On 2022-02-16 2:51 PM, Jamal Hadi Salim wrote:
quoted
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 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

quoted
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