From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B2BEC3B29E for ; Wed, 23 May 2018 18:40:50 -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=1527115249; bh=vQWtvdzN/BJ/G00gllUdSW+UXwwiYB9VKqiD40/qX5M=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=QvH87HzNBy7YQUhq6RC5QALrH8VOiGqCMu4irOmg04zYC5mMmjL8+b0upomffOOao nhyDmEG81/KuJp9npw74fTIsLuUwd9M4+h+61PJV6xmPuehf2VSqtsWjTYbefeHzBc shVkPMYsGCLzEDW+IH7STOy2gi10SyN101kDSTFddkpqJV3yf/Z818vC1iPQw1DEGM 6yTjVHcSne6AYG2ImJHSg3wn1rzxrB/A0hvtUU4k1mcgvCSZ/rUTUxMTFJqrYzJaJn YjrAPRTXboLxHkq+9evmxKoC4xiK/BVFJ9ncpdT2h4O3AKuEn/jdXL+zgbw1kKN2Ze 6V0MCG2Pd9/aQ== To: David Miller Cc: netdev@vger.kernel.org, cake@lists.bufferbloat.net, netfilter-devel@vger.kernel.org In-Reply-To: <20180523.172008.1067759293733489715.davem@davemloft.net> References: <87in7exg3d.fsf@toke.dk> <20180523.164152.387997944739062215.davem@davemloft.net> <87bmd6xeur.fsf@toke.dk> <20180523.172008.1067759293733489715.davem@davemloft.net> Date: Thu, 24 May 2018 00:40:47 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <878t8axafk.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 22:40:50 -0000 David Miller writes: > From: Toke H=C3=B8iland-J=C3=B8rgensen > 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 :) >>=20 >> 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. >>=20 >> 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? We use a u32 hash (from flow_hash_from_keys()) on the source address. Ideally we'd want that; but we could get away with less if we are willing to accept more hash collisions; we just need to map the source address into a hash bucket. We currently have 1024 of those, so 10 bits would suffice if we just drop the set-associative hashing for source hosts. Or maybe 16 bits to be on the safe side? It really is a pretty straight-forward tradeoff between space and collision probability. Hmm, and we still have an issue with ingress filtering (where cake is running on an ifb interface). That runs pre-NAT in the conntrack case, and we can't do the RX trick. Here we do the lookup manually in conntrack (and this part is actually what brings in most of the dependencies). Any neat tricks up your sleeve for this case? :) -Toke