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

From: Jamal Hadi Salim <jhs@mojatatu.com>
To: Oz Shlomo <ozsh@nvidia.com>,
	Simon Horman <simon.horman@corigine.com>,
	netdev@vger.kernel.org
Cc: Vlad Buslov <vladbu@nvidia.com>, Roi Dayan <roid@nvidia.com>,
	Ido Schimmel <idosch@nvidia.com>,
	Cong Wang <xiyou.wangcong@gmail.com>,
	Jiri Pirko <jiri@resnulli.us>,
	Baowen Zheng <notifications@github.com>,
	Louis Peens <louis.peens@corigine.com>,
	oss-drivers@corigine.com
Subject: Re: [RFC/PATCH net-next v3 0/8] allow user to offload tc action to net device
Date: Sun, 31 Oct 2021 09:40:15 -0400	[thread overview]
Message-ID: <cf86b2ab-ec3a-b249-b380-968c0a3ef67d@mojatatu.com> (raw)
In-Reply-To: <b409b190-8427-2b6b-ff17-508d81175e4d@nvidia.com>

On 2021-10-31 05:50, Oz Shlomo wrote:
> 
> 
> On 10/28/2021 2:06 PM, Simon Horman wrote:
>> Baowen Zheng says:
>>
>> Allow use of flow_indr_dev_register/flow_indr_dev_setup_offload to 
>> offload
>> tc actions independent of flows.
>>
>> The motivation for this work is to prepare for using TC police action
>> instances to provide hardware offload of OVS metering feature - which 
>> calls
>> for policers that may be used by multiple flows and whose lifecycle is
>> independent of any flows that use them.
>>
>> This patch includes basic changes to offload drivers to return EOPNOTSUPP
>> if this feature is used - it is not yet supported by any driver.
>>
>> Tc cli command to offload and quote an action:
>>
>> tc qdisc del dev $DEV ingress && sleep 1 || true
>> tc actions delete action police index 99 || true
>>
>> tc qdisc add dev $DEV ingress
>> tc qdisc show dev $DEV ingress
>>
>> tc actions add action police index 99 rate 1mbit burst 100k skip_sw
>> tc actions list action police
>>
>> tc filter add dev $DEV protocol ip parent ffff:
>> flower ip_proto tcp action police index 99
>> tc -s -d filter show dev $DEV protocol ip parent ffff:
>> tc filter add dev $DEV protocol ipv6 parent ffff:
>> flower skip_sw ip_proto tcp action police index 99
>> tc -s -d filter show dev $DEV protocol ipv6 parent ffff:
>> tc actions list action police
>>
>> tc qdisc del dev $DEV ingress && sleep 1
>> tc actions delete action police index 99
>> tc actions list action police
>>
> 
> 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.

cheers,
jamal