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

["Bly, Mike" <mbly@ciena.com>]

Venkat,

While that does “solve” the issue, I find the approach of tying the meta-data-key-offset to a specific table highly limiting. IMO, it would be far more interesting to provide the offset as part of the lookup call itself. For example, I might have an optimized code sequence that generates a series of “keys” in meta data, which then triggers a series of lookups, where one or more lookups are different keys, but in the same table(s). As it stands now, the proposed solution requires an iterative updating of the same key location in meta data between lookups. This also prevents multiple tables from sharing the same meta data “space” for overlapping key values, in that I am forced to iteratively change/reload said key data.

Another thing to consider would be the ability to provide offset/size per sub-field for a given key. The MAC table in question is a great example. I’ll add IP addresses here as well to make it a bit more interesting:

Meta-data = DA | (SA << 6*8) | (BRIDGE_ID << 12*8) | (DIP << 14*8) | (SIP << 20*8)

If we were allowed to use per field offset/size values, I could use the above meta-data for two MAC lookups and two FIB/RIB lookups and perhaps a combo L2/L3 ACL lookup. However, the current limitation requires me to modify the “meta-data” before each individual lookup, which means my frame parsing is iterative and NOT necessarily optimized.

-MikeB

From: Venkateswara Rao Thummala [mailto:venkat.thummala.1978@gmail.com]
Sent: Monday, August 17, 2015 11:06 AM
To: Yeddula, Avinash
Cc: Singh, Jasvinder; Richardson, Bruce; dev@dpdk.org; Bly, Mike
Subject: Re: [dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table.

Hi Avinash,
I think, you can use the same table by just updating the packet meta data based on the Look UP.
In the first lookup, you can populate the meta data [key offset] with the source MAC and in the second lookup, you can populate the same meta data with the destination lookup. I think this should work.
Thanks
Venkat
OneHop Networks

On 17 August 2015 at 22:05, Yeddula, Avinash <ayeddula@ciena.com<mailto:ayeddula@ciena.com>> wrote:
+ Mike ( My team mate)
Hi Jasvinder, It's not a bidirectional packet flow. The pipeline looks something like this.

Ingress port-----Table 1 ----Table-2 ----- Mac_Table ----- Table4 ---- Egress port.

Before the frame goes reaches table 4, we do 2 lookups at the mac table.
1. src lookup ( To learn the MAC on the bridge)
2. dst lookup ( Flooding if dst MAC look up fails else Unicast/forward if dst lookup success).

Here are the keys we are using.
Src lookup key  -  Src MAC (src MAC in the frame) + Bridge ID ( Bridge on which it arrived).
Dst lookup key  - Dst MAC (dst MAC in the frame) + Bridge ID ( Bridge on which it arrived)


Thanks
-Avinash

-----Original Message-----
From: Singh, Jasvinder [mailto:jasvinder.singh@intel.com<mailto:jasvinder.singh@intel.com>]
Sent: Monday, August 17, 2015 7:00 AM
To: Richardson, Bruce; Yeddula, Avinash
Cc: dev@dpdk.org<mailto:dev@dpdk.org>
Subject: RE: [dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table.



> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org<mailto:dev-bounces@dpdk.org>] On Behalf Of Bruce Richardson
> Sent: Friday, August 14, 2015 10:25 AM
> To: Yeddula, Avinash
> Cc: dev@dpdk.org<mailto:dev@dpdk.org>
> Subject: Re: [dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table.
>
> On Thu, Aug 13, 2015 at 05:37:21PM -0400, Yeddula, Avinash wrote:
> > Any comments on this question ?
> >
> > Thanks
> > -Avinash
> >
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org<mailto:dev-bounces@dpdk.org>] On Behalf Of Yeddula,
> > Avinash
> > Sent: Wednesday, August 12, 2015 3:04 PM
> > To: dev@dpdk.org<mailto: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. 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.
> > Use case: Src mac  lookup and dst mac lookup on the same mac table.
> >
> > Thanks
> > -Avinash
>
> Just to confirm: this is using the extensible bucket hash in the
> rte_table library of packet framework, rather than the standalone
> rte_hash library, right?
>
> /Bruce

Could you share detail on the two different keys used for lookups. In case if you are considering bidirectional packet flow between the source and destination, symmetric hash can be used-  http://www.ndsl.kaist.edu/~kyoungsoo/papers/TR-symRSS.pdf

Jasvinder