Ingo Molnar wrote:
* Hiroshi Shimamoto [EMAIL PROTECTED] wrote:
Hi Ingo,
I think local_irq_enable() is missing in default_idle() on x86_64.
It's for recent x86 tree.
From: Hiroshi Shimamoto [EMAIL PROTECTED]
Subject: [PATCH] x86_64: enable irq in default_idle
local_irq_enable
Hello,
tick_nohz_stop_sched_tick() and tick_nohz_restart_sched_tick()
pair in cpu_idle() is different from 32-bit version.
From: Hiroshi Shimamoto [EMAIL PROTECTED]
Subject: [PATCH] x86_64: move out tick_nohz_stop_sched_tick() call from the loop
Move out tick_nohz_stop_sched_tick() call from
From: Hiroshi Shimamoto [EMAIL PROTECTED]
smp_num_siblings hasn't been updated at this point yet, so it's always 1.
This polling and HT warning message is never shown.
Signed-off-by: Hiroshi Shimamoto [EMAIL PROTECTED]
---
arch/x86/kernel/process_32.c |4
1 files changed, 0 insertions
to set the suitable scheduler class.
Signed-off-by: Hiroshi Shimamoto [EMAIL PROTECTED]
---
diff --git a/kernel/sched.c b/kernel/sched.c
index deeb1f8..b0c582b 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -1682,6 +1682,11 @@ void fastcall wake_up_new_task(struct task_struct *p,
unsigned long
.
I've tested it and it looks working fine in my test case.
I attached the test case.
Will you write a patch to replace mine?
Thanks,
Hiroshi Shimamoto
inline: mutexprio.c
similar.
Signed-off-by: Hiroshi Shimamoto [EMAIL PROTECTED]
---
arch/x86/kernel/nmi_32.c | 18 +
arch/x86/kernel/nmi_64.c | 92 +++---
2 files changed, 56 insertions(+), 54 deletions(-)
diff --git a/arch/x86/kernel/nmi_32.c b/arch/x86/kernel/nmi_32
White space and coding style clean up.
Make process_32/64.c similar.
Signed-off-by: Hiroshi Shimamoto [EMAIL PROTECTED]
---
arch/x86/kernel/process_32.c | 20 ++--
arch/x86/kernel/process_64.c | 307 +-
2 files changed, 163 insertions(+), 164 deletions
White space and coding style clean up.
Make apic_32/64.c similar.
Signed-off-by: Hiroshi Shimamoto [EMAIL PROTECTED]
---
arch/x86/kernel/apic_32.c |5 ++---
arch/x86/kernel/apic_64.c | 23 +--
2 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/arch/x86
Ingo Molnar wrote:
* Hiroshi Shimamoto [EMAIL PROTECTED] wrote:
White space and coding style clean up. Make apic_32/64.c similar.
thanks, applied. FYI, there's still a bit left in apic_32.c:
total: 5 errors, 1 warnings, 1566 lines checked
we might as well go for all of them
Hiroshi Shimamoto wrote:
Vivek Goyal wrote:
On Fri, Oct 19, 2007 at 06:18:27PM -0700, Hiroshi Shimamoto wrote:
Hi,
I made patches to unify crash_32/64.c.
There are three patches;
1. add lapic_shutdown for x86_64
2. add safe_smp_processor_id for x86_64
3. unify crash_32/64.c
I'm not sure
tested the latest kernel(2.6.24-rc1-gec3b67c1).
Boot parameter nohpet resolves this issue and kdump
works well on 32bit.
So I guess HPET affects this.
But I don't know why 64bit kernel with HPET is OK.
Thanks
Hiroshi Shimamoto
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
Thomas Gleixner wrote:
On Fri, 26 Oct 2007, Hiroshi Shimamoto wrote:
Added Venki to CC
I'm now testing crash on 32bit, but there is an issue before
applying the patches. My machine stopped at checking 'hlt'
after kexec, showing below message.
CPU: Intel(R) Xeon(TM) CPU 3.80GHz stepping
Hiroshi Shimamoto wrote:
Thomas Gleixner wrote:
On Fri, 26 Oct 2007, Hiroshi Shimamoto wrote:
Added Venki to CC
I'm now testing crash on 32bit, but there is an issue before
applying the patches. My machine stopped at checking 'hlt'
after kexec, showing below message.
CPU: Intel(R) Xeon
lapic_shutdown is useless on x86_64.
Signed-off-by: Hiroshi Shimamoto [EMAIL PROTECTED]
---
arch/x86/kernel/apic_64.c | 14 --
arch/x86/kernel/crash.c |5 +
include/asm-x86/apic_64.h |1 -
3 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/arch/x86/kernel
Eric W. Biederman wrote:
Hiroshi Shimamoto [EMAIL PROTECTED] writes:
Do we really have to introduce this function for 64bit? I remember some
issues were faced on i386 w.r.t kernel enabling the LAPIC against the
wishes of BIOS hence kernel was disabling it while shutting down
Arjan van de Ven wrote:
On Mon, 29 Oct 2007 15:39:46 -0700
Hiroshi Shimamoto [EMAIL PROTECTED] wrote:
lapic_shutdown is useless on x86_64.
but since the goal is to get apic_32.c and apic_64.c to be more
converging (to the point of becoming the same file)... isn't your patch
going
Merge init_task_32/64.c.
Move 64bit per cpu data orig_ist to setup64.c.
Signed-off-by: Hiroshi Shimamoto [EMAIL PROTECTED]
---
arch/i386/Makefile |2 +-
arch/x86/kernel/Makefile_32|2 +-
arch/x86/kernel/Makefile_64|2 +-
arch/x86/kernel/init_task.c| 49
.
Is it possible? And how about moving rdtscll before mach_prepare_counter()?
rdtscll(start);
Thanks
Hiroshi Shimamoto
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
From: Hiroshi Shimamoto [EMAIL PROTECTED]
Signed-off-by: Hiroshi Shimamoto [EMAIL PROTECTED]
---
arch/x86/kernel/apic_64.c | 14 ++
include/asm-x86/apic_64.h |1 +
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/apic_64.c b/arch/x86/kernel
From: Hiroshi Shimamoto [EMAIL PROTECTED]
Most of contents in crash are same.
Signed-off-by: Hiroshi Shimamoto [EMAIL PROTECTED]
---
arch/x86/kernel/Makefile_32 |2 +-
arch/x86/kernel/Makefile_64 |2 +-
arch/x86/kernel/crash.c | 144 +++
arch
Hiroshi Shimamoto
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Hiroshi Shimamoto [EMAIL PROTECTED]
Signed-off-by: Hiroshi Shimamoto [EMAIL PROTECTED]
---
include/asm-x86/smp_64.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/asm-x86/smp_64.h b/include/asm-x86/smp_64.h
index 6f0e027..ab612b0 100644
--- a/include/asm
Mike Galbraith wrote:
On Tue, 2007-10-23 at 23:02 +0200, Thomas Gleixner wrote:
Linus,
please pull from:
ssh://master.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
This contains a couple of bug fixes and a large cleanup and
unification section from various authors.
Vivek Goyal wrote:
On Fri, Oct 19, 2007 at 06:18:27PM -0700, Hiroshi Shimamoto wrote:
Hi,
I made patches to unify crash_32/64.c.
There are three patches;
1. add lapic_shutdown for x86_64
2. add safe_smp_processor_id for x86_64
3. unify crash_32/64.c
I'm not sure that it's good to split
Vivek Goyal wrote:
On Fri, Oct 19, 2007 at 06:21:11PM -0700, Hiroshi Shimamoto wrote:
From: Hiroshi Shimamoto [EMAIL PROTECTED]
Signed-off-by: Hiroshi Shimamoto [EMAIL PROTECTED]
---
arch/x86/kernel/apic_64.c | 14 ++
include/asm-x86/apic_64.h |1 +
2 files changed, 15
Hi Ingo,
I think an interface to access RLIMIT_RTTIME from outside is useful.
It makes administrator able to set RLIMIT_RTTIME watchdog to existing
real-time applications without impact.
I implemented that interface with /proc filesystem.
---
From: Hiroshi Shimamoto [EMAIL PROTECTED]
Introduce
From: Hiroshi Shimamoto [EMAIL PROTECTED]
Introduce new proc interface for RTTIME watchdog.
It makes administrator able to set RTTIME watchdog to existing
real-time applications without impact.
$ echo 1000 /proc/pid/rttime
set RTTIME current value to 1000, it means 10sec.
$ echo
Peter Zijlstra wrote:
On Mon, 2008-02-11 at 13:44 -0800, Hiroshi Shimamoto wrote:
Hi Ingo,
I think an interface to access RLIMIT_RTTIME from outside is useful.
It makes administrator able to set RLIMIT_RTTIME watchdog to existing
real-time applications without impact.
I implemented
Andrew Morton wrote:
On Tue, 12 Feb 2008 14:41:42 -0800 Hiroshi Shimamoto [EMAIL PROTECTED]
wrote:
From: Hiroshi Shimamoto [EMAIL PROTECTED]
Introduce new proc interface for RTTIME watchdog.
It makes administrator able to set RTTIME watchdog to existing
real-time applications without
Peter Zijlstra wrote:
On Tue, 2008-02-12 at 14:21 -0800, Hiroshi Shimamoto wrote:
Peter Zijlstra wrote:
On Mon, 2008-02-11 at 13:44 -0800, Hiroshi Shimamoto wrote:
Hi Ingo,
I think an interface to access RLIMIT_RTTIME from outside is useful.
It makes administrator able to set RLIMIT_RTTIME
From: Hiroshi Shimamoto [EMAIL PROTECTED]
At lstats_open(), calling get_proc_task() gets task struct, but it never put.
put_task_struct() should be called when releasing.
Signed-off-by: Hiroshi Shimamoto [EMAIL PROTECTED]
---
fs/proc/base.c | 11 ++-
1 files changed, 10 insertions
From: Hiroshi Shimamoto [EMAIL PROTECTED]
Reading /proc/pid/latency or /proc/pid/task/tid/latency could cause
NULL pointer dereference.
In lstats_open(), get_proc_task() can return NULL, in which case the kernel
will oops at lstats_show_proc() because m-private is NULL.
When get_proc_task
Hi,
I posted 2 patches to fix kernel panic and memory leak.
http://lkml.org/lkml/2008/2/14/282
http://lkml.org/lkml/2008/2/14/283
But, I think this patch is better than old ones.
---
From: Hiroshi Shimamoto [EMAIL PROTECTED]
Reading /proc/pid/latency or /proc/pid/task/tid/latency could cause
sched_class from wake_up_new_task()
to sched_fork().
Signed-off-by: Hiroshi Shimamoto [EMAIL PROTECTED]
---
diff --git a/kernel/sched.c b/kernel/sched.c
index 6107a0c..8862761 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -1641,6 +1641,8 @@ void sched_fork(struct task_struct *p, int
Ingo Molnar wrote:
* Hiroshi Shimamoto [EMAIL PROTECTED] wrote:
From: Hiroshi Shimamoto [EMAIL PROTECTED]
Subject: [PATCH] x86: move warning message of polling idle and HT enabled
This warning at idle_setup() is never shown because smp_num_sibling hasn't
been updated at this point yet
().
It also needs Andi's patch for 32-bit.
i386: Move MWAIT idle check to generic CPU
http://lkml.org/lkml/2008/1/2/358
[PATCH 1/2] x86: move warning message of polling idle and HT enabled
[PATCH 2/2] x86_64: move select_idle_routine() call after detect_ht()
Thanks,
Hiroshi Shimamoto
From: Hiroshi Shimamoto [EMAIL PROTECTED]
Subject: [PATCH] x86: move warning message of polling idle and HT enabled
The warning message at idle_setup() is never shown because smp_num_sibling
hasn't
been updated at this point yet.
Move this polling idle and HT enabled warning
From: Hiroshi Shimamoto [EMAIL PROTECTED]
Subject: [PATCH] x86_64: move select_idle_routine() call after detect_ht()
Move the select_idle_routine() call to after the detect_ht() call at
identify_cpu() on 64-bit.
This change is for printing the polling idle and HT enabled warning
message properly
is required because struct pt_regs
and elf_gregset_t are different.
---
From: Hiroshi Shimamoto [EMAIL PROTECTED]
Subject: [PATCH] x86: kdump needs ELF_CORE_COPY_REGS macro
kdump needs ELF_CORE_COPY_REGS in crash_save_cpu().
This lack of the macro causes the following BUG.
SysRq : Trigger
From: Hiroshi Shimamoto [EMAIL PROTECTED]
Introduce new proc interface for RTTIME watchdog.
It makes administrator able to set RTTIME watchdog to existing real-time
applications without impact. It's useful we don't want to change software
stack, but use RTTIME watchdog for that software.
New
Ingo Molnar wrote:
* Arjan van de Ven [EMAIL PROTECTED] wrote:
On Thu, 14 Feb 2008 14:51:19 -0800
Hiroshi Shimamoto [EMAIL PROTECTED] wrote:
Hi,
I posted 2 patches to fix kernel panic and memory leak.
http://lkml.org/lkml/2008/2/14/282
http://lkml.org/lkml/2008/2/14/283
But, I think
From: Hiroshi Shimamoto [EMAIL PROTECTED]
clean up for unification.
Signed-off-by: Hiroshi Shimamoto [EMAIL PROTECTED]
---
arch/x86/kernel/cpu/proc.c| 120 +++-
arch/x86/kernel/cpu/proc_64.c | 63 -
2 files changed, 105 insertions
From: Hiroshi Shimamoto [EMAIL PROTECTED]
Change /proc/cpuinfo. It will look like x86_64's.
'power management' line is added and power management information
will be printed at the line.
Signed-off-by: Hiroshi Shimamoto [EMAIL PROTECTED]
---
arch/x86/kernel/cpu/proc.c | 14 +-
1
From: Hiroshi Shimamoto [EMAIL PROTECTED]
x86 /proc/cpuinfo code can be unified.
This is the first step of unification.
Signed-off-by: Hiroshi Shimamoto [EMAIL PROTECTED]
---
arch/x86/kernel/cpu/Makefile |1 +
arch/x86/kernel/cpu/proc_64.c | 126
From: Hiroshi Shimamoto [EMAIL PROTECTED]
make cpu/proc.c and cpu/proc_64.c same.
Signed-off-by: Hiroshi Shimamoto [EMAIL PROTECTED]
---
arch/x86/kernel/cpu/proc.c| 36 ++
arch/x86/kernel/cpu/proc_64.c | 49 +++-
2 files
From: Hiroshi Shimamoto [EMAIL PROTECTED]
Now cpu/proc.c and cpu/proc_64.c are same.
So cpu/proc_64.c can be removed.
Signed-off-by: Hiroshi Shimamoto [EMAIL PROTECTED]
---
arch/x86/kernel/cpu/Makefile |5 +-
arch/x86/kernel/cpu/proc_64.c | 180 -
2
: Hiroshi Shimamoto [EMAIL PROTECTED]
Change getting task_struct by get_proc_task() at read or write time,
and returns -ESRCH if get_proc_task() returns NULL.
This is same behavior as other /proc files.
Signed-off-by: Hiroshi Shimamoto [EMAIL PROTECTED]
---
fs/proc/base.c | 40
CONFIG_IRQBALANCE doesn't exist on x86_64.
Signed-off-by: Hiroshi Shimamoto [EMAIL PROTECTED]
---
arch/x86/kernel/io_apic_64.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/io_apic_64.c b/arch/x86/kernel/io_apic_64.c
index 953328b..04b90ce 100644
Subject: Re: [PATCH] ixgbe: make VLAN filter conditional in SR-IOV case
On Thu, 2014-11-13 at 08:28 +, Hiroshi Shimamoto wrote:
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Disable hardware VLAN filtering if netdev-features VLAN flag is dropped.
In SR-IOV case
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Disable hardware VLAN filtering if netdev-features VLAN flag is dropped.
In SR-IOV case, there is a use case which needs to disable VLAN filter.
For example, we need to make a network function with VF in virtualized
environment. That network
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
The limitation of the number of multicast address for VF is not enough
for the large scale server with SR-IOV feature.
IPv6 requires the multicast MAC address for each IP address to handle
the Neighbor Solicitation message.
We couldn't assign over
Subject: Re: [E1000-devel] [PATCH] ixgbe, ixgbevf: Add new mbox API to
enable MC promiscuous mode
On 11/27/2014 02:39 AM, Hiroshi Shimamoto wrote:
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
The limitation of the number of multicast address for VF is not enough
Subject: Re: [E1000-devel] [PATCH] ixgbe, ixgbevf: Add new mbox API to
enable MC promiscuous mode
On 11/27/2014 02:39 AM, Hiroshi Shimamoto wrote:
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
The limitation of the number of multicast address for VF is not enough
Subject: Re: [E1000-devel] [PATCH] ixgbe, ixgbevf: Add new mbox API to enable
MC promiscuous mode
On 11/27/2014 02:39 AM, Hiroshi Shimamoto wrote:
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
The limitation of the number of multicast address for VF is not enough
for the large
Subject: Re: [E1000-devel] [PATCH 1/3] ixgbe, ixgbevf: Add new mbox API to
enable MC promiscuous mode
On Fri, 2015-01-30 at 11:37 +, Hiroshi Shimamoto wrote:
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
The limitation of the number of multicast address for VF is not enough
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Implements the new netdev op to turn VF multicast promiscuous mode on or off.
When VF multicast promiscuous mode is enabled, all multicast packets are
delivered to the VF.
After enabling multicast promiscuous mode from the host, we can use over
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Add netlink directives and ndo entry to control VF multicast promiscuous mode.
Intel ixgbe and ixgbevf driver can handle only 30 multicast MAC addresses
per VF. It means that we cannot assign over 30 IPv6 addresses to a single
VF interface on VM
Subject: Re: [PATCH 1/2] if_link: Add VF multicast promiscuous mode control
Hiroshi Shimamoto h-shimam...@ct.jp.nec.com writes:
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Add netlink directives and ndo entry to control VF multicast promiscuous
mode.
Intel ixgbe
Subject: RE: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast promiscuous
mode control
Skidmore, Donald C donald.c.skidm...@intel.com writes:
My hang up is more related to: without the nob to enable it (off by
default) we are letting one VF dictate policy for all the other VFs
Subject: RE: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast promiscuous
mode control
-Original Message-
From: Hiroshi Shimamoto [mailto:h-shimam...@ct.jp.nec.com]
Sent: Tuesday, January 20, 2015 3:40 PM
To: Bjørn Mork
Cc: e1000-de...@lists.sourceforge.net; net
Subject: RE: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast promiscuous
mode control
-Original Message-
From: Hiroshi Shimamoto [mailto:h-shimam...@ct.jp.nec.com]
Sent: Tuesday, January 20, 2015 5:07 PM
To: Skidmore, Donald C; Bjørn Mork
Cc: e1000-de
Subject: RE: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast promiscuous
mode control
From: Hiroshi Shimamoto
My concern is what is the real issue that VF multicast promiscuous mode can
cause.
I think there is the 4k entries to filter multicast address, and the
current ixgbe
Can you please fix up your patches based on my tree:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/queue.git
Yes. I haven't noticed your tree.
Will resend patches against it.
I encountered an issue with your tree, the commit id is below.
$ git log | head
Subject: RE: [E1000-devel] [PATCH 1/3] ixgbe, ixgbevf: Add new mbox API to
enable MC promiscuous mode
-Original Message-
From: Hiroshi Shimamoto [mailto:h-shimam...@ct.jp.nec.com]
Sent: Monday, February 09, 2015 6:29 PM
To: Kirsher, Jeffrey T
Cc: Alexander Duyck; Skidmore
-Original Message-
From: Hiroshi Shimamoto [mailto:h-shimam...@ct.jp.nec.com]
Sent: Monday, February 09, 2015 6:29 PM
To: Kirsher, Jeffrey T
Cc: Alexander Duyck; Skidmore, Donald C; Bjørn Mork; e1000-
de...@lists.sourceforge.net; net...@vger.kernel.org; Choi, Sy Jong
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Implements the new netdev op to allow VF multicast promiscuous mode.
The administrator can allow to VF multicast promiscuous mode for only
trusted VM. After allowing multicast promiscuous mode from the host,
we can use over 30 IPv6 addresses
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Add netlink directives and ndo entry to allow VF multicast promiscuous mode.
The administrator wants to allow dedicatedly multicast promiscuous per VF.
Signed-off-by: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Reviewed-by: Hayato Momma h-mo
On 01/22/2015 04:32 PM, Hiroshi Shimamoto wrote:
Subject: RE: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast
promiscuous mode control
Skidmore, Donald C donald.c.skidm...@intel.com writes:
My hang up is more related to: without the nob to enable it (off by
default) we
Subject: Re: [E1000-devel] [PATCH 1/3] ixgbe, ixgbevf: Add new mbox API to
enable MC promiscuous mode
On Fri, 2015-01-30 at 11:37 +, Hiroshi Shimamoto wrote:
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
The limitation of the number of multicast address for VF
Can you please fix up your patches based on my tree:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/que
ue.git
Yes. I haven't noticed your tree.
Will resend patches against it.
I encountered an issue with your tree, the commit id is below.
$ git log | head
commit
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
The limitation of the number of multicast address for VF is not enough
for the large scale server with SR-IOV feature.
IPv6 requires the multicast MAC address for each IP address to handle
the Neighbor Solicitation message.
We couldn't assign over
On 03/11/2015 10:58 PM, Hiroshi Shimamoto wrote:
On 03/10/2015 05:59 PM, Hiroshi Shimamoto wrote:
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Disable hardware VLAN filtering if netdev-features VLAN flag is dropped.
In SR-IOV case, there is a use case which needs to disable VLAN
On 03/16/2015 05:33 AM, Hiroshi Shimamoto wrote:
On 03/11/2015 10:58 PM, Hiroshi Shimamoto wrote:
On 03/10/2015 05:59 PM, Hiroshi Shimamoto wrote:
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Disable hardware VLAN filtering if netdev-features VLAN flag is
dropped.
In SR-IOV
On 03/08/2015 02:15 PM, Or Gerlitz wrote:
On Mon, Feb 23, 2015 at 11:14 PM, Jeff Kirsher
jeffrey.t.kirs...@intel.com wrote:
[...]
We discussed this during NetConf last week, and Don is correct that a
custom sysfs interface is not the way we want to handle this. We agreed
upon a
On Mon, 2015-03-09 at 18:52 -0700, Jeff Kirsher wrote:
On Tue, 2015-03-10 at 01:42 +, Hiroshi Shimamoto wrote:
On 03/08/2015 02:15 PM, Or Gerlitz wrote:
On Mon, Feb 23, 2015 at 11:14 PM, Jeff Kirsher
jeffrey.t.kirs...@intel.com wrote:
[...]
We discussed this during
On Fri, 2015-03-06 at 06:04 +, Hiroshi Shimamoto wrote:
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Disable hardware VLAN filtering if netdev-features VLAN flag is
dropped.
In SR-IOV case, there is a use case which needs to disable VLAN
filter.
For example, we need
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Disable hardware VLAN filtering if netdev-features VLAN flag is dropped.
In SR-IOV case, there is a use case which needs to disable VLAN filter.
For example, we need to make a network function with VF in virtualized
environment. That network
On 03/10/2015 05:59 PM, Hiroshi Shimamoto wrote:
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Disable hardware VLAN filtering if netdev-features VLAN flag is dropped.
In SR-IOV case, there is a use case which needs to disable VLAN filter.
For example, we need to make a network
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Disable hardware VLAN filtering if netdev-features VLAN flag is dropped.
In SR-IOV case, there is a use case which needs to disable VLAN filter.
For example, we need to make a network function with VF in virtualized
environment. That network
On Wed, 2015-02-25 at 00:51 +, Hiroshi Shimamoto wrote:
Subject: Re: [E1000-devel] [PATCH] ixgbe: make VLAN filter
conditional in SR-IOV case
On Thu, 2014-11-13 at 08:28 +, Hiroshi Shimamoto wrote:
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Disable hardware
Subject: Re: [E1000-devel] [PATCH] ixgbe: make VLAN filter conditional in
SR-IOV case
On Thu, 2014-11-13 at 08:28 +, Hiroshi Shimamoto wrote:
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Disable hardware VLAN filtering if netdev-features VLAN flag is
dropped.
In SR-IOV
-Original Message-
From: Hiroshi Shimamoto [mailto:h-shimam...@ct.jp.nec.com]
Sent: Thursday, February 19, 2015 5:01 PM
Subject: [E1000-devel] [PATCH v2 3/3] ixgbe: Add new ndo to allow VF
multicast promiscuous mode
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Implements
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Disable hardware VLAN filtering if netdev-features VLAN flag is dropped.
In SR-IOV case, there is a use case which needs to disable VLAN filter.
For example, we need to make a network function with VF in virtualized
environment
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Implements the new netdev op to allow VF multicast promiscuous mode.
The administrator can allow to VF multicast promiscuous mode for only
trusted VM. After allowing multicast promiscuous mode from the host,
we can use over 30 IPv6 addresses
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Add netlink directives and ndo entry to allow VF multicast promiscuous mode.
The administrator wants to allow dedicatedly multicast promiscuous per VF.
Signed-off-by: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Reviewed-by: Hayato Momma h-mo
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
The limitation of the number of multicast address for VF is not enough
for the large scale server with SR-IOV feature.
IPv6 requires the multicast MAC address for each IP address to handle
the Neighbor Solicitation message.
We couldn't assign over
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
The limitation of the number of multicast address for VF is not enough
for the large scale server with SR-IOV feature.
IPv6 requires the multicast MAC address for each IP address to handle
the Neighbor Solicitation message.
We couldn't assign over
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Implements the new netdev op to allow VF multicast promiscuous mode.
The multicast promiscuous mode is not allowed for all VFs by default.
The administrator can allow to VF multicast promiscuous mode for only
trusted VM. After allowing multicast
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Add netlink directives and ndo entry to allow VF multicast promiscuous mode.
This controls the permission to enter VF multicast promiscuous mode.
The administrator will dedicatedly allow multicast promiscuous per VF.
When the VF is under
Subject: Re: [E1000-devel] [PATCH v3 3/3] ixgbe: Add new ndo to allow VF
multicast promiscuous mode
On Wed, 2015-04-08 at 15:15 -0700, Alexander Duyck wrote:
On 04/07/2015 10:38 PM, Hiroshi Shimamoto wrote:
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Implements the new
On 05/21/2015 06:10 AM, Hiroshi Shimamoto wrote:
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Introduce module parameter disable_hw_vlan_filter to disable HW VLAN
filter on ixgbe module load.
From the hardware limitation, there are only 64 VLAN entries for HW VLAN
filter
Subject: Re: [Intel-wired-lan] [PATCH v5] ixgbe: Add module parameter to
disable VLAN filter
On 05/26/2015 06:11 PM, Hiroshi Shimamoto wrote:
On 05/21/2015 06:10 AM, Hiroshi Shimamoto wrote:
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Introduce module parameter
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Introduce module parameter disable_hw_vlan_filter to disable HW VLAN
filter on ixgbe module load.
From the hardware limitation, there are only 64 VLAN entries for HW VLAN
filter, and it leads to limit the number of VLANs up to 64 among PF and
VFs
Subject: Re: [PATCH v5] ixgbe: Add module parameter to disable VLAN filter
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Date: Thu, 21 May 2015 13:10:49 +
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 263cb40
From: Hiroshi Shimamoto <h-shimam...@ct.jp.nec.com>
/proc/stats shows invalid gtime when the thread is running in guest.
When vtime accounting is not enabled, we cannot get a valid delta.
The delta is calculated now - tsk->vtime_snap, but tsk->vtime_snap
is only updated when vtim
From: Hiroshi Shimamoto <h-shimam...@ct.jp.nec.com>
There is an extra cost in task_cputime() and task_cputime_scaled() when
nohz_full is not activated. This patch removes that cost. When vtime
accounting is not enabled, we don't need to get deltas of utime and stime
with seqlock.
This patc
From: Hiroshi Shimamoto <h-shimam...@ct.jp.nec.com>
/proc/stats shows invalid gtime when the thread is running in guest.
When vtime accounting is not enabled, we cannot get a valid delta.
The delta is calculated now - tsk->vtime_snap, but tsk->vtime_snap
is only updated when vtim
> Subject: Re: [PATCH v2] cputime: fix invalid gtime
>
> On Thu, Oct 29, 2015 at 01:10:01AM +, Hiroshi Shimamoto wrote:
> > > Obviously I completely messed up there. And task_cputime() has a similar
> > > issue
> > > but it happens to work due to vti
> Subject: Re: [PATCH v2] cputime: fix invalid gtime
>
> On Wed, Oct 28, 2015 at 07:01:18AM +, Hiroshi Shimamoto wrote:
> > From: Hiroshi Shimamoto <h-shimam...@ct.jp.nec.com>
> >
> > /proc/stats shows invalid gtime when the thread is running in guest.
> &g
> Subject: Re: [PATCH v3 1/2] cputime: fix invalid gtime in proc
>
> On Mon, Nov 02, 2015 at 05:13:51PM +0100, Peter Zijlstra wrote:
> > On Fri, Oct 30, 2015 at 12:46:39AM +, Hiroshi Shimamoto wrote:
> > > +++ b/kernel/sched/cputime.c
> > > @@ -786,6 +786
1 - 100 of 215 matches
Mail list logo
