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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 22 Dec 2022 15:22:10 +0100 From: Paolo Abeni <pabeni@...hat.com> To: Steen Hegelund <steen.hegelund@...rochip.com>, "David S . Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org> Cc: UNGLinuxDriver@...rochip.com, Randy Dunlap <rdunlap@...radead.org>, Casper Andersson <casper.casan@...il.com>, Russell King <rmk+kernel@...linux.org.uk>, Wan Jiabing <wanjiabing@...o.com>, Nathan Huckleberry <nhuck@...gle.com>, linux-kernel@...r.kernel.org, netdev@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, Daniel Machon <daniel.machon@...rochip.com>, Horatiu Vultur <horatiu.vultur@...rochip.com>, Lars Povlsen <lars.povlsen@...rochip.com>, Dan Carpenter <error27@...il.com> Subject: Re: [PATCH net 0/8] Add support for two classes of VCAP rules Hello, On Wed, 2022-12-21 at 14:25 +0100, Steen Hegelund wrote: > This adds support for two classes of VCAP rules: > > - Permanent rules (added e.g. for PTP support) > - TC user rules (added by the TC userspace tool) > > For this to work the VCAP Loopups must be enabled from boot, so that the > "internal" clients like PTP can add rules that are always active. > > When the TC tool add a flower filter the VCAP rule corresponding to this > filter will be disabled (kept in memory) until a TC matchall filter creates > a link from chain 0 to the chain (lookup) where the flower filter was > added. > > When the flower filter is enabled it will be written to the appropriate > VCAP lookup and become active in HW. > > Likewise the flower filter will be disabled if there is no link from chain > 0 to the chain of the filter (lookup), and when that happens the > corresponding VCAP rule will be read from the VCAP instance and stored in > memory until it is deleted or enabled again. Despite the 'net' target, this looks really like net-next material as most patches look like large refactor. I see there are a bunch of fixes in patches 3-8, but quite frankly it's not obvious at all what the refactors/new features described into the commit messages themself really fix. I suggest to move this series to net-next (and thus repost after Jan 2), unless you come-up with some good reasons to keep it in net. Thanks, Paolo
Powered by blists - more mailing lists