Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Wmem has reached feature-parity with emem

From: Evan Huus <eapache@xxxxxxxxx>
Date: Wed, 19 Jun 2013 11:52:34 -0700
On Wed, Jun 19, 2013 at 8:30 AM, Michal Labedzki
<michal.labedzki@xxxxxxxxx> wrote:
> Hi,
> One more thing. What do you think about new API... In Bluetooth dissectors
> there is a lot of code like this (little simplified):
>
>         k_interface_id = interface_id;
>         k_adapter_id   = adapter_id;
>         k_chandle      = chandle;
>         k_cid          = cid;
>         k_frame_number = pinfo->fd->num;
>
>         key[0].length = 1;
>         key[0].key    = &k_interface_id;
>         key[1].length = 1;
>         key[1].key    = &k_adapter_id;
>         key[2].length = 1;
>         key[2].key    = &k_chandle;
>         key[3].length = 1;
>         key[3].key    = &k_cid;
>         key[4].length = 1;
>         key[4].key    = &k_frame_number;
>         key[5].length = 0;
>         key[5].key    = NULL;
>
>         psm_data = (psm_data_t *)
> wmem_tree_lookup32_array_le(cid_to_psm_table, key);
>         if (!(psm_data && psm_data->interface_id == interface_id &&
>                 psm_data->adapter_id == adapter_id &&
>                 psm_data->chandle == chandle &&
>                 psm_data->scid == (scid | ((pinfo->p2p_dir == P2P_DIR_RECV)
> ? 0x00000000 : 0x80000000))))
>             psm_data = NULL;
>
> So I expected for every key expect last are equal, but last equal or less.
> Currently I need to check all nodes. Maybe we can create for example:
> wmem_tree_lookup32_array_cond() where we can control all the keys
> conditions, for example:
>
>
>         key[0].length = 1;
>         key[0].key    = &k_interface_id;
>         key[0].cond = COND_EQ;
>         key[1].length = 1;
>         key[1].key    = &k_adapter_id;
>         key[1].cond = COND_EQ;
>         key[2].length = 1;
>         key[2].key    = &k_chandle;
>         key[2].cond = COND_EQ;
>         key[3].length = 1;
>         key[3].key    = &k_cid;
>         key[3].cond = COND_EQ; /* or COND_L, COND_G (possible?), COND_GE,
> COND_NE (not equal)  */
>         key[4].length = 1;
>         key[4].key    = &k_frame_number;
>         key[4].cond = COND_LE;
>         key[5].length = 0;
>         key[5].key    = NULL;
>
> Or maybe other idea? (pack all session identifiers to one long length
> identifier?)

lookup32_array_le and lookup32_le return the node with the given key
if it exists, or the next smallest node if it exists (regardless of
how much smaller), or NULL. I don't think mixing and matching
conditions is the correct way to do this.

What I think you can do (this code is not tested and I've never tried
anything like this, but I *think* it will work) is to make the key
with the first 4 entries (and not the k_frame_number value) and use it
in a lookup32_array. If the result of that isn't null, you can cast it
to a wmem_tree_t* and do a lookup32_le with just the frame number on
that subtree (so no need to build a key, just pass k_frame_number
directly to wmem_tree_lookup32_le).

Something like this:

        k_interface_id = interface_id;
        k_adapter_id   = adapter_id;
        k_chandle      = chandle;
        k_cid          = cid;

        key[0].length = 1;
        key[0].key    = &k_interface_id;
        key[1].length = 1;
        key[1].key    = &k_adapter_id;
        key[2].length = 1;
        key[2].key    = &k_chandle;
        key[3].length = 1;
        key[3].key    = &k_cid;
        key[4].length = 0;
        key[4].key    = NULL;

        wmem_tree_t *sub_tree = (wmem_tree_t *)
wmem_tree_lookup32_array(cid_to_psm_table, key);
        if (sub_tree) {
                psm_data = (psm_data_t *)
wmem_tree_lookup32_le(sub_tree, pinfo->fd->num);
        }

> By the way.. key can be a string?

Yes, see wmem_tree_insert_string and wmem_tree_lookup_string. They
simply do the work of converting the string into an array and calling
wmem_tree_*32_array() for you.

>
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe