All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamal Hadi Salim <jhs@mojatatu.com>
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
	Linux Kernel Network Developers <netdev@vger.kernel.org>,
	David Miller <davem@davemloft.net>
Subject: Re: [Patch iproute2] u32: add terminal parameter
Date: Tue, 15 Apr 2014 09:00:18 -0400	[thread overview]
Message-ID: <534D2D62.5080109@mojatatu.com> (raw)
In-Reply-To: <CAM_iQpV8GeEQr+GFFy2Etct_51YhvXEBKydyH9q4NP5QbsDOnA@mail.gmail.com>

On 04/14/14 21:57, Cong Wang wrote:

> So essentially why u32 filters can't just do matching without bothering

u32 is a special animal. You can actually have intermediate nodes
which are _not_ terminal. i.e you can build a tree of hashes which
interconnect other hashes eventually leading to terminal nodes.

> classid especially when they are attached to an ingress qdisc? I still
> fail to see a reason why I have to care about classid here.

It is more of a historical artifact with "benefits".
Historical in that egress qdiscs with classes existed before ingress;
so it makes sense to keep the syntax people are already familiar with.
Benefits because infact with the right approach the flowid even at
ingress can be used as input(look at the route classifier for example
and association with route accounting of the source).


cheers,
jamal

  reply	other threads:[~2014-04-15 13:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-04 17:17 [Patch iproute2] u32: add terminal parameter Cong Wang
2014-04-11 21:04 ` Stephen Hemminger
2014-04-12  0:45   ` Cong Wang
2014-04-12  0:58     ` Stephen Hemminger
2014-04-12  1:15       ` Cong Wang
2014-04-12 11:43         ` Jamal Hadi Salim
2014-04-14 21:18           ` Cong Wang
2014-04-14 23:14             ` Jamal Hadi Salim
2014-04-15  1:57               ` Cong Wang
2014-04-15 13:00                 ` Jamal Hadi Salim [this message]
2014-04-15 20:17                   ` Cong Wang
2014-04-16 12:19                     ` Jamal Hadi Salim

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=534D2D62.5080109@mojatatu.com \
    --to=jhs@mojatatu.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=stephen@networkplumber.org \
    --cc=xiyou.wangcong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.