From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 838833B29E for ; Wed, 23 May 2018 17:05:21 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1527109518; bh=XwDSK7UqDEDF21aKQln3CWJyc32es8JVIvhDMNIeT+M=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=skb7Dzgf2+o/u1t793G7SBBP21/QSB2XybloozMJy2FJXnSkGsf4vS5ZGLBBpe70t DYz/nFapW6xrNC0mWbhe9YIEgicUfwvexVTyQwYbrMzLB/XpPGoXbcxGYBufQKzKAa AGcSEMmdZJ9Z++WL03N1X9SkOZBmO1RyZ3JRuQF6LBuDz+zEb86LVqLe0AOCDK5cou pj0DQncgFX1YWgwLhvSWjt8DF/10s0B7J7vHK1EMh703APYYCO3SpkmPr9WxSdKRzS 51Q2trn0QKHRGSh3t5QkwrfHxa+4pJDaBoY8e1Pm02gcMUyKcyQTZPR5Zw3Xt+gY9g o3Eiy0MrSgdkw== To: David Miller Cc: netdev@vger.kernel.org, cake@lists.bufferbloat.net, netfilter-devel@vger.kernel.org In-Reply-To: <20180523.164152.387997944739062215.davem@davemloft.net> References: <152699745846.21931.4558451708304709296.stgit@alrua-kau> <20180523.144442.864194409238516747.davem@davemloft.net> <87in7exg3d.fsf@toke.dk> <20180523.164152.387997944739062215.davem@davemloft.net> Date: Wed, 23 May 2018 23:05:16 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87bmd6xeur.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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:05:21 -0000 David Miller writes: > From: Toke H=C3=B8iland-J=C3=B8rgensen > Date: Wed, 23 May 2018 22:38:30 +0200 > >> How would this work? > > On egress the core networking flow dissector records what you need > somewhere in SKB or wherever. You later retrieve it at egress time > after NAT has occurred. 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 that, 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? -Toke