Re: [PATCH] convert hh_lock to seqlock

[Eric Dumazet <dada1@cosmosbay.com>]

Stephen Hemminger a écrit :
> On Thu, 07 Dec 2006 23:27:00 +0100
> Eric Dumazet <dada1@cosmosbay.com> wrote:
> 
>> Stephen Hemminger a écrit :
>>> On Thu, 07 Dec 2006 21:23:07 +0100
>>> Eric Dumazet <dada1@cosmosbay.com> 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.