[ovs-dev] [PATCH V3 2/5] dpif-netdev: Implement the API functions to allow multiple handler threads read upcall.

[Ben Pfaff]

On Tue, Mar 11, 2014 at 06:11:27PM -0700, Alex Wang wrote:
> > > Signed-off-by: Alex Wang <alexw at 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.