From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [PATCH] fix iptables on systems with discontiguous processor ids Date: Tue, 11 Oct 2005 16:13:03 +0200 Message-ID: <434BC86F.3090506@cosmosbay.com> References: <20051010164141.GG5627@rama> <20051010.141518.60492651.davem@davemloft.net> <20051010214619.GJ5627@rama> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Harald Welte , netfilter-devel@lists.netfilter.org, "David S. Miller" Return-path: To: Henrik Nordstrom In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-devel-bounces@lists.netfilter.org Errors-To: netfilter-devel-bounces@lists.netfilter.org List-Id: netfilter-devel.vger.kernel.org Henrik Nordstrom a =E9crit : > On Mon, 10 Oct 2005, Harald Welte wrote: >=20 >> I don't know why they are incomplete ;) My guess is that they're most= ly >> targeted to per_cpu users. Basically to solve the 'iptables' problem, >> there are two ways: >=20 >=20 > Or three. >=20 > 3) Keep an NUM_CPUS array of pointers to the per-cpu tables, allocate= d=20 > separately per CPU instead of allocating a single large blob for all=20 > CPUs. These pointers are updated using RCU, and indexed using the=20 > physical CPU id. >=20 Yes, this is what I suggested some weeks ago with a patch. As vmalloc_node() is not yet part of kernel, I even coded a substitute fo= r it. (per_cpu/kmalloc are not an option since the allocations done in iptables= can=20 be very large) http://marc.theaimsgroup.com/?l=3Dlinux-netdev&m=3D112733887410796&w=3D2 > Cost: One (most likely cached) indirect memory access on each packet,=20 > and slightly more complex update procedure (num_possible_cpus=20 > allocations and pointers to update instead of just one). >=20 > Regards > Henrik >=20 >=20