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. - 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
