[ovs-discuss] Isn't there any way to use RSS hash instead of jhash in flow_hash()

[Heung Sik Choi]

Thank you for replying

Are you saying that you want to add RSS to the datapath to
move packets to different queues? Which queues? Or do you just want to
create a Toeplitz hashing algorithm function that will return a hash
value and it doesn't really have anything to do with RSS?

Sorry to confuse you. specifically, I think a design where skb structure
has 'rss hash value' and ovs' datapath use this value when it lookup flow
table. the rss hash value can get in NIC driver(ex. ixgbe), and can be
inserted in skb structure. Also If I replace the jhash2 in flow_hash()
with Toeplitz hash, the 'rss hash' can be used to hash in ovs. How do you
think about it? please let me know if you have any insights.

> I insert only one rule 'ovs-ofctl add-flow ovs-br1
> nw_dst=100.1.1.1,actions=mod_dl_dst:90:e2:ba:5b:88:2c,in_port'.
> Strangely, mac_src, mac_dst, ip_src, ip_dst, and port value in  struct
> sw_flow_key is changed after calling  ovs_flow_mask_key() in
> masked_flow_lookup(). I can not understand why mask processing turn on
> and why mask processing change almost all values in sw_flow_key.

I insert printk for log in masked_flow_lookup() function which is in
openvswitch-2.4.0/datapath/flow_table.c.  here is my code.

        // printk for log
        printk(KERN_ALERT "flow_table.c: masked_flow_lookup call : mac_src:
%d ip_src: %d\n", unmasked->eth.src, unmasked->ipv4.addr.src);


        ovs_flow_mask_key(&masked_key, unmasked, mask);

        // printk for log
        printk(KERN_ALERT "flow_table.c: masked_flow_lookup
call2(masked_key) : mac_src: %d ip_src: %d\n", masked_key.eth.src,
masked_key.ipv4.addr.src);


And then, result is here.

[  526.101151] flow_table.c: masked_flow_lookup call : mac_src: 1740651620
ip_src: 16843018
[  526.101158] flow_table.c: masked_flow_lookup call2(masked_key) :
mac_src: 1740650956 ip_src: 0

ovs is sent packet from dpdk-pktgen. I cannot understand why mask
processing change almost all values in sw_flow_key.

please let me know if you have any insights.

2017-05-24 1:50 GMT+09:00 Greg Rose <gvrose8192 at gmail.com>:

> On Tue, 2017-05-23 at 16:42 +0900, Heung Sik Choi wrote:
> > Hi,
> >
> >
> > In many articles about ovs, there are some mention that hashing
> > function cause quite significant overhead. Also, I did 'perf record'
> > performing OVS L3 forwarding, and found that.
> >
> >
> > So, an idea comes up, which is that implement RSS hash
> > algorithm(Toeplitz hash algorithm) in kernel datapath module.
>
> I'm somewhat confused by this comment.  RSS will use a Toeplitz hash
> algorithm to create a hash value that will then be used by the NIC to
> select one of multiple HW receive queues.  It's more than just a hash
> algorithm.  Are you saying that you want to add RSS to the datapath to
> move packets to different queues? Which queues? Or do you just want to
> create a Toeplitz hashing algorithm function that will return a hash
> value and it doesn't really have anything to do with RSS?
>
> > However, I stucked in processing mask the 'struct sw_flow_key'.
> >
> >
> > I insert only one rule 'ovs-ofctl add-flow ovs-br1
> > nw_dst=100.1.1.1,actions=mod_dl_dst:90:e2:ba:5b:88:2c,in_port'.
> > Strangely, mac_src, mac_dst, ip_src, ip_dst, and port value in  struct
> > sw_flow_key is changed after calling  ovs_flow_mask_key() in
> > masked_flow_lookup(). I can not understand why mask processing turn on
> > and why mask processing change almost all values in sw_flow_key.
>
> I have no idea about that.  I'll see if I can find time to repro on my
> own testing environment.
>
> - Greg
>
> >
> >
> >  Please let me know if you have any insights.
> > _______________________________________________
> > discuss mailing list
> > discuss at openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
>
>
> _______________________________________________
> discuss mailing list
> discuss at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20170524/1e4e852e/attachment-0001.html>