All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Florian Westphal <fw@strlen.de>,
	netdev@vger.kernel.org, alexei.starovoitov@gmail.com
Subject: Re: [PATCH -next 0/5] replace skb tc_verd member with 3 dedicated bit flags
Date: Tue, 5 May 2015 15:06:08 +0200	[thread overview]
Message-ID: <20150505130608.GF17061@breakpoint.cc> (raw)
In-Reply-To: <5548B070.80502@mojatatu.com>

Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> It is borderline questionable for 1 bit but for consistency i
> suggest you do what was there before. I pointed to nocls but
> i meant the comment generically because previous code you are
> changing intended to use the macros.

True.

> In any case I will leave it up to you.

Okay, thanks Jamal.

I'll have to think about this wrt. how to proceed.

> >>- We need two bits for the location (ingress, egress, from stack)
> >>from stack being 0 i.e when it is not set implicitly it is from the
> >>host stack then we can check for ingress or egress when we choose.
> >
> >Hmm, are you sure?  How is that used?
> >
> 
> As example, when something like
> if (!(at & AT_EGRESS))
> implies it is either from ingress or the stack.
> It does not only from ingress.
> >In fact ifb will BUG() if neither AT_INGRESS or AT_EGRESS was set
> >in G_TC_FROM().
> >
> 
> Yes, because you cant send directly from the stack host to ifb. You
> can only redirect to it. If we ever end there from the host we should
> bug()

$ git grep G_TC_FROM | nl
1  drivers/net/ifb.c:              u32 from = G_TC_FROM(skb->tc_verd);
2  drivers/net/ifb.c:      u32 from = G_TC_FROM(skb->tc_verd);
3  include/uapi/linux/pkt_cls.h:#define G_TC_FROM(x)       _TC_GETVALUE(x,S_TC_FROM,M_TC_FROM)
4  net/sched/sch_netem.c:                  if (G_TC_FROM(skb->tc_verd) & AT_INGRESS)

#1 will BUG() if G_TC_FROM yields 0
#4 only cares about AT_INGRESS

I can indeed get #2 to return 'from 0', via:

ip link set dev ifb0 up
ip addr add  10.2.1.1/8 dev ifb0
ping 10.2.1.2

However, there is no user-visible behaviour change since skb->iif is 0 for locally generated
skb.  Since we do '(from == 0 || skb->iif == 0) -> drop' ifb will still be a /dev/null sink
without skb coming in via mirred action.

This also seems to work:
ip link set dev ifb0 up
ip link set dev eth1 up
ip addr add  192.168.42.1/24 dev eth1
tc qdisc add dev eth1 root handle 1: htb default 1
tc filter add dev eth1 parent 1: protocol all u32 match u32 0 0 action mirred egress redirect dev ifb0
ping -c 1 -b 192.168.42.255

iif is set to eth1 iif by the mirred action, so its nonzero by the time skb ends up in ifb and is redirected.

I fully admit that I did not consider this beforehand though ;)

Is there anything else I am missing?

Cheers,
Florian

      parent reply	other threads:[~2015-05-05 13:06 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-04 18:48 [PATCH -next 0/5] replace skb tc_verd member with 3 dedicated bit flags Florian Westphal
2015-05-04 18:48 ` [PATCH -next 1/5] net: sched: replace NCLS macro with tc_nocls bit flag Florian Westphal
2015-05-05 10:38   ` Daniel Borkmann
2015-05-05 23:15   ` David Miller
2015-05-04 18:48 ` [PATCH -next 2/5] net: sched: use counter to break reclassify loops Florian Westphal
2015-05-05 10:47   ` Daniel Borkmann
2015-05-04 18:48 ` [PATCH -next 3/5] net: sched: remove FROM INGRESS/EGRESS Florian Westphal
2015-05-05 10:51   ` Daniel Borkmann
2015-05-04 18:48 ` [PATCH -next 4/5] net: sched: remove AT INGRESS/EGRESS Florian Westphal
2015-05-05 11:06   ` Daniel Borkmann
2015-05-05 11:11     ` Florian Westphal
2015-05-04 18:48 ` [PATCH -next 5/5] skbuff: remove tc_verd member Florian Westphal
2015-05-05 11:09   ` Daniel Borkmann
2015-05-05 11:39 ` [PATCH -next 0/5] replace skb tc_verd member with 3 dedicated bit flags Jamal Hadi Salim
2015-05-05 11:47   ` Florian Westphal
2015-05-05 11:58     ` Jamal Hadi Salim
2015-05-05 12:37       ` Daniel Borkmann
2015-05-05 13:22         ` Jamal Hadi Salim
2015-05-05 13:06       ` Florian Westphal [this message]

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=20150505130608.GF17061@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=alexei.starovoitov@gmail.com \
    --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.