Subject: Re: [RFC PATCH net-next 0/3] TC: Introduce qevents

From: Jiri Pirko <[email-masked]>
Date: Tue, 2 Jun 2020 08:05:55 +0200

Mon, Jun 01, 2020 at 09:50:23PM CEST, [email-masked] wrote:
>On Mon, Jun 1, 2020 at 6:40 AM Jiri Pirko <[email-masked]> 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.