netdev - Re: [PATCH net-next RFC v5 4/4] net/sched: act_blockcast: Introduce blockcast tc action

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]

Date: Tue, 5 Dec 2023 10:27:31 -0500
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Marcelo Ricardo Leitner <mleitner@...hat.com>
Cc: Jiri Pirko <jiri@...nulli.us>, Jamal Hadi Salim <hadi@...atatu.com>, 
	Victor Nogueira <victor@...atatu.com>, davem@...emloft.net, edumazet@...gle.com, 
	kuba@...nel.org, pabeni@...hat.com, xiyou.wangcong@...il.com, 
	vladbu@...dia.com, paulb@...dia.com, pctammela@...atatu.com, 
	netdev@...r.kernel.org, kernel@...atatu.com
Subject: Re: [PATCH net-next RFC v5 4/4] net/sched: act_blockcast: Introduce
 blockcast tc action

On Tue, Dec 5, 2023 at 9:52 AM Marcelo Ricardo Leitner
<mleitner@...hat.com> wrote:
>
> On Tue, Dec 05, 2023 at 09:41:02AM +0100, Jiri Pirko wrote:
> > Mon, Dec 04, 2023 at 09:10:18PM CET, jhs@...atatu.com wrote:
> > >On Mon, Dec 4, 2023 at 4:49 AM Jiri Pirko <jiri@...nulli.us> wrote:
> > >>
> > >> Fri, Dec 01, 2023 at 07:45:47PM CET, jhs@...atatu.com wrote:
> ...
> > >> >Ok, so we are moving forward with mirred "mirror" option only for this then...
> > >>
> > >> Could you remind me why mirror and not redirect? Does the packet
> > >> continue through the stack?
> > >
> > >For mirror it is _a copy_ of the packet so it continues up the stack
> > >and you can have other actions follow it (including multiple mirrors
> > >after the first mirror). For redirect the packet is TC_ACT_CONSUMED -
> > >so removed from the stack processing (and cant be sent to more ports).
> > >That is how mirred has always worked and i believe thats how most
> > >hardware works as well.
> > >So sending to multiple ports has to be mirroring semantics (most
> > >hardware assumes the same semantics).
> >
> > You assume cloning (sending to multiple ports) means mirror,
> > that is I believe a mistake. Look at it from the perspective of
> > replacing device by target for each action. Currently we have:
> >
> > 1) mirred mirror TARGET_DEVICE
> >    Clones, sends to TARGET_DEVICE and continues up the stack
> > 2) mirred redirect TARGET_DEVICE
> >    Sends to TARGET_DEVICE, nothing is sent up the stack
> >
> > For block target, there should be exacly the same semantics:
> >
> > 1) mirred mirror TARGET_BLOCK
> >    Clones (multiple times, for each block member), sends to TARGET_BLOCK
> >    and continues up the stack
> > 2) mirred redirect TARGET_BLOCK
> >    Clones (multiple times, for each block member - 1), sends to
> >    TARGET_BLOCK, nothing is sent up the stack
>
> This makes sense to me as well. When I first read Jamal's email I
> didn't spot any confusion, but now I see there can be some. I think he
> meant pretty much the same thing, referencing cascading other outputs
> after blockcast (and not the inner outputs, lets say), but that's just
> my interpretation. :)

In my (shall i say long experience) I have never seen the prescribed
behavior of redirect meaning mirror to (all - last one) then redirect
on last one.. Jiri, does spectrum work like this?
Neither in s/w nor in h/w. From h/w - example, the nvidia CX6 you have
to give explicit mirror, mirror, mirror, redirect. IOW, i dont think
the hardware can be told "here's a list of ports, please mirror to all
of them and for the last one steal the packet and redirect".
Having said that i am not opposed to it - it will just make the code
slightly more complex and i am sure slightly slower in the datapath.

cheers,
jamal