On 25 September 2013 05:51, Jesse Gross wrote:
> On Mon, Sep 23, 2013 at 11:20 PM, Viresh Kumar
> wrote:
>> static inline void rcu_read_lock_bh(void)
>> {
>> local_bh_disable();
>> #ifdef CONFIG_PREEMPT_RT_FULL
>> rcu_read_lock();
On 24 September 2013 02:00, Jesse Gross wrote:
> Search net/core/dev.c for RECURSION_LIMIT.
Ahh, thanks for the pointers..
This stuff was added in 2.6.37 And you said this earlier:
"This loop checker is just compatibility code since the exact same
logic exists in net/core/dev.c on newer kernels
On 21 September 2013 00:28, Jesse Gross wrote:
> On Mon, Sep 16, 2013 at 2:13 AM, Viresh Kumar wrote:
>> Is this piece of code reentrant? I don't think so, otherwise there would
>> have been races to update loop_counters..
> It certainly can be accessed simultan
On 31 August 2013 06:27, Jesse Gross wrote:
> On Wed, Aug 28, 2013 at 2:57 AM, Viresh Kumar wrote:
Sorry for delayed response.. Was on holidays for a week and then
was busy with CPUFreq bugs last week..
>> Which should have worked for both RT and non-RT kernels..
>
> I think tha
On 28 August 2013 05:48, Jesse Gross wrote:
> 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
Hi Jesse,
Thanks for your quick reply :)
On 26 August 2013 22:16, Jesse Gross 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
On 24 August 2013 06:30, Jesse Gross wrote:
> Putting a big lock around the majority of the packet processing
> doesn't seem like a particularly good idea for performance and you
> would need to make sure that you get all the entry points. You would
> probably be better off serializing the parts t
On 7 August 2013 22:48, Jesse Gross wrote:
> It's not a particularly good starting point because all it was make it
> compile on these kernels. It didn't actually make anything
> preemptable.
I am back after some study of RT Kernel.. :)
So, I had a look at OVS out-of-kernel module to get RT suppo
