From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from shards.monkeyblade.net (shards.monkeyblade.net [184.105.139.130]) (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 70E4A3B29E for ; Wed, 23 May 2018 17:20:13 -0400 (EDT) Received: from localhost (pool-173-77-163-54.nycmny.fios.verizon.net [173.77.163.54]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 54ABB14500547; Wed, 23 May 2018 14:20:11 -0700 (PDT) Date: Wed, 23 May 2018 17:20:08 -0400 (EDT) Message-Id: <20180523.172008.1067759293733489715.davem@davemloft.net> To: toke@toke.dk Cc: netdev@vger.kernel.org, cake@lists.bufferbloat.net, netfilter-devel@vger.kernel.org From: David Miller In-Reply-To: <87bmd6xeur.fsf@toke.dk> References: <87in7exg3d.fsf@toke.dk> <20180523.164152.387997944739062215.davem@davemloft.net> <87bmd6xeur.fsf@toke.dk> X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Wed, 23 May 2018 14:20:11 -0700 (PDT) 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 21:20:13 -0000 From: Toke H=F8iland-J=F8rgensen Date: Wed, 23 May 2018 23:05:16 +0200 > Ah, right, that could work. Is there any particular field in sk_buff > we should stomp on for this purpose, or would you prefer a new one? > Looking through it, the only obvious one that comes to mind is, well,= > skb->_nfct :) > = > If we wanted to avoid bloating sk_buff, we could add a union with tha= t, > fill it in the flow dissector, and just let conntrack overwrite it if= > active; then detect which is which in Cake, and read the data we need= > from _nfct if conntrack is active, and from what the flow dissector > stored otherwise. > = > Is that too many hoops to jump through to avoid adding an extra field= ? Space is precious in sk_buff, so yes avoid adding new members at all costs. How much info do you need exactly?