[ovs-dev] [PATCH 03/11] datapath: Fold key_len and hash into sw_flow_key.

Rajahalme, Jarno (NSN - FI/Espoo) jarno.rajahalme at nsn.com
Mon Feb 18 08:13:36 UTC 2013


On Feb 16, 2013, at 1:19 , ext Jesse Gross wrote:

> On Mon, Feb 11, 2013 at 6:46 AM, Jarno Rajahalme
> <jarno.rajahalme at nsn.com> wrote:
>> Store key_len and hash fields at the end of struct sw_flow_key, past the
>> area being hashed.
>> Rename functions operating on keys from "_flow_" to "_flow_key_".
>> Shift the responsibility for key hashing from lookup and insert to key
>> construction side, which helps avaiding unnecessary hash computations.
>> 
>> Signed-off-by: Jarno Rajahalme <jarno.rajahalme at nsn.com>
> 
> This seems like three independent changes, so it really should be
> broken up into different commits.  However, that being said, it also
> needs more justification since I don't really see the benefit at the
> moment.  In particular, how does moving the location of hash
> computation reduce unnecessary work?


I'd be happy to break it apart.

In datapath.c ovs_flow_cmd_build_info(), there is first a call to ovs_flow_tbl_lookup(), which currently computes the hash. In the case of a new flow this is followed by ovs_flow_tbl_insert(), which currently recomputes the same hash. This can be avoided if hash is made a part of the key itself.

In a later patch (which may be more controversial), I have proposed to expose the kernel computed key hash to the userspace (think "cookie"), which is given back to the kernel only when the key is passed back as-is. In this case additional key hash computations can be avoided in kernel flow set-up.

  Jarno


More information about the dev mailing list