Re: [dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table.

["Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Yeddula, Avinash
> Sent: Thursday, August 13, 2015 10:37 PM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table.
> 
> Any comments on this question ?
> 
> Thanks
> -Avinash
> 

Sorry for my delay, Avinash, I was out of office for a few days.

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Yeddula, Avinash
> Sent: Wednesday, August 12, 2015 3:04 PM
> To: dev@dpdk.org
> Subject: [dpdk-dev] Lookup mechanim in DPDK HASH table.
> 
> Hello All,
> 
> I'm using DPDK extendable hash tables. This question is with respect to the
> lookup aspect of the hash table.
> I see that there is just one "t->key_offset" that is pre-defined for the hash
> table.

Just to avoid any confusion here implied by "pre-defined" statement, the key offset is definitely not hardcoded at build time; the key offset is configurable per each hash table instance when the hash table instance is initialized. Once set up for a particular hash table instance, it cannot be changed for that instance. Different hash table instances can have different values for this parameter.

> I also understand that the frame needs to carry the "lookup_key / keys" in the meta data.
> 
> Here is my question:  How to support more than one lookup with different
> keys on the same frame on the same table.

I agree with Venkat that one way of doing this is to do additional work of extracting the lookup key from the packet (which can have different format, depending on the point in the processing pipeline) and placing it at a fixed offset within the packet meta-data. This work can be done by: 
- the action handler defined for the input ports of the same pipeline that current table is part of
- the action handler of a table in the same pipeline (located before the current table)
- an action handler (of input port/output port/table) from a different pipeline instance (located before the current pipeline in the processing chain)

I also agree with Mike Bly this is not the best way of doing things, and I don't think you actually need it, based on your use-case. Please see below for my suggestion.

> Use case: Src mac  lookup and dst mac lookup on the same mac table.

Your use-case looks like classical L2 bridging. My understanding is: 
- you need to lookup the MAC destination in the MAC forwarding table: on lookup hit, unicast forward the frame on the port read from the hit table entry; on lookup hit, broadcast/flood the frame on all ports. 
- you also need to learn the MAC source, i.e. make sure you add the MAC source to the same MAC forwarding table to make the association of MAC address and the port where it is located for future lookups. As Jasvinder is pointing out, you do not really need to do a lookup of the MAC source in the table, what you need is to add the MAC source to the table.

So one suggestion is to:
- have a single lookup operation in the MAC forwarding table (based on MAC destination)
- have the table action handler (or the input port action handler, or the output port action handler) to perform the add operation to the MAC forwarding table (add the MAC source as a new key to the table); the add operation is really an add/update, meaning that when the key is already present in the table, only the data associated with the key (i.e. the port where to forward the frame) is modified, which can be handy to pick up automatically the corner case of one station being moved from port A to port B (so one MAC address that previously showed up as being sourced on port A is not sourced by port B)

You can also optimize things a bit to reduce the rate of add operations to the table, so you don't need to perform an add operation per frame:
-have single lookup operation to table 1( MAC forwarding table), using the MAC destination as the lookup key
-have single lookup operation to table 2 (MAC learning cache table, which can be a small LRU-based table used to record the most frequently MAC addresses encountered lately), using the MAC source as the lookup key: only add the current MAC source to table 1 (MAC forwarding table) on lookup miss in table 2

I am sure that other people have even better ideas for optimizations.

> 
> Thanks
> -Avinash