netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Florian Westphal <fw@strlen.de>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Pablo Neira Ayuso <pablo@netfilter.org>,
	netfilter-devel@vger.kernel.org, davem@davemloft.net,
	netdev@vger.kernel.org, kaber@trash.net
Subject: Re: [PATCH 0/4] Netfilter ingress support (v3)
Date: Mon, 4 May 2015 20:59:41 +0200	[thread overview]
Message-ID: <20150504185941.GA17061@breakpoint.cc> (raw)
In-Reply-To: <5547BEC4.4090400@mojatatu.com>

Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> On 05/04/15 13:43, Florian Westphal wrote:
> >Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> >Please don't accuse anyone of being 'evil'.
> >
> 
> It is a figure of speech and was intended to be humorous.
> I consider Pablo a friend, sorry if that came out wrong.

Ugh.  I'm sorry Jamal, seems I lack a sense of humor.
In any case, no offense taken.

> >I think that tc and netfilter are both broken by design in the sense
> >that we have two different systems with partially overlapping
> >functionality while interaction between them consists of hacks.
> >
> >It works both ways, iptables CLASSIFY target is also not very
> >elegant from a design point of view, it bolts the packet/connection matching
> >functionality provided by iptables to qdisc hierarchy.
> >
> 
> Well, from the tc perspective the angle has been one of laziness
> and avoiding to rewrite any features that netfilter has. Essentially
> a gateway-to-iptables. It has not been easy.

Right, I can imagine that.

> It does look silly if we copy things netfilter does in our view.

Sure, that would not be good either (perhaps even worse).

> >>think is that distros which ship with iptables rules and conntracking
> >>on are going to not even turn on tc and my scripts now have to go
> >>unload one.
> >
> >You mean add 'rmmod nft_ingress' or something similar?
> >
> >That might be a problem.  One possible way out would be to
> >make 'tc qdisc add dev eth0 ingress' silently unregister nft ingress
> >on kernel side (but not vice versa).
> >
> >Not nice, but it would keep compatibility with tc ingress scripts.
> >
> 
> Assuming there is something else using the nft side, now they break
> because tc has taken over.

Well, thats true.  But I would not care at this point (in the 'nft
ingress breaks when tc takes over') case.

I'd first like to see what distros would do (by default, that is).

I'd prefer to not base a 'we need to support both at same time' decision
on speculation as to what some distribution might do at some point.

Anything that makes sure that tc ingress doesn't break is fine.
If that turns out to be 'two hooks' then, alas, so be it.

I'd just like some evidence first 8-)

  reply	other threads:[~2015-05-04 18:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-04 10:50 [PATCH 0/4] Netfilter ingress support (v3) Pablo Neira Ayuso
2015-05-04 10:50 ` [PATCH 1/4] net: add minimalistic ingress filter hook and port sch_ingress on top of it Pablo Neira Ayuso
2015-05-04 10:50 ` [PATCH 2/4] netfilter: cleanup struct nf_hook_ops indentation Pablo Neira Ayuso
2015-05-04 10:50 ` [PATCH 3/4] netfilter: add hook list to nf_hook_state Pablo Neira Ayuso
2015-05-04 10:50 ` [PATCH 4/4] net: add netfilter ingress hook Pablo Neira Ayuso
2015-05-04 15:56 ` [PATCH 0/4] Netfilter ingress support (v3) Alexei Starovoitov
2015-05-04 16:19   ` Florian Westphal
2015-05-04 17:21     ` Jamal Hadi Salim
2015-05-04 17:43       ` Florian Westphal
2015-05-04 18:47         ` Jamal Hadi Salim
2015-05-04 18:59           ` Florian Westphal [this message]
2015-05-04 20:05             ` Alexei Starovoitov
2015-05-04 22:21               ` Pablo Neira Ayuso
2015-05-04 23:04                 ` Thomas Graf

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=20150504185941.GA17061@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=alexei.starovoitov@gmail.com \
    --cc=davem@davemloft.net \
    --cc=jhs@mojatatu.com \
    --cc=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.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 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).