|
Hello,
On Wed, 7 May 2003, Alexandre Cassen wrote:
> Yes, I spend long time in this code and the dependance with
> low level qos code introduce many complications... I have tried
> many things to optimize this but changing the current rt_cache
> structure will broke some routings dependances... even RCU
> spin_lock optimization don't increase perf.
May be it works for SMP ...
> > > rt_cache design is the kernel forwarding performance bottleneck :/
> >
> > It is true but the things are very complex.
>
> 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 ?
I assume you want the input routing lookup not to cache
results? It sounds good but lets see the facts:
- the cached result is attached to skb->dst, we have to attach
something there
- the cached results from input route lookups are not updated,
only the results from output route calls (metrics), so we will not
need to clone them on update
- even frag_needed events and dst->pmtu updates happen on
output route entries
- dst_cache users (TCP, UDP) update their cached dst (LVS does
not update them)
- one dst entry always points to its nexthop - good for incoming
traffic destined to small number of hosts, bad for traffic
sent from local hosts to many destinations
> do you think this will increase a little perf ?
We can not completely remove these entries but for
forwarding only situations (no output routes cached from TCP)
we can try to reduce their number in the cache. Consider this
example:
We are gateway for our LAN (firewall, etc). We have one uplink
router. The goal: can we use only one input route cache entry
per destination (local host)?
This entry will be attached to all incoming skbs even for
packets with different saddr. For this we need to use netmasks.
I'm not sure whether simple hash table will work for such
entries and also if there are no problems with that approach,
the new thing is that saddr is replaced with saddr/srcnetmask.
But if you want to avoid the caching then you will reach
low-level lookups, eg. neighbour resolutions (hashed tables with
MACs), routing tables (zoned hash tables), etc. Such lookups
per packet are bad.
IMO, the direction should be one input route cache entry
to match more skbs by introducing srcnetmask. May be we can
derive it from res->r but it is dangerous area considering
the fact other packets from this srcnet can match more specific
rules before the one used for caching. IMO, this is the main
problem in resolving this reduction of cache entries. When I
have more time I'll think on this issue more deeply.
Also, it is better rth->key.src == saddr to be checked
first, this can save some CPU cycles.
> Best regs,
> Alexandre
Regards
--
Julian Anastasov <ja@xxxxxx>
|
