All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamal Hadi Salim <jhs@mojatatu.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Florian Westphal <fw@strlen.de>
Cc: netdev@vger.kernel.org, daniel@iogearbox.net
Subject: Re: [PATCH -next 2/3] net: sched: remove AT INGRESS/EGRESS
Date: Fri, 15 May 2015 18:43:07 -0400	[thread overview]
Message-ID: <5556767B.2010700@mojatatu.com> (raw)
In-Reply-To: <20150515200944.GA8527@Alexeis-MacBook-Pro.local>

On 05/15/15 16:09, Alexei Starovoitov wrote:
> On Fri, May 15, 2015 at 07:21:15PM +0200, Florian Westphal wrote:
>> So, from ifb point of view it makes no difference, G_TC_FROM+AT_STACK
>> causes skb to be dropped and IFB doesn't care about G_TC_AT() at all.
>
> yes. your change is technically correct. It's not causing ifb regression,
> but it removes information in a way that will be very hard to add it later.
>
>> AT_STACK cannot even happen for the G_TC_AT case from looking at the
>> code since dev_queue_xmit forces AT_EGRESS & rx sets AT_INGRESS.
>
> yes, if we only consider ingress and egress hooks.
> I want to use this stack/ingress/egress indication with socket filters.
> If we make stack==egress, I would need to refactor this code all over again.
> It's not broken today. You're doing this aliasing only two squeeze a bit.
> That's why I'm saying keep the stack/ingress/egress flag as-is. It's useful.
>

My point as well. Using ifb or mirred as examples is fine
but they are not the only potential consumers/producers. Using examples
as such is out of place when it is an architectural issue.
So i would rather this be left alone.

cheers,
jamal

  parent reply	other threads:[~2015-05-15 22:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-15  8:50 [PATCH -next 0/3] tc state machinery cleanups Florian Westphal
2015-05-15  8:50 ` [PATCH -next 1/3] net: sched: remove FROM INGRESS/EGRESS Florian Westphal
2015-05-15  8:50 ` [PATCH -next 2/3] net: sched: remove AT INGRESS/EGRESS Florian Westphal
2015-05-15 16:23   ` Alexei Starovoitov
2015-05-15 17:21     ` Florian Westphal
2015-05-15 20:09       ` Alexei Starovoitov
2015-05-15 22:22         ` Florian Westphal
2015-05-15 22:43         ` Jamal Hadi Salim [this message]
2015-05-15  8:50 ` [PATCH -next 3/3] net: core: use skb_tc_state to skip ingress classifiers Florian Westphal
2015-05-15 11:36 ` [PATCH -next 0/3] tc state machinery cleanups Jamal Hadi Salim
2015-05-15 11:59   ` Florian Westphal
2015-05-15 13:11   ` Daniel Borkmann
2015-05-18  3:34 ` David Miller

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=5556767B.2010700@mojatatu.com \
    --to=jhs@mojatatu.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=daniel@iogearbox.net \
    --cc=fw@strlen.de \
    --cc=netdev@vger.kernel.org \
    /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.