[ovs-discuss] OVS Support for RT Kernel

[Jesse Gross]

On Tue, Aug 27, 2013 at 1:37 AM, Viresh Kumar <viresh.kumar at linaro.org> wrote:
> Hi Jesse,
>
> Thanks for your quick reply :)
>
> On 26 August 2013 22:16, Jesse Gross <jesse at nicira.com> wrote:
>
>> Please look at the implementation of the loop counter.
>
> Sorry but I couldn't find anything interesting/tricky in implementation
> of loop counter.. :(
>
> struct loop_counter {
>     u8 count; /* Count. */
>     bool looping; /* Loop detected? */
> };
>
> It used to be tricky the last time you tried to add RT support (there
> were two separate counters for process/interrupt context), but its
> pretty much straight forward now..

The implementation is actually pretty much exactly the same as before.
The only reason why there are no longer separate process/interrupt
counters is because we started disabling bottom halves when processing
packets for userspace. However, with your change that is longer the
case and it's possible to be interrupted/rescheduled while using a
per-CPU counter. This will produce non-deterministic results since the
processing for multiple packets are sharing the same loop counter.

>> The current
>> method will yield non-deterministic results in the presence of
>> preemption.
>
> I see one problem: We may access these per-cpu variables
> concurrently from process context and bh.. And so we need
> something to guarantee the serialization here.. And then probably
> we don't need to do: get_cpu_var() for non-RT case..
>
> Do we have some existing lock that can be reused here? Otherwise
> I will create a new one.. spinlock would be better then a mutex as we
> would be accessing this code from BH too..

There's something similar in dev.c so you could check to see if they
did anything to that in the RT patchset.

>> Have you also audited the other use of per-CPU variables?
>
> Yes, I did. But couldn't find anything that would be broken with RT..
> Per-cpu doesn't have a problem with RT, only the access to those
> can be a issue.. And if things are serialized enough, then there
> shouldn't be any issue, I hope.

Can't you be interrupted/preempted while modifying the counters?