Thread (41 messages) flat view 41 messages, 6 authors, 2021-11-04

Re: [RFC/PATCH net-next v3 0/8] allow user to offload tc action to net device

From: Simon Horman <hidden>
Date: 2021-11-02 12:51:29

On Mon, Nov 01, 2021 at 10:01:28AM +0200, Vlad Buslov wrote:
On Sun 31 Oct 2021 at 15:40, Jamal Hadi Salim [off-list ref] wrote:
quoted
On 2021-10-31 05:50, Oz Shlomo wrote:
quoted
On 10/28/2021 2:06 PM, Simon Horman wrote:
...
quoted
quoted
Actions are also (implicitly) instantiated when filters are created.
In the following example the mirred action instance (created by the first
filter) is shared by the second filter:
tc filter add dev $DEV1 proto ip parent ffff: flower \
     ip_proto tcp action mirred egress redirect dev $DEV3
tc filter add dev $DEV2 proto ip parent ffff: flower \
     ip_proto tcp action mirred index 1
I sure hope this is supported. At least the discussions so far
are a nod in that direction...
I know there is hardware that is not capable of achieving this
(little CPE type devices) but lets not make that the common case.
Looks like it isn't supported in this change since
tcf_action_offload_add() is only called by tcf_action_init() when BIND
flag is not set (the flag is always set when called from cls code).
Moreover, I don't think it is good idea to support such use-case because
that would require to increase number of calls to driver offload
infrastructure from 1 per filter to 1+number_of_actions, which would
significantly impact insertion rate.
Hi,

I feel that I am missing some very obvious point here.

But from my perspective the use case described by Oz is supported
by existing offload of the flower classifier (since ~4.13 IIRC).
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help