[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170428222928.GA1905@nanopsycho.orion>
Date: Sat, 29 Apr 2017 00:29:28 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Cong Wang <xiyou.wangcong@...il.com>
Cc: Linux Kernel Network Developers <netdev@...r.kernel.org>,
David Miller <davem@...emloft.net>,
Jamal Hadi Salim <jhs@...atatu.com>,
David Ahern <dsa@...ulusnetworks.com>,
Eric Dumazet <edumazet@...gle.com>,
Stephen Hemminger <stephen@...workplumber.org>,
Daniel Borkmann <daniel@...earbox.net>,
Alexander Duyck <alexander.h.duyck@...el.com>,
mlxsw@...lanox.com, Simon Horman <simon.horman@...ronome.com>
Subject: Re: [patch net-next 02/10] net: sched: introduce tcf block
infractructure
Fri, Apr 28, 2017 at 07:48:34PM CEST, xiyou.wangcong@...il.com wrote:
>On Thu, Apr 27, 2017 at 4:12 AM, Jiri Pirko <jiri@...nulli.us> wrote:
>> From: Jiri Pirko <jiri@...lanox.com>
>>
>> Currently, the filter chains are direcly put into the private structures
>> of qdiscs. In order to be able to have multiple chains per qdisc and to
>> allow filter chains sharing among qdiscs, there is a need for common
>> object that would hold the chains. This introduces such object and calls
>> it "tcf_block".
>>
>
>What is filter chains sharing here? Sounds like a new feature you are
>trying to hide? How could it be possibly shared among qdisc's when they
>are still stored in a per-qdisc pointer?
I can change the description. I just found out that eventually, later
on, the blocks could be shared among qdiscs. It is not part of this
patchset. Just this change of infra is bringing this one step closer.
I can imagine that the blocks could have indexes and when you create a
qdisc you could pass this index of an existing block.
Not trying to hide anything!
>
>Look at tc actions, they can be shared because they are physically stored
>in a per-netns hashtable, filters can just refer them with indexes.
Powered by blists - more mailing lists