netdev - Re: [PATCH net-next v4 0/3] net/sched: Introduce tc block ports tracking and use

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: <CALnP8ZbD_09u+Qqd2N4VcrstuGexh7TiNAtL7n4pyUvLAQ8EOw@mail.gmail.com>
Date: Mon, 9 Oct 2023 13:54:07 -0700
From: Marcelo Ricardo Leitner <mleitner@...hat.com>
To: Jiri Pirko <jiri@...nulli.us>
Cc: Jamal Hadi Salim <jhs@...atatu.com>, Jakub Kicinski <kuba@...nel.org>, 
	Victor Nogueira <victor@...atatu.com>, xiyou.wangcong@...il.com, davem@...emloft.net, 
	pabeni@...hat.com, edumazet@...gle.com, vladbu@...dia.com, 
	simon.horman@...igine.com, pctammela@...atatu.com, netdev@...r.kernel.org, 
	kernel@...atatu.com
Subject: Re: [PATCH net-next v4 0/3] net/sched: Introduce tc block ports
 tracking and use

On Sat, Oct 07, 2023 at 07:20:52PM +0200, Jiri Pirko wrote:
> Sat, Oct 07, 2023 at 04:09:15PM CEST, jhs@...atatu.com wrote:
> >On Sat, Oct 7, 2023 at 8:43 AM Jiri Pirko <jiri@...nulli.us> wrote:
...
> >> My primary point is, this should be mirred redirect to block instead of
> >> what we currently have only for dev. That's it.
> >
> >Agreed (and such a feature should be added regardless of this action).
> >The tc block provides a simple abstraction, but do you think it is
> >enough? Alternative is to use a list of ports given to mirred: it
> >allows us to group ports from different tc blocks or even just a
> >subset of what is in a tc block - but it will require a lot more code
> >to express such functionality.
>
> Again, you attach filter to either dev or block. If you extend mirred
> redirect to accept the same 2 types of target, I think it would be best.

The difference here between filter and action here is that you don't
really have an option for filters: you either attach it to either dev
or block, or you create an entire new class of objects, say,
"blockfilter", all while retaining the same filters, parameters, etc.
I'm not aware of a single filter that behaves differently over a block
than a netdev.

But for actions, there is the option, and despite the fact that both
"output packets", the semantics are not that close. It actually
helps with parameter parsing, documentation (man pages), testing (as
use and test cases can be more easily tracked) and perhaps more
importantly: if I don't want this feature, I can disable the new
module.

Later someone will say "hey why not have a hash_dst_selector", so it
can implement a load balancer through the block output? And mirred,
once a simple use case (with an already complex implementation),
becomes a partial implementation of bonding then. :)

In short, I'm not sure if having the user to fiddle through a maze of
options that only work in mode A or B or work differently is better
than having more specialized actions (which can and should reuse code).

  Marcelo