All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Florian Westphal <fw@strlen.de>,
	netdev@vger.kernel.org, jhs@mojatatu.com, daniel@iogearbox.net
Subject: Re: [PATCH -next 2/3] net: sched: remove AT INGRESS/EGRESS
Date: Sat, 16 May 2015 00:22:54 +0200	[thread overview]
Message-ID: <20150515222254.GL6179@breakpoint.cc> (raw)
In-Reply-To: <20150515200944.GA8527@Alexeis-MacBook-Pro.local>

Alexei Starovoitov <alexei.starovoitov@gmail.com> 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,

Thanks.

> but it removes information in a way that will be very hard to add it later.

Are you sure?  Would you mind elaborating a bit?

> > 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.

Hmm... I'm sorry, I fail to understand where problem is.

> If we make stack==egress, I would need to refactor this code all over again.

If you mean "skb was not forwarded", you could just check for
skb->skb_iif = 0?

If not, what info do you need, and why could we not extend proposed enum
if absolutely required?

> It's not broken today. You're doing this aliasing only two squeeze a bit.

Yep, but its was also to minimize the state machinery down to whats
required.

Sorry Alexei, I'm just trying to find out what exactly is needed,
perhaps if you can clarify/explain I might be able to re-spin this in a
way that will meet your requirements.

  reply	other threads:[~2015-05-15 22:22 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 [this message]
2015-05-15 22:43         ` Jamal Hadi Salim
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=20150515222254.GL6179@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=alexei.starovoitov@gmail.com \
    --cc=daniel@iogearbox.net \
    --cc=jhs@mojatatu.com \
    --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.