Re: [RFC]: raw packet filtering via tc-flower

[Jiri Pirko <jiri@resnulli.us>]

Fri, Feb 23, 2024 at 01:07:06PM CET, ecree.xilinx@gmail.com wrote:
>On 23/02/2024 09:51, Jiri Pirko wrote:
>> Hmm, but why flower can't be extended this direction. I mean, it is very
>> convenient to match on well-defined fields.
>
>Flower is intrinsically tied to the flow dissector, both conceptually
> and in implementation.  I'm not sure it's appropriate for it to become
> a dumping ground for random vendor filtering extensions/capabilities.

Nope, the extension of dissector would be clean, one timer. Just add
support for offset+len based dissection. Also, the fact that flower uses
flow_dissector is only because DaveM requested that back in the days I
pushed flower. The original implementation was not using flow_dissector.
The dissection backing should not block flower extension. We can always
replace it if needed and convenient (maybe the criteria is met already).


>
>> U32 is, well, not that convenient.
>
>How about a new classifier that just does this raw matching?

That's u32 basically, isn't it?


>
>> I can imagine that the
>> combination of match on well-defined fields and random chunks together
>> is completely valid use-case.
>
>But is it likely to be something that hardware supports?  (Since the

Yeah, I know couple of ASICs that support this, driver names are mlx5
and mlxsw :)


> motivation for this feature is clearly the hardware offload — otherwise
> there are other mechanisms like BPF for arbitrary packet filtering.)
>
>As the vendor behind this, one hopes Intel can comment on both the
> hardware and the use-case side of this question.