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

Pravin Shelar pshelar at nicira.com
Fri Feb 7 21:00:37 UTC 2014


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.



More information about the dev mailing list