Stephen Hemminger a écrit :
On Thu, 07 Dec 2006 23:27:00 +0100
Eric Dumazet <[EMAIL PROTECTED]> wrote:
Stephen Hemminger a écrit :
On Thu, 07 Dec 2006 21:23:07 +0100
Eric Dumazet <[EMAIL PROTECTED]> wrote:
Stephen Hemminger a écrit :
The hard header cache is in the main output path, so using
seqlock instead of reader/writer lock should reduce overhead.
Nice work Stephen, I am very interested.
Did you benchmarked it ?
I ask because I think hh_refcnt frequent changes may defeat the gain you want
(ie avoiding cache line ping pongs between cpus). seqlock are definitly better
than rwlock, but if we really keep cache lines shared.
So I would suggest reordering fields of hh_cache and adding one
____cacheline_aligned_in_smp to keep hh_refcnt in another cache line.
(hh_len, hh_lock and hh_data should be placed on a 'mostly read' cache line)
Thank you
Eric
It doesn't make any visible performance difference for real networks;
copies and device issues are much larger.
Hum, so 'my' machines must be unreal :)
The hh_refcnt is used only when creating destroying neighbor entries,
so except under DoS attack it doesn't make a lot of difference.
The hh_lock is used on each packet sent.
Some machines create/delete 10.000 entries per second in rt_cache.
I believe they are real. DoS ? you tell it, some people wont agree.
That could be fixed by doing RCU, I did some of that previously, but it
seemed better to hit the worst case first. Even Robert doesn't see 10,000
rt cache entries per second.
What's the problem with my suggestion of keeping hh_refcnt on another cache
line ?
It is basically free (once your change from rwlock to seqlock put in), and no
change of algorithm.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
