On Tue, Mar 11, 2014 at 06:11:27PM -0700, Alex Wang wrote: > > > Signed-off-by: Alex Wang <al...@nicira.com> > > > > > > --- > > > V2 -> V3: > > > - rebase. > > > > > > PATCH -> V2: > > > - explain the drop of upcall queueing priority in dpif-netdev. > > > - use mhash to calculate the 5-tuple hash. > > > > Why does dpif_netdev_recv_set() ignore its 'enable' argument? > > I saw in current dpif-netdev.c, the dpif_netdev_recv_set() does nothing. > > I didn't ask for the reason. But now seems to be the good time, do you know > why it is not implemented? > > If there is the need, I'd like follow the dpif-provider definition and > implement it.
I don't know why it does nothing. I see that it has been that way for years, so obviously it is not particularly harmful. But I would prefer to follow the definition, if it does not require too much work to do so. > > As written, flow_hash_5tuple() will incorporate ICMP type and code > > into the hash (because those are stored into tp_src and tp_dst). Is > > that desirable? > > > > > I'm okay with that. I think counting ICMP type and code in hash will not > cause > particular handler receiving unfairly more ICMP related upcalls. (Is this > what you > concerned?) I am not concerned about fairness in this case. I am wondering whether one should ensure ordered delivery of ICMP with different type and code. My guess is that it does not matter, so let's leave this as-is unless anyone speaks up. > Also, want to ask that if there is any issue with the first patch? I don't recall what I thought about it, I'll look at it again now. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
