|
Hello Roberto,
> RCU won't buy you a lot without SMP. Stupid question: did you
> readprofile/oprofile it once? I'd be interested to get some numbers.
When blaste the routers I constat this, then I try with SMP and this is the
same problem... I generated 12M random traffic through router on a Xeon hard
and CPU is 100% !... with a poor 60Kpps forwarding handling...
> > as you said :), what about not adding new entries per packets in the
> > rt_cache ? that way hash key will miss and submit routing lookup and
> > gc_.. will have a simple low job not the current big linearization aging
> task.
> > I was thinking of the _intern_hash func to not append new entries ?
>
> Again stupid question: Is it really the lookup that consumes the precious
> time?
The current rt_cache hash design is bad IMHO, since truly random traffic
generate lot of hash collision which end on a slow lookup. DaveM provided
a "nethashfix" last day using jenkins hash func which are using secret to try
limit collisions but this doesn't solve the problem since we can generate big
traffic between two hash secret update. I tried with this patch and problem
still the same... this is why PATRICIA and the like exist to speed up rt_cache
lookup... Since QoS is closed to routings porting current rt_cache design to
better design is big work...
Best regards,
Alexandre
|
