[PATCH] fix iptables on systems with discontiguous processor ids

[Harald Welte]

On Mon, Oct 10, 2005 at 02:15:18PM -0700, David S. Miller wrote:
> From: Harald Welte <laforge at netfilter.org>
> Date: Mon, 10 Oct 2005 18:41:41 +0200
> 
> > This is my proposed patch for the problem you've described.  Please test
> > and submit.  If it works, I'll also prepare a patch for {arp,ip6}_tables.
> 
> Ebtables needs it too.  "git grep num_possible_cpus" shows all
> of the users in the whole tree, %80 of which are the netfilter
> cases we're fixing here :-)
> 
> Why don't any of the existing interfaces on cpumasks and numbers
> provide what you need here?  

I don't know why they are incomplete ;)  My guess is that they're mostly
targeted to per_cpu users.  Basically to solve the 'iptables' problem,
there are two ways:

1) allocate one copy of the ruleset per cpu that actually exists,
   independent of their smp_processor_id().  This means that for every
   packet traversing the ruleset, we need to resolve the logical "cpu
   number" from the physical smp_processor_id().  Since there is no
   apparent mapping between them, we'd need to iterate over the 
   cpu_possible bitmask and find "how many bits are set between 0 and
   smp_processor_id()".  I'm not sure how expensive such calculations
   are, but I'd rather not additional code to the per-packet path.
   Advantage of this solution is that there is only one copy of the
   ruleset per physical cpu.

2) allocate one copy of the ruleset for every "possible
   smp_processor_id()", which is what the patch that I sent in my last
   email implements.

> Perhaps this routine you are adding (highest_processor_id()) belongs
> in linux/cpumask.h?  Perhaps named something like
> "highest_possible_processor_id()" to be consistent with the
> "num_possible_cpus()" naming?

I thought it was too specific for the generic code, but since we'll need
it from all the foobar_tables, it's probably best in cpumask.h

> Otherwise the patch looks fine, thanks for following up on this
> Harald.  I'll push the rest of the netfilter fixes once you cook
> up the final patch for this, thanks.

ok.
-- 
- Harald Welte <laforge at netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/netfilter-devel/attachments/20051010/2641e3b4/attachment.pgp