From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.us.es (mail.us.es [193.147.175.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id D2CB63B29E for ; Wed, 23 May 2018 18:46:59 -0400 (EDT) Received: from antivirus1-rhel7.int (unknown [192.168.2.11]) by mail.us.es (Postfix) with ESMTP id 492A31E8FAD for ; Thu, 24 May 2018 00:45:53 +0200 (CEST) Received: from antivirus1-rhel7.int (localhost [127.0.0.1]) by antivirus1-rhel7.int (Postfix) with ESMTP id 31664DA4C7 for ; Thu, 24 May 2018 00:45:53 +0200 (CEST) Received: by antivirus1-rhel7.int (Postfix, from userid 99) id 26DF2DA73F; Thu, 24 May 2018 00:45:53 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on antivirus1-rhel7.int X-Spam-Level: X-Spam-Status: No, score=-108.2 required=7.5 tests=ALL_TRUSTED,BAYES_50, SMTPAUTH_US2, URIBL_BLOCKED, USER_IN_WHITELIST autolearn=disabled version=3.4.1 Received: from antivirus1-rhel7.int (localhost [127.0.0.1]) by antivirus1-rhel7.int (Postfix) with ESMTP id 1A7E2DA727; Thu, 24 May 2018 00:45:51 +0200 (CEST) Received: from 192.168.1.97 (192.168.1.97) by antivirus1-rhel7.int (F-Secure/fsigk_smtp/550/antivirus1-rhel7.int); Thu, 24 May 2018 00:45:51 +0200 (CEST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/antivirus1-rhel7.int) Received: from us.es (sys.soleta.eu [212.170.55.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 1984lsi) by entrada.int (Postfix) with ESMTPSA id EDEAD4265A4E; Thu, 24 May 2018 00:45:50 +0200 (CEST) Date: Thu, 24 May 2018 00:46:53 +0200 X-SMTPAUTHUS: auth mail.us.es From: Pablo Neira Ayuso To: Toke =?iso-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: netdev@vger.kernel.org, cake@lists.bufferbloat.net, netfilter-devel@vger.kernel.org Message-ID: <20180523224653.mvxkibc4x37nbhha@salvia> References: <152699741881.21931.11656377745581563912.stgit@alrua-kau> <152699745846.21931.4558451708304709296.stgit@alrua-kau> <20180522140759.2rl25eggaoaecw4m@salvia> <87k1rvg4qt.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87k1rvg4qt.fsf@toke.dk> User-Agent: NeoMutt/20170113 (1.7.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Wed, 23 May 2018 19:24:52 -0400 Subject: Re: [Cake] [PATCH net-next v15 4/7] sch_cake: Add NAT awareness to packet classifier X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 22:47:00 -0000 On Tue, May 22, 2018 at 04:11:06PM +0200, Toke Høiland-Jørgensen wrote: > Pablo Neira Ayuso writes: > > > Hi Toke, > > > > On Tue, May 22, 2018 at 03:57:38PM +0200, Toke Høiland-Jørgensen wrote: > >> When CAKE is deployed on a gateway that also performs NAT (which is a > >> common deployment mode), the host fairness mechanism cannot distinguish > >> internal hosts from each other, and so fails to work correctly. > >> > >> To fix this, we add an optional NAT awareness mode, which will query the > >> kernel conntrack mechanism to obtain the pre-NAT addresses for each packet > >> and use that in the flow and host hashing. > >> > >> When the shaper is enabled and the host is already performing NAT, the cost > >> of this lookup is negligible. However, in unlimited mode with no NAT being > >> performed, there is a significant CPU cost at higher bandwidths. For this > >> reason, the feature is turned off by default. > >> > >> Cc: netfilter-devel@vger.kernel.org > >> Signed-off-by: Toke Høiland-Jørgensen > >> --- > >> net/sched/sch_cake.c | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++ > >> 1 file changed, 79 insertions(+) > >> > >> diff --git a/net/sched/sch_cake.c b/net/sched/sch_cake.c > >> index 68ac908470f1..6f7cae705c84 100644 > >> --- a/net/sched/sch_cake.c > >> +++ b/net/sched/sch_cake.c > >> @@ -71,6 +71,12 @@ > >> #include > >> #include > >> > >> +#if IS_REACHABLE(CONFIG_NF_CONNTRACK) > >> +#include > >> +#include > >> +#include > >> +#endif > >> + > >> #define CAKE_SET_WAYS (8) > >> #define CAKE_MAX_TINS (8) > >> #define CAKE_QUEUES (1024) > >> @@ -516,6 +522,60 @@ static bool cobalt_should_drop(struct cobalt_vars *vars, > >> return drop; > >> } > >> > >> +#if IS_REACHABLE(CONFIG_NF_CONNTRACK) > >> + > >> +static void cake_update_flowkeys(struct flow_keys *keys, > >> + const struct sk_buff *skb) > >> +{ > >> + const struct nf_conntrack_tuple *tuple; > >> + enum ip_conntrack_info ctinfo; > >> + struct nf_conn *ct; > >> + bool rev = false; > >> + > >> + if (tc_skb_protocol(skb) != htons(ETH_P_IP)) > >> + return; > >> + > >> + ct = nf_ct_get(skb, &ctinfo); > >> + if (ct) { > >> + tuple = nf_ct_tuple(ct, CTINFO2DIR(ctinfo)); > >> + } else { > >> + const struct nf_conntrack_tuple_hash *hash; > >> + struct nf_conntrack_tuple srctuple; > >> + > >> + if (!nf_ct_get_tuplepr(skb, skb_network_offset(skb), > >> + NFPROTO_IPV4, dev_net(skb->dev), > >> + &srctuple)) > >> + return; > >> + > >> + hash = nf_conntrack_find_get(dev_net(skb->dev), > >> + &nf_ct_zone_dflt, > >> + &srctuple); > >> + if (!hash) > >> + return; > >> + > >> + rev = true; > >> + ct = nf_ct_tuplehash_to_ctrack(hash); > >> + tuple = nf_ct_tuple(ct, !hash->tuple.dst.dir); > >> + } > >> + > >> + keys->addrs.v4addrs.src = rev ? tuple->dst.u3.ip : tuple->src.u3.ip; > >> + keys->addrs.v4addrs.dst = rev ? tuple->src.u3.ip : tuple->dst.u3.ip; > >> + > >> + if (keys->ports.ports) { > >> + keys->ports.src = rev ? tuple->dst.u.all : tuple->src.u.all; > >> + keys->ports.dst = rev ? tuple->src.u.all : tuple->dst.u.all; > >> + } > >> + if (rev) > >> + nf_ct_put(ct); > >> +} > > > > This is going to pull in the nf_conntrack module, even if you may not > > want it, as soon as cake is in place. > > Yeah, we are aware of that; we get a moddep on nf_conntrack. Our main > deployment scenario has been home routers where conntrack is used > anyway, so this has not been much of an issue. However, if there is a > way to avoid this, and instead detect at runtime if conntrack is > available, that would certainly be useful. Is there? :) Yes, there is. You place this function in net/netfilter/nf_conntrack_core.c, call it nf_conntrack_get_tuple() which internally uses a rcu hook for this. See nf_ct_attach() and ip_ct_attach() in net/netfilter/core.c for instance. This allows you to avoid the dependency with nf_conntrack (which would be only called if the module has been explicitly loaded), which is what you're searching for.