netdev - Re: [PATCH net-next] net: airoha: Add matchall filter offload support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKa-r6tNa+Ltxb61g6E3h66pxW0XTDb76T6Wc2XMJCu8xuAvPg@mail.gmail.com>
Date: Tue, 8 Apr 2025 10:05:17 +0200
From: Davide Caratti <dcaratti@...hat.com>
To: Lorenzo Bianconi <lorenzo@...nel.org>
Cc: Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org, 
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next] net: airoha: Add matchall filter offload support

hello Lorenzo, thanks for this patch!

On Mon, Apr 7, 2025 at 10:04 PM Lorenzo Bianconi <lorenzo@...nel.org> wrote:
>
> Introduce tc matchall filter offload support in airoha_eth driver.
> Matchall hw filter is used to implement hw rate policing via tc action
> police:
>
> $tc qdisc add dev eth0 handle ffff: ingress
> $tc filter add dev eth0 parent ffff: matchall action police \
>  rate 100mbit burst 1000k drop
>
> Curennet implementation supports just drop/accept as exceed/notexceed
> actions. Moreover, rate and burst are the only supported configuration
> parameters.
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@...nel.org>

[...]

> +
> +       if (act->police.peakrate_bytes_ps || act->police.avrate ||
> +           act->police.overhead) {
> +               NL_SET_ERR_MSG_MOD(f->common.extack,
> +                                  "peakrate/avrate/overhead not supported");
> +               return -EOPNOTSUPP;
> +       }

I think the driver should also validate the so-called "mtu policing"
parameter. E.g, configuring it in the hardware if it has non-zero
value in act->police, or alternatively reject offloading of police
rules where act->police.mtu is non-zero (like done in the hunk above).
WDYT?
-- 
davide