Re: Linux Route Cache performance tests

[Eric Dumazet <eric.dumazet@gmail.com>]

Le lundi 07 novembre 2011 à 13:42 +0000, Ben Hutchings a écrit :

> A routing cache this big is not going to fit in the processor caches,
> anyway; in fact even the hash table may not.  So a routing cache hit is
> likely to involve processor cache misses.  After David's work to make
> cacheless operation faster, I suspect that such a 'hit' can be a net
> loss.  But it *is* necessary to run a benchmark to answer this (and the
> answer will obviously vary between systems).
> 

I dont know why you think full hash table should fit processor cache.
If it does, thats perfect, but its not a requirement.

This is one cache miss, to get the pointer to the first element in
chain. Of course this might be a cache hit if several packets for a
given flow are processed in a short period of time.

Given a dst itself is 256 bytes (4 cache lines), one extra cache miss to
get the pointer to dst is not very expensive.

At least, in recent kernels we dont change dst->refcnt in forwarding
patch (usinf NOREF skb->dst)

One particular point is the atomic_inc(dst->refcnt) we have to perform
when queuing an UDP packet if socket asked PKTINFO stuff (for example a
typical DNS server has to setup this option)

I have one patch somewhere that stores the information in skb->cb[] and
avoid the atomic_{inc|dec}(dst->refcnt).