Re: [PATCH] x_tables, take 5 (Final Review)

[Eric Dumazet <dada1@cosmosbay.com>]

Harald Welte a écrit :
> Hi!
> 
> It's been some time since I last released a version of the x_tables
> patch.  This is mainly due to the reason that 2.6.15 has only been
> released recently, and x_tables was clearly 2.6.16 work.
> 
> I've modified nfsim and the nfsim-testsuite to work with an x_tables
> kernel, and all tests now pass without any problem (using an old
> iptables binary that was compiled against a non-xtables kernel). This,
> in addition to my manual tests, give me enough confidence that I didn't
> break something significant.
> 
> I'm planning to submit x_tables eatly next week, so this is assumed to
> be the final review phase.
> 
> So if you have any issues, please comment now before it's too late :)
> 
Hi Harald

Is there any chance we can get rid of the rwlock_t lock in 'struct xt_table' ?
(Replacing it by an array of spinlocks)

     /* Lock for the curtain */
-   rwlock_t lock;
+   spinlock_t *lockp;



Pros :

   1) No more cache line ping pongs between cpus. A read_lock_bh(&table->lock) 
is still expensive because of that.

   2) spinlocks are less expensive (spin_unlock is not an atomic op like 
read_unlock_bh()

On a dual processor machine, its quite common that all incoming frames are 
handled by CPU 0, while CPU 1 is doing the User level stuff and sends network 
trafic...

Thank you

( I had a patch sent in September which was doing quite the same thing on 
ipt_tables, but keeping the rwlock_t : Correct me but I think we can just use 
spinlocks)

Eric