Re: remarkably Increase iptables' speed on SMP system.

[Rennie deGraaf <rgndegra@ucalgary.ca>]

[-- Attachment #1: Type: text/plain, Size: 3039 bytes --]

Amin Azez wrote:
> * John Ye wrote, On 28/09/07 03:15:
> 
>> There is a kernel patch to let softirq network code(iptables included in) concurrently run on every CPUs on SMP system.
>> We wrote the kernel patch, a loadable module as well, to totally resolve iptables SMP issue.
>> Have discussed with kernel netdev experts. it should be working.
>>
>> The patch(module) will greatly increase the speed of iptalbes by making full use of every CPUs in SMP system.
>>
>> It can be viewed and downloaded from blog http://blog.chinaunix.net/u/12848/showart.php?id=389602
>> You are welcome to review and test without patching and re-compiling the kerenl.
> 
> 
> This looks interesting, and I hope worthwhile.
> 
> I wonder if it will likely re-order packets with the same flow?
> 
> i.e. packets which take more processing may leave the bridge/router
> after a packet of the same flow which arrived later.
> 
> Cases where this seems more likely are generally where not every packet
> of the same flow requires the same level of processing.
> 
> Obvious examples are:
> * udp snat, where only the first packet follows the nat table
> * layer7 when it stops matching, the very next packet may get through
> before the one that was the last to be matched.
> * packet count or rate based rules that only sometimes call secondary
> chains may be delayed more than the next packet if it doesn't match.
> 
> TCP (with SACK) may not be so bothered about this, but some GRE or UDP
> protocols may care (get degraded service), it may also foil upstream
> flow analysis which makes me realise that the layer7 match (and probably
> string match) are open to being deceived by deliberate out-of-order
> packets or intermediate fake packets with bad tcp sequence numbers. Hmm

Unless something is seriously wrong with netfilter or the patch, packets
should almost never be re-ordered unless their inter-arrival times are
less than a few milliseconds.  If the packets are that close together,
then existing network equipment will re-order them with non-trivial
probability, so any additional re-ordering introduced by this patch
shouldn't matter.  Applications need to be built to handle this, and if
anything in netfilter depends on packets arriving in the correct order
(other than stuff like TCP SYN segments that can't be delivered out of
order if both endpoints are following the protocol), it should be fixed.

There is a great paper by Bennet, Partridge and Shectman titled "Packet
Reordering is Not Pathological Network Behavior" published in IEEE/ACM
Transactions on Networking in December 1999 that examines this issue and
its effects on TCP, so the observation that parallelism in network
devices causes packet re-ordering is nothing new.  I did an experimental
analysis on the effects of inter-packet time on delivery order last
winter; my results are in Appendix A of my MSc thesis, which is
available at
http://pages.cpsc.ucalgary.ca/~degraaf/papers/thesis-degraaf.pdf

Rennie deGraaf


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]