IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and there
is no need to do that again from its callers. Drop it.
Acked-by: Neil Horman
Signed-off-by: Viresh Kumar
---
net/openvswitch/datapath.c | 2 +-
net/sctp/socket.c | 2 +-
net/socket.c | 6
IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and there
is no need to do that again from its callers. Drop it.
Signed-off-by: Viresh Kumar
---
net/openvswitch/datapath.c | 2 +-
net/sctp/socket.c | 2 +-
net/socket.c | 6 +++---
3 files
IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and there
is no need to do that again from its callers. Drop it.
Signed-off-by: Viresh Kumar
---
net/openvswitch/datapath.c | 2 +-
net/sctp/socket.c | 2 +-
net/socket.c | 6 +++---
3 files
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 16 September 2013 21:45, Ben Pfaff wrote:
> On Mon, Sep 16, 2013 at 07:01:43PM +0530, Viresh Kumar wrote:
>> Patches created using git aren't part of repository and shouldn't be counted
>> to
>> mark repo as dirty. Mark an entry into .gitignore for these.
&g
Patches created using git aren't part of repository and shouldn't be counted to
mark repo as dirty. Mark an entry into .gitignore for these.
Signed-off-by: Viresh Kumar
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index 60ed30d..bfe1993 10
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 12 September 2013 21:38, Pravin Shelar wrote:
> On Thu, Sep 12, 2013 at 3:11 AM, Viresh Kumar wrote:
>> On latest RT kernels we are getting following errors while compiling OVS:
>>
>> In file included from
>> openvswitch/datapath/linux/compat/
because RT kernel has used raw keyword inside skbuff.h, which was
used to identify some older kernels stuff in OVS.
Lets make the search pattern a bit stronger by searching "*raw;" instead of
"raw".
Signed-off-by: Viresh Kumar
---
V1->V2:
- Instead of removing OVS_GREP_IFE
On 3 September 2013 22:53, Jesse Gross wrote:
> Thanks, that's what I was looking for. Would you mind submitting the
> patch formally then? (I don't think you need to escape the semicolon
> though.)
Sorry was away on vacations..
Yeah, I will resubmit it then.. I kept semicolon as well to make it
On 31 August 2013 05:45, Jesse Gross wrote:
> Out of curiosity, what is the actual symbol that we're finding in the RT
> kernel?
Its not about RT kernel really..
Following patch did this:
b0e380b [SK_BUFF]: unions of just one member don't get anything done, kill them
diff --git a/include/linu
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
On 28 August 2013 05:37, Jesse Gross wrote:
> On Tue, Aug 27, 2013 at 3:51 AM, Viresh Kumar wrote:
>> On 26 August 2013 21:59, Jesse Gross wrote:
>>
>>> This is compatibility code for older kernels so by definition it
>>> doesn't exist in current kerne
On 26 August 2013 21:59, Jesse Gross wrote:
> This is compatibility code for older kernels so by definition it
> doesn't exist in current kernels. You can't just remove it.
My mistake :(
Will something like this makes sense? This was changed in 2.6.22 by
following patch:
b0e380b [SK_BUFF]: unio
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
instead of mac_header,
network_header, transport_header. And so the hack to rename them in OVS code.
But that's not the case now. RT kernel have mac_header, network_header and
transport_header as parameter and so we don't need this macro at all.
Lets get rid of it.
Signed-off-by: Vi
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
20 matches
Mail list logo
