Re: [PATCH] SMP SNMP

On Mon, 31 Jan 2011 23:00:34 +0200, Tsantilas Christos
<chtsanti_at_users.sourceforge.net> wrote:
> On 01/31/2011 10:18 PM, Amos Jeffries wrote:
>> On 01/02/11 04:17, Tsantilas Christos wrote:
>>> I am sending a new version of the patch.
>>> Please my comments bellow for the fixes and my comments.
>>>
>>> Also I am including a patch for Ranges. The original patch which
>>> included in squid-smp-snmp patch did not support 64bit range sizes
which
>>> required by the HttpRanges.
>>>
>>>
>>> On 01/29/2011 03:06 AM, Amos Jeffries wrote:
>>>> On 29/01/11 07:04, Tsantilas Christos wrote:
>>>>> I am attaching the new version.
>>>>>
>>>>>
>>>>> On 01/27/2011 05:10 PM, Amos Jeffries wrote:
>> <snip>
>>>>>
>>>>>>
>>>>>> * PERF_SYS_CURLRUEXP again is tricky to combine. best match would
be
>>>>>> a
>>>>>> min() for oldest timestamp.
>>>>>
>>>>> Currently it is just return "0".
>>>>>
>>>>
>>>> Oh I see.
>>>>
>>>> The meaning of LRU is "oldest timestamped object in cache, if LRU
>>>> algorithm is used". The fact that the workers are not presenting the
>>>> timestamp can be left for future fix. There is a bug open for that.
>>>>
>>>> What this SMP support needs to do is aggregate via a special filter
>>>> equivalent to min() to retain the semantic oldest-object meaning. A
>>>> special one is needed that works as unsigned and ignores '0' values.
>>>
>>> I just add your comment near the related source code.
>>>
>>>>
>>>> As I understand it, if there are no values available from any worker
we
>>>> should return the SNMP no-data message instead of '0'.
>>>
>>> I did not found an quick/easy way to return no-data message (or an
>>> example how to do it). I let it as is for now. Is it important?
>>>
>>
>> The default switch case should handle it nicely if the hard-coded block
>> is "#if 0"'d out of existence.
>
> Already tested, plus some other options and it does not worked. I do not

> remember the exact error, but it was something like "wrong value" on
> snmpget, and bad behaviour on snmpwalk.
>

Oh well. Thanks for trying. Thats a +1 on that patch as-is then.

Amos
Received on Mon Jan 31 2011 - 21:36:48 MST