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

[Alex Wang]

 > > > 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.
>
>

Cool, I'll add this.



>  > > 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.



This will require the datapath to distinguish such special packets and send
them to
the same PID.

Also, can you give me an example that we will have a userspace action to
send
packet like ICMP to userspace?  I can only think of sampling.  And I cannot
think
of other example where the reordering would happen.




> > 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20140312/cfb1b41f/attachment-0005.html>