[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_iQpVj_FHUBGsuBoCAPTbB5416MZ9GoFJVb-+a6C58NaFzJA@mail.gmail.com>
Date: Fri, 29 Jun 2018 15:18:02 -0700
From: Cong Wang <xiyou.wangcong@...il.com>
To: sridhar.samudrala@...el.com
Cc: Jiri Pirko <jiri@...nulli.us>, David Ahern <dsahern@...il.com>,
Jamal Hadi Salim <jhs@...atatu.com>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
David Miller <davem@...emloft.net>,
Jakub Kicinski <jakub.kicinski@...ronome.com>,
Simon Horman <simon.horman@...ronome.com>,
john.hurley@...ronome.com, mlxsw@...lanox.com
Subject: Re: [patch net-next v2 0/9] net: sched: introduce chain templates
support with offloading to mlxsw
On Fri, Jun 29, 2018 at 10:06 AM Samudrala, Sridhar
<sridhar.samudrala@...el.com> wrote:
>
> So instead of introducing 'chaintemplate' object in the kernel, can't we add 'chain'
> object in the kernel that takes the 'template' as an attribute?
This is exactly what I mean above. Making the chain a standalone object
in kernel would benefit:
1. Align with 'tc chain' in iproute2, add/del an object is natural
2. Template is an attribute of this object when creating it:
# tc chain add template ....
# tc chain add ... # non-template chain
3. Easier for sharing by qdiscs:
# tc chain add X block Y ...
# tc filter add ... chain X block Y ...
# tc qdisc add dev eth0 block Y ...
The current 'ingress_block 22 ingress' syntax is ugly.
Powered by blists - more mailing lists