netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shmulik Ladkani <shmulik.ladkani@gmail.com>
To: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Florian Westphal <fw@strlen.de>,
	Jamal Hadi Salim <jhs@mojatatu.com>,
	"David S. Miller" <davem@davemloft.net>,
	WANG Cong <xiyou.wangcong@gmail.com>,
	Eric Dumazet <edumazet@google.com>,
	netdev@vger.kernel.org, Daniel Borkmann <daniel@iogearbox.net>
Subject: Re: [PATCH net-next 4/4] net/sched: act_mirred: Implement ingress actions
Date: Mon, 26 Sep 2016 18:26:54 +0300	[thread overview]
Message-ID: <20160926182654.292838e6@halley> (raw)
In-Reply-To: <54aa5404-f4c8-03e1-0b62-8c070bd6d65b@stressinduktion.org>

Hi,

On Mon, 26 Sep 2016 16:43:16 +0200 Hannes Frederic Sowa <hannes@stressinduktion.org> wrote:
> On 26.09.2016 03:35, Florian Westphal wrote:
> > 
> > Yes, but I think we get same issue when we deal with stacked
> > interfaces, and redirect is to e.g. vlan on top of physical device.  
> 
> We do have the adjacent upper lists in all netdevices, calculating if a
> mirred actions would insert the skb on a stacked device above us should
> be as easy as querying netdev_has_upper_dev and should be possible to
> check that during config time.

This does not seem the right direction:

- We should NOT ban egress redirect to an "upper device", this limits
  flexibility available today:
  One may validly redirect to an "upper device" according to a very
  specific criteria such that the skb will NOT be caught again by the
  filter when re-iterated down the stack.

- And even if we did, at "config time" as you say, one can always stack
  the target device ontop the filtered device at a LATER time.
  And obviously, testing "is upper" while executing action is a bad idea.

- Moreover, as Daniel noted, this is just a band-aid which limitely
  addresses only few of the already existing troubles with stacked
  virtual netdevices (with or without act_mirred).

Frankly, I think the loop-detection suggestions overload act_mirred
with AI that might imply limitations not well assessed (even on existing
usecases).

If needed, I'd go with the "recursion detection" suggested by Daniel,
which is simple and aids with the issues of "egress" redirect that
already exist today.

Moreover, as the patch series is all about "ingress redirect" support,
the "recursion detection" deserves a series of its own, we shouldn't
bundle these two distinct features.

Regards,
Shmulik

  parent reply	other threads:[~2016-09-26 15:27 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-22 13:21 [PATCH net-next 0/4] act_mirred: Ingress actions support Shmulik Ladkani
2016-09-22 13:21 ` [PATCH net-next 1/4] net/sched: act_mirred: Rename tcfm_ok_push to tcfm_mac_header_xmit Shmulik Ladkani
2016-09-27 10:30   ` Daniel Borkmann
2016-09-27 18:24     ` Shmulik Ladkani
2016-09-22 13:21 ` [PATCH net-next 2/4] net/sched: act_mirred: Refactor detection whether dev needs xmit at mac header Shmulik Ladkani
2016-09-22 13:21 ` [PATCH net-next 3/4] net/sched: tc_mirred: Rename public predicates 'is_tcf_mirred_redirect' and 'is_tcf_mirred_mirror' Shmulik Ladkani
2016-09-22 13:21 ` [PATCH net-next 4/4] net/sched: act_mirred: Implement ingress actions Shmulik Ladkani
2016-09-22 14:54   ` Eric Dumazet
2016-09-22 18:27     ` Shmulik Ladkani
2016-09-22 18:42       ` Eric Dumazet
2016-09-22 23:40   ` Jamal Hadi Salim
2016-09-23  5:11     ` Shmulik Ladkani
2016-09-23 12:48       ` Jamal Hadi Salim
2016-09-23 15:40         ` Shmulik Ladkani
2016-09-25  0:20           ` Cong Wang
2016-09-25 13:05           ` Jamal Hadi Salim
2016-09-25 16:26             ` Daniel Borkmann
2016-09-25 18:33               ` Florian Westphal
2016-09-25 23:47                 ` Jamal Hadi Salim
2016-09-25 23:31               ` Jamal Hadi Salim
2016-09-25 17:33             ` Shmulik Ladkani
2016-09-25 18:31               ` Florian Westphal
2016-09-26  1:15                 ` Jamal Hadi Salim
2016-09-26  1:35                   ` Florian Westphal
2016-09-26  1:40                     ` Jamal Hadi Salim
2016-09-26 14:43                     ` Hannes Frederic Sowa
2016-09-26 14:53                       ` Daniel Borkmann
2016-09-26 15:12                         ` Hannes Frederic Sowa
2016-09-26 15:53                           ` Daniel Borkmann
2016-09-26 15:26                       ` Shmulik Ladkani [this message]
2016-09-25 23:45               ` Jamal Hadi Salim
2016-09-25  0:07       ` Cong Wang
2016-09-25 13:39         ` Jamal Hadi Salim
2016-09-26  4:55           ` Cong Wang
2016-09-25 17:59         ` Shmulik Ladkani
2016-09-26  4:56           ` Cong Wang
2016-09-24 23:50   ` Cong Wang
2016-09-27  5:56   ` David Miller
2016-09-27  8:07     ` Shmulik Ladkani
2016-09-27 10:39       ` Daniel Borkmann
2016-09-27 13:44         ` David Miller
2016-09-27 14:18           ` Shmulik Ladkani
2016-09-27 14:47             ` Daniel Borkmann
2016-09-27 14:06       ` 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=20160926182654.292838e6@halley \
    --to=shmulik.ladkani@gmail.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fw@strlen.de \
    --cc=hannes@stressinduktion.org \
    --cc=jhs@mojatatu.com \
    --cc=netdev@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).