Exact Match Bulk support

[amarsri28]

This Patch enables Exact Match bulk support only.

[krsna1729]

Any reason to expose 32 here? Can we simplify it to be like below and move the detail all the way down to cuckooMap lookup_bulk_data API? Since at that level you can do sub-batch iteration using RTE_HASH_LOOKUP_BULK_MAX constraint

ValueTuple *res[bess::PacketBatch::kMaxBurst] = {0};
table_.Find(&keys, &res, cnt);

// Iterate results and set values and gate
for(int i = 0; i < cnt; i++)
{
    if(res[i]) {
        setValues(batch->pkts()[i], res[i]->action);
        EmitPacket(ctx, batch->pkts()[i], res[i]->gate);
    }
    else {
        EmitPacket(ctx, batch->pkts()[i], default_gate);
    }
}

[krsna1729]

a more general question NOT pertaining to this PR, The ValueTuple being pointed could be in the process of updating by the writer correct? How do we handle that scenario?

[amarsri28]

slow path forward separate event for update , it can be taken care.

[krsna1729]

I did not understand. We have a lock for the key but no lock while accessing the value.

[amarsri28]

yes there is no lock for accessing the value so its cleaner to handle 'update' separately .

[krsna1729]

The reason I removed the hitmask in my example was it would make an assumption without any assert that cnt is <=64

[krsna1729]

also when simplifying there must be some additional check in lookup_bulk_data of cuckoomap to lookup in chunks of 64 at the max in case cnt or n is more than 64

[amarsri28]

bess already check that in pipeline for cnt .

[amarsri28]

hit_mask seems a better logic for checking presence of data(standard way , used in ut also) as compare to checking pointer null condition.

[krsna1729]

Is there a need for hit_mask being exposed all the way up to exact_match.cc? cant we simply use pointer being null?

[amarsri28]

pointer would be easier to check...i gave it a thought, but we dnt want to waste cycles in initializing pointer array to zero everytime , also didnt got any dpdk reference which says that for 'not present' keys , pointer would be made null by dpdk(though it might be doing in this dpdk version) but dnt want to be dependent on internal dpdk logic for future dpdk revisions.
Unit test also uses same hit_msk logic for checking presence.

[krsna1729]

1. rebase
2. Run clang-format (contributing) manually or automatically as part of git hooks before committing and generating the BESS patch

[krsna1729]

can this be simplified

table_.Find(&keys[0],&res[0],cnt);

to

table_.Find(keys, res, cnt);