[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200602060555.GR2282@nanopsycho>
Date: Tue, 2 Jun 2020 08:05:55 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Cong Wang <xiyou.wangcong@...il.com>
Cc: Petr Machata <petrm@...lanox.com>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
Jakub Kicinski <kuba@...nel.org>,
Eric Dumazet <eric.dumazet@...il.com>,
Jamal Hadi Salim <jhs@...atatu.com>,
Jiri Pirko <jiri@...lanox.com>,
Ido Schimmel <idosch@...lanox.com>
Subject: Re: [RFC PATCH net-next 0/3] TC: Introduce qevents
Mon, Jun 01, 2020 at 09:50:23PM CEST, xiyou.wangcong@...il.com wrote:
>On Mon, Jun 1, 2020 at 6:40 AM Jiri Pirko <jiri@...nulli.us> wrote:
>> The first command just says "early drop position should be processed by
>> block 10"
>>
>> The second command just adds a filter to the block 10.
>
>This is exactly why it looks odd to me, because it _reads_ like
>'tc qdisc' creates the block to hold tc filters... I think tc filters should
>create whatever placeholder for themselves.
That is how it is done already today. We have the block object. The
instances are created separatelly (clsact for example), user may specify
the block id to identify the block. Then the user may use this block id
to add/remove filters directly to/from the block.
What you propose with "position" on the other hand look unnatural for
me. It would slice the exising blocks in some way. Currently, the block
has 1 clearly defined entrypoint. With "positions", all of the sudden
there would be many of them? I can't really imagine how that is supposed
to work :/
>
>I know in memory block (or chain or filters) are stored in qdisc, but
>it is still different to me who initiates the creation.
Qdiscs create blocks.
>
>Thanks.
Powered by blists - more mailing lists