Re: hidden interface (ARP) 2.4.20 / network performance

[Roberto Nibali]

>>Could you please be more specific on what exactly you're trying to 
>>achieve? Do you want to load balance an application whose average 
>>package size is 80 bytes? How many sustained connections per seconds do 
>>you have?
>  
> Well, what I am trying to say is this: my experience is that under load with
> small sized packets even standard routing/packet forwarding becomes lossy. If I

That's a known fact, however I experienced Linux to perform the best in 
such worst case situations among several other Unices I tested, and NAPI 
certainly has brought some improvements in this area.

> put NAT and other nice netfilter features on top of such a situation things get
> a lot worse (obviously) - no comparison to building the "application" (e.g.
> cluster) with routing and hidden-patch (mainly because of its pure simplicity I
> guess).

I'm afraid but I don't understand what you mean with the second part of 
your statement.

> Don't get me wrong: I am pretty content with the hidden-patch and my setup
> without NAT. But I wanted to point to the direction of possible further routing
> performance improvement in 2.4.X tree. Is it correct that I can expect higher

Huh? Routing performance improvements? Routing is almost possible at 
wire speed. Some 60us delay per packet maybe (in case of load balancing 
decisions) but what do you want to improve?

I agree with you that netfilter NAT performance should and possibly can 
be impoved. And people are working on proof-of-concept improvements of 
NAPT in the Linux kernel including the netfilter team. But again, for me 
the hidden patch (http://www.ssi.bg/~ja/hidden-2.4.20pre10-1.diff) as it 
can be found does nothing to improve your situation.

> data-rates (concerning small packets) if using higher HZ ?

I doubt this would help much but I haven't tested it and I do not see 
all consequences on the routing, the routing cache and the FIB policy of 
modifying HZ. I couldn't comment on that.

> Someone selling E3 cards told me he cannot manage loads like these (small
> packet stuff) with a stock kernel, and that you _at least_ have to increase HZ
> to get acceptable throughput results.

Now that certainly is interesting, does he have any nice numbers to back 
this up? I'd be very interested. Also I've cc'd Jamal (I hope he will 
forgive me for that) who's working in this field since a couple of years 
now. Maybe he can comment on the HZ changes.

Best regards,
Roberto Nibali, ratz
-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc