From: Jiri Pirko <jiri@resnulli.us>
To: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Victor Nogueira <victor@mojatatu.com>,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, xiyou.wangcong@gmail.com, mleitner@redhat.com,
vladbu@nvidia.com, paulb@nvidia.com, pctammela@mojatatu.com,
netdev@vger.kernel.org, kernel@mojatatu.com
Subject: Re: [PATCH net-next RFC v5 4/4] net/sched: act_blockcast: Introduce blockcast tc action
Date: Thu, 23 Nov 2023 15:04:00 +0100 [thread overview]
Message-ID: <ZV9b0HrM5WespGMW@nanopsycho> (raw)
In-Reply-To: <CAM0EoMnwM836zTWJJsLa0QcqByGkcw0dMs8ScW7Cct3aBAQOMw@mail.gmail.com>
Thu, Nov 23, 2023 at 02:37:13PM CET, jhs@mojatatu.com wrote:
>On Thu, Nov 23, 2023 at 3:51 AM Jiri Pirko <jiri@resnulli.us> wrote:
>>
>> Fri, Nov 10, 2023 at 10:46:18PM CET, victor@mojatatu.com wrote:
>> >This action takes advantage of the presence of tc block ports set in the
>> >datapath and multicasts a packet to ports on a block. By default, it will
>> >broadcast the packet to a block, that is send to all members of the block except
>> >the port in which the packet arrived on. However, the user may specify
>> >the option "tx_type all", which will send the packet to all members of the
>> >block indiscriminately.
>> >
>> >Example usage:
>> > $ tc qdisc add dev ens7 ingress_block 22
>> > $ tc qdisc add dev ens8 ingress_block 22
>> >
>> >Now we can add a filter to broadcast packets to ports on ingress block id 22:
>> >$ tc filter add block 22 protocol ip pref 25 \
>> > flower dst_ip 192.168.0.0/16 action blockcast blockid 22
>>
>> Name the arg "block" so it is consistent with "filter add block". Make
>> sure this is aligned netlink-wise as well.
>>
>>
>> >
>> >Or if we wish to send to all ports in the block:
>> >$ tc filter add block 22 protocol ip pref 25 \
>> > flower dst_ip 192.168.0.0/16 action blockcast blockid 22 tx_type all
>>
>> I read the discussion the the previous version again. I suggested this
>> to be part of mirred. Why exactly that was not addressed?
>>
>
>I am the one who pushed back (in that discussion). Actions should be
>small and specific. Like i had said in that earlier discussion it was
>a mistake to make mirred do both mirror and redirect - they should
For mirror and redirect, I agree. For redirect and redirect, does not
make much sense. It's just confusing for the user.
>have been two actions. So i feel like adding a block to mirred is
>adding more knobs. We are also going to add dev->group as a way to
>select what devices to mirror to. Should that be in mirred as well?
I need more details.
>
>cheers,
>jamal
>
>> Instead of:
>> $ tc filter add block 22 protocol ip pref 25 \
>> flower dst_ip 192.168.0.0/16 action blockcast blockid 22
>> You'd have:
>> $ tc filter add block 22 protocol ip pref 25 \
>> flower dst_ip 192.168.0.0/16 action mirred egress redirect block 22
>>
>> I don't see why we need special action for this.
>>
>> Regarding "tx_type all":
>> Do you expect to have another "tx_type"? Seems to me a bit odd. Why not
>> to have this as "no_src_skip" or some other similar arg, without value
>> acting as a bool (flag) on netlink level.
>>
>>
next prev parent reply other threads:[~2023-11-23 14:04 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-10 21:46 [PATCH net-next RFC v5 0/4] net/sched: Introduce tc block ports tracking and use Victor Nogueira
2023-11-10 21:46 ` [PATCH net-next RFC v5 1/4] net/sched: act_mirred: Separate mirror and redirect into two distinct functions Victor Nogueira
2023-11-11 0:13 ` kernel test robot
2023-11-11 0:13 ` kernel test robot
2023-11-23 6:58 ` Jiri Pirko
2023-11-10 21:46 ` [PATCH net-next RFC v5 2/4] net/sched: Introduce tc block netdev tracking infra Victor Nogueira
2023-11-10 21:46 ` [PATCH net-next RFC v5 3/4] net/sched: cls_api: Expose tc block to the datapath Victor Nogueira
2023-11-10 21:46 ` [PATCH net-next RFC v5 4/4] net/sched: act_blockcast: Introduce blockcast tc action Victor Nogueira
2023-11-23 8:51 ` Jiri Pirko
2023-11-23 13:37 ` Jamal Hadi Salim
2023-11-23 14:04 ` Jiri Pirko [this message]
2023-11-23 14:38 ` Jamal Hadi Salim
2023-11-23 15:17 ` Jiri Pirko
2023-11-23 16:20 ` Jamal Hadi Salim
2023-11-23 16:51 ` Jiri Pirko
2023-11-23 16:21 ` Jamal Hadi Salim
2023-11-23 16:52 ` Jiri Pirko
2023-11-27 15:50 ` Jamal Hadi Salim
2023-11-27 18:52 ` Marcelo Ricardo Leitner
2023-12-01 18:45 ` Jamal Hadi Salim
2023-12-04 9:49 ` Jiri Pirko
2023-12-04 20:10 ` Jamal Hadi Salim
2023-12-05 8:41 ` Jiri Pirko
2023-12-05 14:51 ` Marcelo Ricardo Leitner
2023-12-05 15:27 ` Jamal Hadi Salim
2023-12-05 22:12 ` Marcelo Ricardo Leitner
2023-12-06 7:55 ` Jiri Pirko
2023-12-06 15:09 ` Jamal Hadi Salim
2023-11-23 14:29 ` Marcelo Ricardo Leitner
2023-11-23 15:18 ` Jiri Pirko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZV9b0HrM5WespGMW@nanopsycho \
--to=jiri@resnulli.us \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jhs@mojatatu.com \
--cc=kernel@mojatatu.com \
--cc=kuba@kernel.org \
--cc=mleitner@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=paulb@nvidia.com \
--cc=pctammela@mojatatu.com \
--cc=victor@mojatatu.com \
--cc=vladbu@nvidia.com \
--cc=xiyou.wangcong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.