archive mirror
 help / color / mirror / Atom feed
From: Alexei Starovoitov <>
To: Pablo Neira Ayuso <>,
	Daniel Borkmann <>
Subject: Re: [PATCH net-next 0/2] handle_ing update
Date: Sun, 10 May 2015 10:55:23 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20150510170550.GA4442@salvia>

On 5/10/15 10:05 AM, Pablo Neira Ayuso wrote:
> On Sat, May 09, 2015 at 10:51:30PM +0200, Daniel Borkmann wrote:
>> These are a couple of cleanups to make ingress a bit more lightweight.
> This is plain wrong at many levels.
> You're persisting on embedding the ingress code into the core, and you
> have to remember that most users don't need this. Modules allows
> people to get the code that they need into the core, with this
> approach, they have no other choice other than disable from .config
> this if they don't need it.

I think you're misreading the patch set. Where do you see that this is
pushed on all users?
if (static_key_false(&ingress_needed))
still protects all of these bits.
When ingress qdisc is added, the key gets enabled and it only needs
one deref to not go any further. Much faster than it is today.

> This has to be done the other way around. I just sent a patchset to
> clean up this that in exactly the other direction, as a result,
> performance is improved for users that don't need this.

you're doing exactly the same in your patch set, but with added extra
overhead for netfilter hook.

> We should do things to make users aware that when they request
> features, they have to pay a performance cost, and that happens by
> when you invoke:
>          tc qdisc add dev eth0 handle ffff: ingress
> David already stated before that ingress path is performance critical,
> but you insist on trying to get qdisc ingress faster *at any cost*.

Nope. We're cleaning up ingress qdisc path _without_ affecting anything
else, whereas your netfilter hook creates binary choice for users
whether they want nft or tc.
Please just add your own netfilter hook to netif_receive_skb and
let's be done with this back and forth arguments.

  reply	other threads:[~2015-05-10 17:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-09 20:51 [PATCH net-next 0/2] handle_ing update Daniel Borkmann
2015-05-09 20:51 ` [PATCH net-next 1/2] net: sched: consolidate handle_ing and ing_filter Daniel Borkmann
2015-05-09 21:07   ` Alexei Starovoitov
2015-05-09 20:51 ` [PATCH net-next 2/2] net: sched: further simplify handle_ing Daniel Borkmann
2015-05-10 17:05 ` [PATCH net-next 0/2] handle_ing update Pablo Neira Ayuso
2015-05-10 17:55   ` Alexei Starovoitov [this message]
2015-05-10 18:06     ` Pablo Neira Ayuso
2015-05-11 15:09   ` David Miller
2015-05-11 22:03     ` Cong Wang
2015-05-11 22:23       ` Alexei Starovoitov
2015-05-11 22:42         ` Cong Wang
2015-05-11 22:33       ` Daniel Borkmann
2015-05-11 22:48         ` Cong Wang
2015-05-12 12:54     ` Pablo Neira Ayuso
2015-05-11 15:11 ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

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