From: Jiri Pirko <jiri@resnulli•us>
To: Jamal Hadi Salim <jhs@mojatatu•com>
Cc: Cong Wang <xiyou.wangcong@gmail•com>,
John Fastabend <john.fastabend@gmail•com>,
David Miller <davem@davemloft•net>,
Linux Kernel Network Developers <netdev@vger•kernel.org>,
mlxsw@mellanox•com
Subject: Re: Qdisc->u32_node - licence to kill
Date: Wed, 9 Aug 2017 14:48:34 +0200 [thread overview]
Message-ID: <20170809124834.GC1867@nanopsycho> (raw)
In-Reply-To: <c296f4c2-3509-a162-e972-42c2e81434aa@mojatatu.com>
Wed, Aug 09, 2017 at 02:40:30PM CEST, jhs@mojatatu•com wrote:
>On 17-08-07 07:21 PM, Cong Wang wrote:
>> On Mon, Aug 7, 2017 at 12:54 PM, John Fastabend
>> <john.fastabend@gmail•com> wrote:
>> > On 08/07/2017 12:06 PM, Jiri Pirko wrote:
>> > > Mon, Aug 07, 2017 at 07:47:14PM CEST, john.fastabend@gmail•com wrote:
>> > > > On 08/07/2017 09:41 AM, Jiri Pirko wrote:
>> > > > > Hi Jamal/Cong/David/all.
>> > > > >
>=
>> > >
>> > > Not correct. prio/pref is one level up priority, independent on specific
>> > > cls implementation. You can have cls_u32 instance on prio 10 and
>> > > cls_flower instance on prio 20. Both work.
>> >
>> > ah right, lets make sure I got this right then (its been awhile since I've
>> > read this code). So the tcf_ctl_tfilter hook walks classifiers, inserting the
>> > classifier by prio. Then tcf_classify walks the list of classifiers looking
>> > for any matches, specifically any return codes it recognizes or a return code
>> > greater than zero. u32 though has this link notion that allows users to jump
>> > to other u32 classifiers that are in this list, because it has a global hash
>> > table list. So the per prio classifier isolation is not true in u32 case.
>>
>> u32 filter supports multiple hash tables within a qdisc, struct
>> tc_u_common is supposed to link them together. This has to be
>> per qdisc because all of these hash tables belong to one qdisc
>> and their ID's are unique within the qdisc.
>>
>
>I think historically this used to sit within the u32 code as a
>static linked list; i cant recall why it got attached to the
>qdisc.
>Indeed, the idea is that hash tables can be added independently
>without linking and then linked afterwards. They have to be held
>somewhere in transient. And they have priorities (at least the
>prios are used in the dump)
>
>> I dislike it too, and I actually tried to improve it in the past,
>> unfortunately didn't make any real progress. I think we can
>> definitely make it less ugly, but I don't think we can totally
>> get rid of it because of the design of u32.
>>
>> Similar for tp->data.
>>
>
>tp->q maybe harder to deal with. I agree with getting rid of
>this dependency. Could this info be stored in the block instead?
Yeah, I will have to do that. I just wanted to get rid of it if possible :/
>
>cheers,
>jamal
prev parent reply other threads:[~2017-08-09 12:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-07 16:41 Qdisc->u32_node - licence to kill Jiri Pirko
2017-08-07 17:47 ` John Fastabend
2017-08-07 19:06 ` Jiri Pirko
2017-08-07 19:54 ` John Fastabend
2017-08-07 23:21 ` Cong Wang
2017-08-09 12:40 ` Jamal Hadi Salim
2017-08-09 12:48 ` Jiri Pirko [this message]
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=20170809124834.GC1867@nanopsycho \
--to=jiri@resnulli$(echo .)us \
--cc=davem@davemloft$(echo .)net \
--cc=jhs@mojatatu$(echo .)com \
--cc=john.fastabend@gmail$(echo .)com \
--cc=mlxsw@mellanox$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=xiyou.wangcong@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox