[DTrace-devel] [PATCH 5/6 v3] Implement associative array support

[Eugene Loh]

On 3/22/22 2:41 AM, Kris Van Hees wrote:

> On Mon, Mar 21, 2022 at 08:08:31PM -0400, Eugene Loh via DTrace-devel wrote:
>> On 3/11/22 4:41 PM, Eugene Loh wrote:
>>> On 3/11/22 11:19 AM, Kris Van Hees via DTrace-devel wrote:
>>>> On Fri, Mar 11, 2022 at 01:26:30AM -0500, Kris Van Hees via
>>>> DTrace-devel wrote:
>>>>> diff --git a/bpf/get_dvar.c b/bpf/get_dvar.c
>>>>> @@ -11,8 +11,24 @@
>>>>>    #endif
>>>>>      extern struct bpf_map_def dvars;
>>>>> +extern struct bpf_map_def tuples;
>>>>>    extern uint64_t NCPUS;
>>>>>    +/*
>>>>> + * Dynamic variables are identified using a unique 64-bit key.
>>>>> Three diferent
>>>>> + * categories of dynamic variables are supported in DTrace:
>>>>> + *
>>>>> + * 1. Thread-local storage (TLS) variables:
>>>>> + *    dvar key = TLS key (highest bit = 0)
>>>>> + * 2. Global associative array elements:
>>>>> + *    dvar key = &tuples[var id, tuple, (uint64_t)0] (highest bit = 1)
>>>>> + * 2. TLS associative array elements:
>>>>> + *    dvar key = &tuples[var id, tuple, TLS key] (highest bit = 1)
>>>>> + *
>>>>> + * Given that the TLS key can never be 0, uniqueness of the
>>>>> dvar key is
>>>>> + * guaranteed in this scheme.
>>>>> + */
>>>>> +
>>>>>    noinline uint64_t dt_tlskey(uint32_t id)
>>>>>    {
>>>>>        uint64_t    key;
>>>>> @@ -25,7 +41,7 @@ noinline uint64_t dt_tlskey(uint32_t id)
>>>>>            key += (uint32_t)(uint64_t)&NCPUS;
>>>>>          key++;
>>>>> -    key = (key << 32) | id;
>>>>> +    key = ((key & 0x7fffffff) << 32) | id;
>>> I do not understand the & 0x7fffffff.  Are you throwing a bit away?  Or
>>> is this operation unnecessary?  Or is it simply there for the BPF
>>> verifier?
> I am forcing the highest order bit to be 0.  Of course, it will typically be
> 0 anyway, but this makes it abundantly clear that we have an orthogonal key
> value space for plain TLS variables vs associative arrays.
Thanks, but it would seem that either:
*)  We already know the top bit will be 0, in which case the masking is 
unnecessary.
*)  The top bit could be 0 (and masking introduces the risk of duplicate 
TLS keys???).

Maybe what I'm asking is to whom we are trying to be abundantly clear.  
If to human readers, then a comment would be sufficient and the extra 
BPF is unneeded.