[ovs-dev] [PATCH] ofproto-dpif-upcall: Remove the dispatcher thread.

Alex Wang alexw at nicira.com
Sat Feb 8 00:46:45 UTC 2014


Based on the discussion offline, we agree on that the kernel side
implementation should be
kept simple.  So, the current design will still be used.

Also, change the key name from OVS_VPORT_ATTR_UPCALL_PIDS to
OVS_VPORT_ATTR_UPCALL_PID.

I'll send V2 patch soon.


On Fri, Feb 7, 2014 at 1:00 PM, Pravin Shelar <pshelar at nicira.com> wrote:

> On Fri, Feb 7, 2014 at 11:55 AM, Alex Wang <alexw at nicira.com> wrote:
> > Thanks Pravin,
> >
> >
> >> >
> >> > This patch also significantly simplifies the flow miss handling
> >> > code and brings slight improvement to flow setup rate.
> >> >
> >> Hi Alex,
> >>
> >> I have couple of high level comments:
> >>
> >> 1. Are we trying to solve fairness here? If yes then how does it work
> >> for tunnel ports? If not then this is about only removing dispatcher.
> >> Therefore can we have a per datapath pool of pids rather than per
> >> vport?
> >
> >
> >
> > This is only about removing dispatcher.  But we want to try addressing
> the
> > fairness issue in userspace based on this implementation.  The pids per
> > vport implementation provides per port fairness.  If we use a pids pool,
> > the starvation may happen in the kernel (since the upcall from different
> > vport
> > may go to the same pid).  And we need some fair queueing scheme in the
> > kernel.  I think we want to avoid such complexity in kernel.
> >
> Right, this works for physical ports. What about tunnel port? In
> kernel there is one vport for a tunnel type. So with this patch there
> is one pool of pids for all tunnel-vports for give tunnel type (for
> example gre). That can cause starvation among different tunnels.
>
> >
> >> 2. In any case we need to handle OVS_VPORT_ATTR_UPCALL_PID attribute
> >> in kernel. Since it is kernel interface.
> >>
> >
> > I didn't follow.  Do you mean we need this to pass in the nl_sock pid?
> >
> I mean vport attribute OVS_VPORT_ATTR_UPCALL_PID can not be removed.
> We need to handle it in kernel datapath along with new attribute
> related to pid pool.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20140207/f0f64ffb/attachment-0003.html>


More information about the dev mailing list