RE: [Intel-wired-lan] [PATCH] fm10k: mark PM functions as __maybe_unused

2017-11-28 Thread Singh, Krishneil K 


> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf
> Of Keller, Jacob E
> Sent: Wednesday, October 11, 2017 3:20 PM
> To: Arnd Bergmann ; Kirsher, Jeffrey T
> 
> Cc: Kwan, Ngai-mint ; net...@vger.kernel.org;
> Florian Westphal ; linux-kernel@vger.kernel.org; intel-wired-
> l...@lists.osuosl.org; David S. Miller 
> Subject: Re: [Intel-wired-lan] [PATCH] fm10k: mark PM functions as
> __maybe_unused
> 
> 
> 
> > -Original Message-
> > From: Arnd Bergmann [mailto:a...@arndb.de]
> > Sent: Wednesday, October 11, 2017 6:58 AM
> > To: Kirsher, Jeffrey T 
> > Cc: Arnd Bergmann ; Keller, Jacob E
> > ; Kwan, Ngai-mint ;
> > David S. Miller ; Florian Westphal ;
> > intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux-
> > ker...@vger.kernel.org
> > Subject: [PATCH] fm10k: mark PM functions as __maybe_unused
> >
> > A cleanup of the PM code left an incorrect #ifdef in place, leading
> > to a harmless build warning:
> >
> > drivers/net/ethernet/intel/fm10k/fm10k_pci.c:2502:12: error:
> 'fm10k_suspend'
> > defined but not used [-Werror=unused-function]
> > drivers/net/ethernet/intel/fm10k/fm10k_pci.c:2475:12: error:
> 'fm10k_resume'
> > defined but not used [-Werror=unused-function]
> >
> > It's easier to use __maybe_unused attributes here, since you
> > can't pick the wrong one.
> >
> 
> Acked-by: Jacob Keller 
> 
> > Fixes: 8249c47c6ba4 ("fm10k: use generic PM hooks instead of legacy PCIe
> power
> > hooks")
> > Signed-off-by: Arnd Bergmann 
> > ---
> >  drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 9 ++---
> >  1 file changed, 2 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
> > b/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
> > index 1e9ae3197b17..52f8eb3c470e 100644
> > --- a/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
> > +++ b/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
> > @@ -2463,7 +2463,6 @@ static int fm10k_handle_resume(struct fm10k_intfc
> > *interface)
> > return err;
> >  }
> >
> > -#ifdef CONFIG_PM
> >  /**
> >   * fm10k_resume - Generic PM resume hook
> >   * @dev: generic device structure
> > @@ -2472,7 +2471,7 @@ static int fm10k_handle_resume(struct fm10k_intfc
> > *interface)
> >   * suspend or hibernation. This function does not need to handle lower PCIe
> >   * device state as the stack takes care of that for us.
> >   **/
> > -static int fm10k_resume(struct device *dev)
> > +static int __maybe_unused fm10k_resume(struct device *dev)
> >  {
> > struct fm10k_intfc *interface = pci_get_drvdata(to_pci_dev(dev));
> > struct net_device *netdev = interface->netdev;
> > @@ -2499,7 +2498,7 @@ static int fm10k_resume(struct device *dev)
> >   * system suspend or hibernation. This function does not need to handle
> lower
> >   * PCIe device state as the stack takes care of that for us.
> >   **/
> > -static int fm10k_suspend(struct device *dev)
> > +static int __maybe_unused fm10k_suspend(struct device *dev)
> >  {
> > struct fm10k_intfc *interface = pci_get_drvdata(to_pci_dev(dev));
> > struct net_device *netdev = interface->netdev;
> > @@ -2511,8 +2510,6 @@ static int fm10k_suspend(struct device *dev)
> > return 0;
> >  }
> >
> > -#endif /* CONFIG_PM */
> > -
> >  /**
> >   * fm10k_io_error_detected - called when PCI error is detected
> >   * @pdev: Pointer to PCI device
> > @@ -2643,11 +2640,9 @@ static struct pci_driver fm10k_driver = {
> > .id_table   = fm10k_pci_tbl,
> > .probe  = fm10k_probe,
> > .remove = fm10k_remove,
> > -#ifdef CONFIG_PM
> > .driver = {
> > .pm = _pm_ops,
> > },
> > -#endif /* CONFIG_PM */
> > .sriov_configure= fm10k_iov_configure,
> > .err_handler= _err_handler
> >  };
> > --
> > 2.9.0
> 
> ___
> Intel-wired-lan mailing list
> intel-wired-...@osuosl.org
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

Tested-by: Krishneil Singh

RE: [Intel-wired-lan] [PATCH] fm10k: mark PM functions as __maybe_unused

2017-11-28 Thread Singh, Krishneil K 


> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf
> Of Keller, Jacob E
> Sent: Wednesday, October 11, 2017 3:20 PM
> To: Arnd Bergmann ; Kirsher, Jeffrey T
> 
> Cc: Kwan, Ngai-mint ; net...@vger.kernel.org;
> Florian Westphal ; linux-kernel@vger.kernel.org; intel-wired-
> l...@lists.osuosl.org; David S. Miller 
> Subject: Re: [Intel-wired-lan] [PATCH] fm10k: mark PM functions as
> __maybe_unused
> 
> 
> 
> > -Original Message-
> > From: Arnd Bergmann [mailto:a...@arndb.de]
> > Sent: Wednesday, October 11, 2017 6:58 AM
> > To: Kirsher, Jeffrey T 
> > Cc: Arnd Bergmann ; Keller, Jacob E
> > ; Kwan, Ngai-mint ;
> > David S. Miller ; Florian Westphal ;
> > intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux-
> > ker...@vger.kernel.org
> > Subject: [PATCH] fm10k: mark PM functions as __maybe_unused
> >
> > A cleanup of the PM code left an incorrect #ifdef in place, leading
> > to a harmless build warning:
> >
> > drivers/net/ethernet/intel/fm10k/fm10k_pci.c:2502:12: error:
> 'fm10k_suspend'
> > defined but not used [-Werror=unused-function]
> > drivers/net/ethernet/intel/fm10k/fm10k_pci.c:2475:12: error:
> 'fm10k_resume'
> > defined but not used [-Werror=unused-function]
> >
> > It's easier to use __maybe_unused attributes here, since you
> > can't pick the wrong one.
> >
> 
> Acked-by: Jacob Keller 
> 
> > Fixes: 8249c47c6ba4 ("fm10k: use generic PM hooks instead of legacy PCIe
> power
> > hooks")
> > Signed-off-by: Arnd Bergmann 
> > ---
> >  drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 9 ++---
> >  1 file changed, 2 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
> > b/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
> > index 1e9ae3197b17..52f8eb3c470e 100644
> > --- a/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
> > +++ b/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
> > @@ -2463,7 +2463,6 @@ static int fm10k_handle_resume(struct fm10k_intfc
> > *interface)
> > return err;
> >  }
> >
> > -#ifdef CONFIG_PM
> >  /**
> >   * fm10k_resume - Generic PM resume hook
> >   * @dev: generic device structure
> > @@ -2472,7 +2471,7 @@ static int fm10k_handle_resume(struct fm10k_intfc
> > *interface)
> >   * suspend or hibernation. This function does not need to handle lower PCIe
> >   * device state as the stack takes care of that for us.
> >   **/
> > -static int fm10k_resume(struct device *dev)
> > +static int __maybe_unused fm10k_resume(struct device *dev)
> >  {
> > struct fm10k_intfc *interface = pci_get_drvdata(to_pci_dev(dev));
> > struct net_device *netdev = interface->netdev;
> > @@ -2499,7 +2498,7 @@ static int fm10k_resume(struct device *dev)
> >   * system suspend or hibernation. This function does not need to handle
> lower
> >   * PCIe device state as the stack takes care of that for us.
> >   **/
> > -static int fm10k_suspend(struct device *dev)
> > +static int __maybe_unused fm10k_suspend(struct device *dev)
> >  {
> > struct fm10k_intfc *interface = pci_get_drvdata(to_pci_dev(dev));
> > struct net_device *netdev = interface->netdev;
> > @@ -2511,8 +2510,6 @@ static int fm10k_suspend(struct device *dev)
> > return 0;
> >  }
> >
> > -#endif /* CONFIG_PM */
> > -
> >  /**
> >   * fm10k_io_error_detected - called when PCI error is detected
> >   * @pdev: Pointer to PCI device
> > @@ -2643,11 +2640,9 @@ static struct pci_driver fm10k_driver = {
> > .id_table   = fm10k_pci_tbl,
> > .probe  = fm10k_probe,
> > .remove = fm10k_remove,
> > -#ifdef CONFIG_PM
> > .driver = {
> > .pm = _pm_ops,
> > },
> > -#endif /* CONFIG_PM */
> > .sriov_configure= fm10k_iov_configure,
> > .err_handler= _err_handler
> >  };
> > --
> > 2.9.0
> 
> ___
> Intel-wired-lan mailing list
> intel-wired-...@osuosl.org
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

Tested-by: Krishneil Singh

RE: [Intel-wired-lan] [PATCH] fm10k: Fix misuse of net_ratelimit()

2017-09-18 Thread Singh, Krishneil K 


> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf
> Of Joe Perches
> Sent: Friday, August 11, 2017 9:17 AM
> To: Kirsher, Jeffrey T 
> Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux-
> ker...@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH] fm10k: Fix misuse of net_ratelimit()
> 
> Correct the backward logic using !net_ratelimit()
> 
> Miscellanea:
> 
> o Add a blank line before the error return label
> 
> Signed-off-by: Joe Perches 
> ---

Tested-by: Krishneil Singh

RE: [Intel-wired-lan] [PATCH] fm10k: Fix misuse of net_ratelimit()

2017-09-18 Thread Singh, Krishneil K 


> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf
> Of Joe Perches
> Sent: Friday, August 11, 2017 9:17 AM
> To: Kirsher, Jeffrey T 
> Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux-
> ker...@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH] fm10k: Fix misuse of net_ratelimit()
> 
> Correct the backward logic using !net_ratelimit()
> 
> Miscellanea:
> 
> o Add a blank line before the error return label
> 
> Signed-off-by: Joe Perches 
> ---

Tested-by: Krishneil Singh

RE: [Intel-wired-lan] [PATCH] fm10k: Use seq_putc() in fm10k_dbg_desc_break()

2017-09-18 Thread Singh, Krishneil K 

> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf
> Of SF Markus Elfring
> Sent: Monday, May 8, 2017 9:18 AM
> To: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; Kirsher, 
> Jeffrey T
> 
> Cc: kernel-janit...@vger.kernel.org; LKML 
> Subject: [Intel-wired-lan] [PATCH] fm10k: Use seq_putc() in
> fm10k_dbg_desc_break()
> 
> From: Markus Elfring 
> Date: Mon, 8 May 2017 18:10:39 +0200
> 
> Two single characters should be put into a sequence.
> Thus use the corresponding function "seq_putc".
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---

Tested-by: Krishneil Singh

RE: [Intel-wired-lan] [PATCH] fm10k: Use seq_putc() in fm10k_dbg_desc_break()

2017-09-18 Thread Singh, Krishneil K 

> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf
> Of SF Markus Elfring
> Sent: Monday, May 8, 2017 9:18 AM
> To: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; Kirsher, 
> Jeffrey T
> 
> Cc: kernel-janit...@vger.kernel.org; LKML 
> Subject: [Intel-wired-lan] [PATCH] fm10k: Use seq_putc() in
> fm10k_dbg_desc_break()
> 
> From: Markus Elfring 
> Date: Mon, 8 May 2017 18:10:39 +0200
> 
> Two single characters should be put into a sequence.
> Thus use the corresponding function "seq_putc".
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---

Tested-by: Krishneil Singh

RE: [Intel-wired-lan] [PATCH] ixgbe: initialize u64_stats_sync structures early at ixgbe_probe

2017-04-24 Thread Singh, Krishneil K 



-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On 
Behalf Of Liwei Song
Sent: Sunday, December 4, 2016 7:41 PM
To: Kirsher, Jeffrey T 
Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; 
linux-kernel@vger.kernel.org; Song, Liwei (Wind River) 

Subject: [Intel-wired-lan] [PATCH] ixgbe: initialize u64_stats_sync structures 
early at ixgbe_probe

Fix the following CallTrace:
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 71 PID: 1 Comm: swapper/0 Not tainted 4.8.8-WR9.0.0.1_standard #11 
Hardware name: Intel Corporation S2600WTT/S2600WTT, BIOS 
GRNDSDP1.86B.0036.R05.1407140519 07/14/2014
 00200086 00200086 eb5e1ab8 c144dd70   eb5e1af8 c10af89a
 c1d23de4 eb5e1af8 0009 eb5d8600 eb5d8638 eb5e1af8 c10b14d8 0009  
000a c1d32911   e44c826c eb5d8000 eb5e1b74 c10b214e Call 
Trace:
 [] dump_stack+0x5f/0x8f
 [] register_lock_class+0x25a/0x4c0  [] ? 
check_irq_usage+0x88/0xc0  [] __lock_acquire+0x5e/0x17a0  
[] ? _raw_spin_unlock_irqrestore+0x3b/0x70
 [] ? rcu_read_lock_sched_held+0x8a/0x90
 [] lock_acquire+0x9f/0x1f0
 [] ? dev_get_stats+0x5f/0x110  [] 
ixgbe_get_stats64+0x113/0x320  [] ? dev_get_stats+0x5f/0x110  
[] dev_get_stats+0x5f/0x110  [] rtnl_fill_stats+0x40/0x105  
[] rtnl_fill_ifinfo+0x4c5/0xd20  [] ? 
__kmalloc_node_track_caller+0x1a5/0x410
 [] ? __kmalloc_reserve.isra.42+0x27/0x80
 [] ? __alloc_skb+0x6f/0x270
 [] rtmsg_ifinfo_build_skb+0x71/0xd0  [] 
rtmsg_ifinfo.part.23+0x1a/0x50  [] ? 
call_netdevice_notifiers_info+0x2d/0x60
 [] rtmsg_ifinfo+0x2b/0x40
 [] register_netdevice+0x3d7/0x4d0  [] 
register_netdev+0x17/0x30  [] ixgbe_probe+0x118d/0x1610  [] 
local_pci_probe+0x32/0x80  [] ? pci_match_device+0xd2/0x100  
[] pci_device_probe+0xc0/0x110  [] 
driver_probe_device+0x1c5/0x280  [] ? pci_match_device+0xd2/0x100  
[] __driver_attach+0x89/0x90  [] ? 
driver_probe_device+0x280/0x280  [] bus_for_each_dev+0x4f/0x80  
[] driver_attach+0x1e/0x20  [] ? 
driver_probe_device+0x280/0x280  [] bus_add_driver+0x1a7/0x220  
[] driver_register+0x59/0xe0  [] ? 
igb_init_module+0x49/0x49  [] __pci_register_driver+0x4a/0x50  
[] ixgbe_init_module+0xa5/0xc4  [] 
do_one_initcall+0x35/0x150  [] ? parameq+0x18/0x70  [] ? 
repair_env_string+0x12/0x51  [] ? parse_args+0x260/0x3b0  
[] ? __usermodehelper_set_disable_depth+0x43/0x50
 [] kernel_init_freeable+0x19b/0x267  [] ? 
set_debug_rodata+0xf/0xf  [] ? trace_hardirqs_on+0xb/0x10  
[] ? _raw_spin_unlock_irq+0x32/0x50  [] ? 
finish_task_switch+0xab/0x1f0  [] ? finish_task_switch+0x69/0x1f0  
[] kernel_init+0x10/0x110  [] ? schedule_tail+0x25/0x80  
[] ret_from_kernel_thread+0xe/0x24  [] ? 
rest_init+0x130/0x130

This CallTrace occurred on 32-bit kernel with CONFIG_PROVE_LOCKING enabled.

This happens at ixgbe driver probe hardware stage, when comes to 
ixgbe_get_stats64, the seqcount/seqlock still not initialize, although this was 
initialize in TX/RX resources setup routin, but it was too late, then lockdep 
give this Warning.

To fix this, move the u64_stats_init function to driver probe stage, which 
before we get the status of seqcount and after the RX/TX ring was finished init.

Signed-off-by: Liwei Song 
---

Tested-by: Krishneil Singh

RE: [Intel-wired-lan] [PATCH] ixgbe: initialize u64_stats_sync structures early at ixgbe_probe

2017-04-24 Thread Singh, Krishneil K 



-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On 
Behalf Of Liwei Song
Sent: Sunday, December 4, 2016 7:41 PM
To: Kirsher, Jeffrey T 
Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; 
linux-kernel@vger.kernel.org; Song, Liwei (Wind River) 

Subject: [Intel-wired-lan] [PATCH] ixgbe: initialize u64_stats_sync structures 
early at ixgbe_probe

Fix the following CallTrace:
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 71 PID: 1 Comm: swapper/0 Not tainted 4.8.8-WR9.0.0.1_standard #11 
Hardware name: Intel Corporation S2600WTT/S2600WTT, BIOS 
GRNDSDP1.86B.0036.R05.1407140519 07/14/2014
 00200086 00200086 eb5e1ab8 c144dd70   eb5e1af8 c10af89a
 c1d23de4 eb5e1af8 0009 eb5d8600 eb5d8638 eb5e1af8 c10b14d8 0009  
000a c1d32911   e44c826c eb5d8000 eb5e1b74 c10b214e Call 
Trace:
 [] dump_stack+0x5f/0x8f
 [] register_lock_class+0x25a/0x4c0  [] ? 
check_irq_usage+0x88/0xc0  [] __lock_acquire+0x5e/0x17a0  
[] ? _raw_spin_unlock_irqrestore+0x3b/0x70
 [] ? rcu_read_lock_sched_held+0x8a/0x90
 [] lock_acquire+0x9f/0x1f0
 [] ? dev_get_stats+0x5f/0x110  [] 
ixgbe_get_stats64+0x113/0x320  [] ? dev_get_stats+0x5f/0x110  
[] dev_get_stats+0x5f/0x110  [] rtnl_fill_stats+0x40/0x105  
[] rtnl_fill_ifinfo+0x4c5/0xd20  [] ? 
__kmalloc_node_track_caller+0x1a5/0x410
 [] ? __kmalloc_reserve.isra.42+0x27/0x80
 [] ? __alloc_skb+0x6f/0x270
 [] rtmsg_ifinfo_build_skb+0x71/0xd0  [] 
rtmsg_ifinfo.part.23+0x1a/0x50  [] ? 
call_netdevice_notifiers_info+0x2d/0x60
 [] rtmsg_ifinfo+0x2b/0x40
 [] register_netdevice+0x3d7/0x4d0  [] 
register_netdev+0x17/0x30  [] ixgbe_probe+0x118d/0x1610  [] 
local_pci_probe+0x32/0x80  [] ? pci_match_device+0xd2/0x100  
[] pci_device_probe+0xc0/0x110  [] 
driver_probe_device+0x1c5/0x280  [] ? pci_match_device+0xd2/0x100  
[] __driver_attach+0x89/0x90  [] ? 
driver_probe_device+0x280/0x280  [] bus_for_each_dev+0x4f/0x80  
[] driver_attach+0x1e/0x20  [] ? 
driver_probe_device+0x280/0x280  [] bus_add_driver+0x1a7/0x220  
[] driver_register+0x59/0xe0  [] ? 
igb_init_module+0x49/0x49  [] __pci_register_driver+0x4a/0x50  
[] ixgbe_init_module+0xa5/0xc4  [] 
do_one_initcall+0x35/0x150  [] ? parameq+0x18/0x70  [] ? 
repair_env_string+0x12/0x51  [] ? parse_args+0x260/0x3b0  
[] ? __usermodehelper_set_disable_depth+0x43/0x50
 [] kernel_init_freeable+0x19b/0x267  [] ? 
set_debug_rodata+0xf/0xf  [] ? trace_hardirqs_on+0xb/0x10  
[] ? _raw_spin_unlock_irq+0x32/0x50  [] ? 
finish_task_switch+0xab/0x1f0  [] ? finish_task_switch+0x69/0x1f0  
[] kernel_init+0x10/0x110  [] ? schedule_tail+0x25/0x80  
[] ret_from_kernel_thread+0xe/0x24  [] ? 
rest_init+0x130/0x130

This CallTrace occurred on 32-bit kernel with CONFIG_PROVE_LOCKING enabled.

This happens at ixgbe driver probe hardware stage, when comes to 
ixgbe_get_stats64, the seqcount/seqlock still not initialize, although this was 
initialize in TX/RX resources setup routin, but it was too late, then lockdep 
give this Warning.

To fix this, move the u64_stats_init function to driver probe stage, which 
before we get the status of seqcount and after the RX/TX ring was finished init.

Signed-off-by: Liwei Song 
---

Tested-by: Krishneil Singh

RE: [Intel-wired-lan] [PATCH] net: ethernet: intel: fm10k: Remove create_workqueue

2016-07-11 Thread Singh, Krishneil K 

-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On 
Behalf Of Bhaktipriya Shridhar
Sent: Wednesday, June 1, 2016 8:40 AM
To: Kirsher, Jeffrey T 
Cc: Tejun Heo ; net...@vger.kernel.org; 
intel-wired-...@lists.osuosl.org; linux-kernel@vger.kernel.org
Subject: [Intel-wired-lan] [PATCH] net: ethernet: intel: fm10k: Remove 
create_workqueue

alloc_workqueue replaces deprecated create_workqueue().

A dedicated workqueue has been used since the workitem (viz fm10k_service_task, 
which manages and runs other subtasks) is involved in normal device operation 
and requires forward progress under memory pressure.

create_workqueue has been replaced with alloc_workqueue with max_active as 0 
since there is no need for throttling the number of active work items.

Since network devices may be used in memory reclaim path, WQ_MEM_RECLAIM has 
been set to guarantee forward progress.

flush_workqueue is unnecessary since destroy_workqueue() itself calls
drain_workqueue() which flushes repeatedly till the workqueue becomes empty. 
Hence the call to flush_workqueue() has been dropped.

Signed-off-by: Bhaktipriya Shridhar 
---

Tested-by: Krishneil Singh

RE: [Intel-wired-lan] [PATCH] net: ethernet: intel: fm10k: Remove create_workqueue

2016-07-11 Thread Singh, Krishneil K 

-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On 
Behalf Of Bhaktipriya Shridhar
Sent: Wednesday, June 1, 2016 8:40 AM
To: Kirsher, Jeffrey T 
Cc: Tejun Heo ; net...@vger.kernel.org; 
intel-wired-...@lists.osuosl.org; linux-kernel@vger.kernel.org
Subject: [Intel-wired-lan] [PATCH] net: ethernet: intel: fm10k: Remove 
create_workqueue

alloc_workqueue replaces deprecated create_workqueue().

A dedicated workqueue has been used since the workitem (viz fm10k_service_task, 
which manages and runs other subtasks) is involved in normal device operation 
and requires forward progress under memory pressure.

create_workqueue has been replaced with alloc_workqueue with max_active as 0 
since there is no need for throttling the number of active work items.

Since network devices may be used in memory reclaim path, WQ_MEM_RECLAIM has 
been set to guarantee forward progress.

flush_workqueue is unnecessary since destroy_workqueue() itself calls
drain_workqueue() which flushes repeatedly till the workqueue becomes empty. 
Hence the call to flush_workqueue() has been dropped.

Signed-off-by: Bhaktipriya Shridhar 
---

Tested-by: Krishneil Singh

RE: [Intel-wired-lan] [PATCH] fm10k:Fix error handling in the function fm10k_resume

2015-10-28 Thread Singh, Krishneil K 


-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On 
Behalf Of Nicholas Krause
Sent: Saturday, October 17, 2015 9:21 AM
To: Kirsher, Jeffrey T 
Cc: linux-kernel@vger.kernel.org; intel-wired-...@lists.osuosl.org; 
net...@vger.kernel.org
Subject: [Intel-wired-lan] [PATCH] fm10k:Fix error handling in the function 
fm10k_resume

This fixes error handling to proper check if the call to the function 
fm10k_mbx_request_irq has failed by returning a error code and if so return 
immediately to the caller of fm10k_resume to properly signal a failure has 
occurred when accepting to resume this network

Signed-off-by: Nicholas Krause 
---

Tested-by: Krishneil SIngh 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [Intel-wired-lan] [PATCH] fm10k:Fix error handling in the function fm10k_resume

2015-10-28 Thread Singh, Krishneil K 


-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On 
Behalf Of Nicholas Krause
Sent: Saturday, October 17, 2015 9:21 AM
To: Kirsher, Jeffrey T 
Cc: linux-kernel@vger.kernel.org; intel-wired-...@lists.osuosl.org; 
net...@vger.kernel.org
Subject: [Intel-wired-lan] [PATCH] fm10k:Fix error handling in the function 
fm10k_resume

This fixes error handling to proper check if the call to the function 
fm10k_mbx_request_irq has failed by returning a error code and if so return 
immediately to the caller of fm10k_resume to properly signal a failure has 
occurred when accepting to resume this network

Signed-off-by: Nicholas Krause 
---

Tested-by: Krishneil SIngh 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [Intel-wired-lan] [PATCH] fm10k:Fix error handling in the function fm10k_setup_tc

2015-10-27 Thread Singh, Krishneil K 


-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On 
Behalf Of Nicholas Krause
Sent: Tuesday, October 20, 2015 2:05 PM
To: Kirsher, Jeffrey T 
Cc: linux-kernel@vger.kernel.org; intel-wired-...@lists.osuosl.org; 
net...@vger.kernel.org
Subject: [Intel-wired-lan] [PATCH] fm10k:Fix error handling in the function 
fm10k_setup_tc

This fixes error handling in the function fm10k_setup_tc to properly check if 
the call to the function fm10k_open has failed by returning a error and if so 
return immediately to the caller of the function fm10k_setup_tc to properly 
signal this non recoverable failure.

Signed-off-by: Nicholas Krause 
---

Tested-by: Krishneil Singh 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [Intel-wired-lan] [PATCH] fm10k:Fix error handling in the function fm10k_setup_tc for certain function calls

2015-10-27 Thread Singh, Krishneil K 

-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On 
Behalf Of Nicholas Krause
Sent: Friday, October 9, 2015 8:53 AM
To: Kirsher, Jeffrey T 
Cc: linux-kernel@vger.kernel.org; intel-wired-...@lists.osuosl.org; 
net...@vger.kernel.org
Subject: [Intel-wired-lan] [PATCH] fm10k:Fix error handling in the function 
fm10k_setup_tc for certain function calls

This fixes the function fm10k_setup_tc to propley check if the calls to either 
the function fm10k_init_queueing_scheme or the function fm10k_mbx_request_irq 
fail by returning a error code to signal that the call to either function has 
failed. Furthermore if this arises exit immediately from the function 
fm10k_setup_tc by returning the returned error code from the failed function 
call to signal to the caller that setting up the tc on the device has failed 
and the caller needs to handle this failed setup.

Signed-off-by: Nicholas Krause 
---
 
Tested-by: Krishneil Singh 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [Intel-wired-lan] [PATCH] fm10k:Fix error handling in the function fm10k_setup_tc for certain function calls

2015-10-27 Thread Singh, Krishneil K 

-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On 
Behalf Of Nicholas Krause
Sent: Friday, October 9, 2015 8:53 AM
To: Kirsher, Jeffrey T 
Cc: linux-kernel@vger.kernel.org; intel-wired-...@lists.osuosl.org; 
net...@vger.kernel.org
Subject: [Intel-wired-lan] [PATCH] fm10k:Fix error handling in the function 
fm10k_setup_tc for certain function calls

This fixes the function fm10k_setup_tc to propley check if the calls to either 
the function fm10k_init_queueing_scheme or the function fm10k_mbx_request_irq 
fail by returning a error code to signal that the call to either function has 
failed. Furthermore if this arises exit immediately from the function 
fm10k_setup_tc by returning the returned error code from the failed function 
call to signal to the caller that setting up the tc on the device has failed 
and the caller needs to handle this failed setup.

Signed-off-by: Nicholas Krause 
---
 
Tested-by: Krishneil Singh 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [Intel-wired-lan] [PATCH] fm10k:Fix error handling in the function fm10k_setup_tc

2015-10-27 Thread Singh, Krishneil K 


-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On 
Behalf Of Nicholas Krause
Sent: Tuesday, October 20, 2015 2:05 PM
To: Kirsher, Jeffrey T 
Cc: linux-kernel@vger.kernel.org; intel-wired-...@lists.osuosl.org; 
net...@vger.kernel.org
Subject: [Intel-wired-lan] [PATCH] fm10k:Fix error handling in the function 
fm10k_setup_tc

This fixes error handling in the function fm10k_setup_tc to properly check if 
the call to the function fm10k_open has failed by returning a error and if so 
return immediately to the caller of the function fm10k_setup_tc to properly 
signal this non recoverable failure.

Signed-off-by: Nicholas Krause 
---

Tested-by: Krishneil Singh 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [Intel-wired-lan] [PATCH] ixgbe: Remove bimodal SR-IOV disabling

2015-09-03 Thread Singh, Krishneil K 
-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On 
Behalf Of Alex Williamson
Sent: Friday, July 10, 2015 3:44 PM
To: Rose, Gregory V 
Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; 
linux-kernel@vger.kernel.org
Subject: Re: [Intel-wired-lan] [PATCH] ixgbe: Remove bimodal SR-IOV disabling

On Fri, 2015-07-10 at 21:36 +, Rose, Gregory V wrote:
> 
> > -Original Message-
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Friday, July 10, 2015 2:32 PM
> > To: intel-wired-...@lists.osuosl.org; Kirsher, Jeffrey T
> > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; Rose, 
> > Gregory V
> > Subject: [PATCH] ixgbe: Remove bimodal SR-IOV disabling
> > 
> > When unbinding an SR-IOV device with VFs configured from ixgbe, the 
> > driver behaves in one of two ways.  If max_vfs was specified, the 
> > SR-IOV state is disabled, removing the VFs.  The occurs regardless 
> > of whether the VF count was later modified through sysfs.  If 
> > however max_vfs is zero, such as by not specifying the module 
> > parameter, the VFs persist after the PF is unbound from ixgbe.  If 
> > the PF is then bound to vfio-pci to be assigned to a VM, the PF is 
> > non-functional.
> > 
> > >From the comment, commit da36b64736cf ("ixgbe: Implement PCI SR-IOV
> > sysfs callback operation") clearly intended this alternate behavior, 
> > but probably didn't realize the PF doesn't work in this mode.
> > 
> > This bimodal behavior is confusing to users and results in a state 
> > where the PF is broken for other uses unless the user sets 
> > sriov_numvfs to zero prior to unbinding the device.  Remove this 
> > behavior so that VFs are removed and the PF is functional for other 
> > uses after unbind, regardless of the way VFs are enabled.
> > 
> > Signed-off-by: Alex Williamson 
> > Cc: Greg Rose 
> > Cc: Jeff Kirsher 
> > ---
> > 
> > I can only think that not disabling SR-IOV was meant to enable some 
> > sort of persistence for VFs, but that's probably better accomplished 
> > with either udev rules and/or modprobe.d install scripts.
> > 
> >  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |7 +--
> >  1 file changed, 1 insertion(+), 6 deletions(-)
> > 
> > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > index 5be12a0..de04e3e 100644
> > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > @@ -8810,12 +8810,7 @@ static void ixgbe_remove(struct pci_dev *pdev)
> > unregister_netdev(netdev);
> > 
> >  #ifdef CONFIG_PCI_IOV
> > -   /*
> > -* Only disable SR-IOV on unload if the user specified the now
> > -* deprecated max_vfs module parameter.
> > -*/
> > -   if (max_vfs)
> > -   ixgbe_disable_sriov(adapter);
> > +   ixgbe_disable_sriov(adapter);
> >  #endif
> > ixgbe_clear_interrupt_scheme(adapter);
> > 
> 
> Please remove max_vfs module parameter - it is deprecated and should be 
> removed from upstream builds.  Dave let us get away with a kernel module a 
> few years ago because the other necessary infrastructure to enable SR-IOV 
> virtual functions via the PCIe interface was not available.  Now that it's 
> there it should be removed and vendors/end users should be forced to move 
> away from this.

I can't really say I'm in favor of removing that option.  It's probably going 
to break a lot of people because doing the udev rules right is hard.  The sysfs 
sriov interface has been tossed over the wall as the right way to do things, 
but there's really no infrastructure to facilitate even the simple peanut 
butter, everybody gets the same number of VFs, interface that max_vfs provides. 
 I think the existence of this bug is probably a good indication that the sysfs 
interface has not really been adopted yet.  Thanks,

Alex

___
Intel-wired-lan mailing list
intel-wired-...@lists.osuosl.org
http://lists.osuosl.org/mailman/listinfo/intel-wired-lan


Tested-By: Krishneil Singh 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [Intel-wired-lan] [PATCH] ixgbe: Remove bimodal SR-IOV disabling

2015-09-03 Thread Singh, Krishneil K 
-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On 
Behalf Of Alex Williamson
Sent: Friday, July 10, 2015 3:44 PM
To: Rose, Gregory V 
Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; 
linux-kernel@vger.kernel.org
Subject: Re: [Intel-wired-lan] [PATCH] ixgbe: Remove bimodal SR-IOV disabling

On Fri, 2015-07-10 at 21:36 +, Rose, Gregory V wrote:
> 
> > -Original Message-
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Friday, July 10, 2015 2:32 PM
> > To: intel-wired-...@lists.osuosl.org; Kirsher, Jeffrey T
> > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; Rose, 
> > Gregory V
> > Subject: [PATCH] ixgbe: Remove bimodal SR-IOV disabling
> > 
> > When unbinding an SR-IOV device with VFs configured from ixgbe, the 
> > driver behaves in one of two ways.  If max_vfs was specified, the 
> > SR-IOV state is disabled, removing the VFs.  The occurs regardless 
> > of whether the VF count was later modified through sysfs.  If 
> > however max_vfs is zero, such as by not specifying the module 
> > parameter, the VFs persist after the PF is unbound from ixgbe.  If 
> > the PF is then bound to vfio-pci to be assigned to a VM, the PF is 
> > non-functional.
> > 
> > >From the comment, commit da36b64736cf ("ixgbe: Implement PCI SR-IOV
> > sysfs callback operation") clearly intended this alternate behavior, 
> > but probably didn't realize the PF doesn't work in this mode.
> > 
> > This bimodal behavior is confusing to users and results in a state 
> > where the PF is broken for other uses unless the user sets 
> > sriov_numvfs to zero prior to unbinding the device.  Remove this 
> > behavior so that VFs are removed and the PF is functional for other 
> > uses after unbind, regardless of the way VFs are enabled.
> > 
> > Signed-off-by: Alex Williamson 
> > Cc: Greg Rose 
> > Cc: Jeff Kirsher 
> > ---
> > 
> > I can only think that not disabling SR-IOV was meant to enable some 
> > sort of persistence for VFs, but that's probably better accomplished 
> > with either udev rules and/or modprobe.d install scripts.
> > 
> >  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |7 +--
> >  1 file changed, 1 insertion(+), 6 deletions(-)
> > 
> > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > index 5be12a0..de04e3e 100644
> > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > @@ -8810,12 +8810,7 @@ static void ixgbe_remove(struct pci_dev *pdev)
> > unregister_netdev(netdev);
> > 
> >  #ifdef CONFIG_PCI_IOV
> > -   /*
> > -* Only disable SR-IOV on unload if the user specified the now
> > -* deprecated max_vfs module parameter.
> > -*/
> > -   if (max_vfs)
> > -   ixgbe_disable_sriov(adapter);
> > +   ixgbe_disable_sriov(adapter);
> >  #endif
> > ixgbe_clear_interrupt_scheme(adapter);
> > 
> 
> Please remove max_vfs module parameter - it is deprecated and should be 
> removed from upstream builds.  Dave let us get away with a kernel module a 
> few years ago because the other necessary infrastructure to enable SR-IOV 
> virtual functions via the PCIe interface was not available.  Now that it's 
> there it should be removed and vendors/end users should be forced to move 
> away from this.

I can't really say I'm in favor of removing that option.  It's probably going 
to break a lot of people because doing the udev rules right is hard.  The sysfs 
sriov interface has been tossed over the wall as the right way to do things, 
but there's really no infrastructure to facilitate even the simple peanut 
butter, everybody gets the same number of VFs, interface that max_vfs provides. 
 I think the existence of this bug is probably a good indication that the sysfs 
interface has not really been adopted yet.  Thanks,

Alex

___
Intel-wired-lan mailing list
intel-wired-...@lists.osuosl.org
http://lists.osuosl.org/mailman/listinfo/intel-wired-lan


Tested-By: Krishneil Singh 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [Intel-wired-lan] [PATCH 3/6] ethernet/ixgbe: advertise LRO support in vlan_features

2015-09-02 Thread Singh, Krishneil K 

-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On 
Behalf Of Jarod Wilson
Sent: Thursday, August 13, 2015 11:03 AM
To: linux-kernel@vger.kernel.org
Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; Jarod Wilson 

Subject: [Intel-wired-lan] [PATCH 3/6] ethernet/ixgbe: advertise LRO support in 
vlan_features

Without this, the presence of a ixgbe device in a bond will not trigger LRO 
support to be enabled at the bond level, even while it is enabled on the slave 
itself.

This change becomes necessary when NETIF_F_LRO is added to netdev_features.h's 
NETIF_F_ONE_FOR_ALL.

CC: Jeff Kirsher 
CC: intel-wired-...@lists.osuosl.org
CC: net...@vger.kernel.org
Signed-off-by: Jarod Wilson 
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 3e6a931..0a6e4e1 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -8659,8 +8659,10 @@ skip_sriov:
 
if (adapter->flags2 & IXGBE_FLAG2_RSC_CAPABLE)
netdev->hw_features |= NETIF_F_LRO;
-   if (adapter->flags2 & IXGBE_FLAG2_RSC_ENABLED)
+   if (adapter->flags2 & IXGBE_FLAG2_RSC_ENABLED) {
netdev->features |= NETIF_F_LRO;
+   netdev->vlan_features |= NETIF_F_LRO;
+   }
 
/* make sure the EEPROM is good */
if (hw->eeprom.ops.validate_checksum(hw, NULL) < 0) {
--
1.8.3.1

___
Intel-wired-lan mailing list
intel-wired-...@lists.osuosl.org
http://lists.osuosl.org/mailman/listinfo/intel-wired-lan

While Validating this patch we have run in to a call trace if we have 
forwarding  (net.ipv4.ip_forward = 1) and  LRO enabled on interface prior to 
creating VLAN interface. With the patch reverted we don't see this failure. 

Validation setup:

sysctl net.ipv4.ip_forward=1
ethtool -K ethX lro on
ip link set ethX up
ip link add link ethX name ethX.10 type vlan id 10.

CALL TRACE:

[582992.985245] ixgbe :83:00.0 eth6: NIC Link is Up 10 Gbps, Flow Control: 
RX/TX
[582992.985400] IPv6: ADDRCONF(NETDEV_CHANGE): eth6: link becomes ready
[582995.764828] ixgbe :83:00.1 eth7: NIC Link is Up 10 Gbps, Flow Control: 
RX/TX
[582995.764964] IPv6: ADDRCONF(NETDEV_CHANGE): eth7: link becomes ready
[583027.588991] ixgbe :04:00.0 eth2: NIC Link is Up 10 Gbps, Flow Control: 
RX/TX
[583044.365523] [ cut here ]
[583044.366181] WARNING: CPU: 20 PID: 56879 at net/core/dev.c:1472 
dev_disable_lro+0x95/0xa0()
[583044.366711] netdevice: eth2.10
failed to disable LRO!
[583044.367876] Modules linked in: ixgbe ixgb igb e100 mii e1000 e1000e 8021q 
garp mrp tcp_lp bnep bluetooth rfkill fuse btrfs xor raid6_pq vfat msdos fat 
ext4 mbcache jbd2 binfmt_misc xt_CHECKSUM iptable_mangle ipt_MASQUERADE 
nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 
nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 
iptable_filter ip_tables tun bridge stp llc x86_pkg_temp_thermal 
intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul 
crc32c_intel nfsd ghash_clmulni_intel mei_me aesni_intel mei lrw auth_rpcgss 
gf128mul shpchp iTCO_wdt ioatdma iTCO_vendor_support glue_helper nfs_acl 
ablk_helper lockd cryptd i2c_i801 lpc_ich mfd_core ipmi_si sb_edac edac_core 
grace dm_mirror dm_region_hash ipmi_msghandler pcspkr wmi dm_log dm_mod sunrpc 
uinput
[583044.371142]  xfs libcrc32c sr_mod cdrom sd_mod mgag200 syscopyarea 
sysfillrect sysimgblt drm_kms_helper ttm drm ahci libahci libata mdio vxlan 
firewire_ohci ip6_udp_tunnel firewire_core udp_tunnel ptp i2c_algo_bit pps_core 
i2c_core crc_itu_t dca [last unloaded: ixgbe]
[583044.372915] CPU: 20 PID: 56879 Comm: ip Tainted: GW IOE   
4.2.0-rc7-Ustream-8-26-15+ #1
[583044.373511] Hardware name: Intel Corporation S2600CO/S2600CO, BIOS 
SE5C600.86B.01.06.0001.090720121056 09/07/2012
[583044.374126]   e9a2d4dc 8803ce16b5b8 
8166b4e9
[583044.374752]   8803ce16b610 8803ce16b5f8 
8107b06a
[583044.375380]  8803ce16b608 880428041000 818dc1eb 
0005
[583044.376033] Call Trace:
[583044.376662]  [] dump_stack+0x45/0x57
[583044.377290]  [] warn_slowpath_common+0x8a/0xc0
[583044.377950]  [] warn_slowpath_fmt+0x55/0x70
[583044.378570]  [] ? netdev_update_features+0x25/0x60
[583044.379218]  [] dev_disable_lro+0x95/0xa0
[583044.379841]  [] inetdev_init+0x17d/0x230
[583044.380458]  [] inetdev_event+0x37f/0x4f0
[583044.381079]  [] notifier_call_chain+0x4d/0x80
[583044.381697]  [] raw_notifier_call_chain+0x16/0x20
[583044.382343]  [] call_netdevice_notifiers_info+0x39/0x70
[583044.382971]  [] register_netdevice+0x2ae/0x430
[583044.383595]  [] ? dev_get_nest_level+0x64/0xa0
[583044.384226]  []

RE: [Intel-wired-lan] [PATCH 3/6] ethernet/ixgbe: advertise LRO support in vlan_features

2015-09-02 Thread Singh, Krishneil K 

-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On 
Behalf Of Jarod Wilson
Sent: Thursday, August 13, 2015 11:03 AM
To: linux-kernel@vger.kernel.org
Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; Jarod Wilson 

Subject: [Intel-wired-lan] [PATCH 3/6] ethernet/ixgbe: advertise LRO support in 
vlan_features

Without this, the presence of a ixgbe device in a bond will not trigger LRO 
support to be enabled at the bond level, even while it is enabled on the slave 
itself.

This change becomes necessary when NETIF_F_LRO is added to netdev_features.h's 
NETIF_F_ONE_FOR_ALL.

CC: Jeff Kirsher 
CC: intel-wired-...@lists.osuosl.org
CC: net...@vger.kernel.org
Signed-off-by: Jarod Wilson 
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 3e6a931..0a6e4e1 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -8659,8 +8659,10 @@ skip_sriov:
 
if (adapter->flags2 & IXGBE_FLAG2_RSC_CAPABLE)
netdev->hw_features |= NETIF_F_LRO;
-   if (adapter->flags2 & IXGBE_FLAG2_RSC_ENABLED)
+   if (adapter->flags2 & IXGBE_FLAG2_RSC_ENABLED) {
netdev->features |= NETIF_F_LRO;
+   netdev->vlan_features |= NETIF_F_LRO;
+   }
 
/* make sure the EEPROM is good */
if (hw->eeprom.ops.validate_checksum(hw, NULL) < 0) {
--
1.8.3.1

___
Intel-wired-lan mailing list
intel-wired-...@lists.osuosl.org
http://lists.osuosl.org/mailman/listinfo/intel-wired-lan

While Validating this patch we have run in to a call trace if we have 
forwarding  (net.ipv4.ip_forward = 1) and  LRO enabled on interface prior to 
creating VLAN interface. With the patch reverted we don't see this failure. 

Validation setup:

sysctl net.ipv4.ip_forward=1
ethtool -K ethX lro on
ip link set ethX up
ip link add link ethX name ethX.10 type vlan id 10.

CALL TRACE:

[582992.985245] ixgbe :83:00.0 eth6: NIC Link is Up 10 Gbps, Flow Control: 
RX/TX
[582992.985400] IPv6: ADDRCONF(NETDEV_CHANGE): eth6: link becomes ready
[582995.764828] ixgbe :83:00.1 eth7: NIC Link is Up 10 Gbps, Flow Control: 
RX/TX
[582995.764964] IPv6: ADDRCONF(NETDEV_CHANGE): eth7: link becomes ready
[583027.588991] ixgbe :04:00.0 eth2: NIC Link is Up 10 Gbps, Flow Control: 
RX/TX
[583044.365523] [ cut here ]
[583044.366181] WARNING: CPU: 20 PID: 56879 at net/core/dev.c:1472 
dev_disable_lro+0x95/0xa0()
[583044.366711] netdevice: eth2.10
failed to disable LRO!
[583044.367876] Modules linked in: ixgbe ixgb igb e100 mii e1000 e1000e 8021q 
garp mrp tcp_lp bnep bluetooth rfkill fuse btrfs xor raid6_pq vfat msdos fat 
ext4 mbcache jbd2 binfmt_misc xt_CHECKSUM iptable_mangle ipt_MASQUERADE 
nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 
nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 
iptable_filter ip_tables tun bridge stp llc x86_pkg_temp_thermal 
intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul 
crc32c_intel nfsd ghash_clmulni_intel mei_me aesni_intel mei lrw auth_rpcgss 
gf128mul shpchp iTCO_wdt ioatdma iTCO_vendor_support glue_helper nfs_acl 
ablk_helper lockd cryptd i2c_i801 lpc_ich mfd_core ipmi_si sb_edac edac_core 
grace dm_mirror dm_region_hash ipmi_msghandler pcspkr wmi dm_log dm_mod sunrpc 
uinput
[583044.371142]  xfs libcrc32c sr_mod cdrom sd_mod mgag200 syscopyarea 
sysfillrect sysimgblt drm_kms_helper ttm drm ahci libahci libata mdio vxlan 
firewire_ohci ip6_udp_tunnel firewire_core udp_tunnel ptp i2c_algo_bit pps_core 
i2c_core crc_itu_t dca [last unloaded: ixgbe]
[583044.372915] CPU: 20 PID: 56879 Comm: ip Tainted: GW IOE   
4.2.0-rc7-Ustream-8-26-15+ #1
[583044.373511] Hardware name: Intel Corporation S2600CO/S2600CO, BIOS 
SE5C600.86B.01.06.0001.090720121056 09/07/2012
[583044.374126]   e9a2d4dc 8803ce16b5b8 
8166b4e9
[583044.374752]   8803ce16b610 8803ce16b5f8 
8107b06a
[583044.375380]  8803ce16b608 880428041000 818dc1eb 
0005
[583044.376033] Call Trace:
[583044.376662]  [] dump_stack+0x45/0x57
[583044.377290]  [] warn_slowpath_common+0x8a/0xc0
[583044.377950]  [] warn_slowpath_fmt+0x55/0x70
[583044.378570]  [] ? netdev_update_features+0x25/0x60
[583044.379218]  [] dev_disable_lro+0x95/0xa0
[583044.379841]  [] inetdev_init+0x17d/0x230
[583044.380458]  [] inetdev_event+0x37f/0x4f0
[583044.381079]  [] notifier_call_chain+0x4d/0x80
[583044.381697]  [] raw_notifier_call_chain+0x16/0x20
[583044.382343]  [] call_netdevice_notifiers_info+0x39/0x70
[583044.382971]  [] register_netdevice+0x2ae/0x430
[583044.383595]  [] ?

RE: [Intel-wired-lan] [PATCH 1/1] ixgbe: use kzalloc for allocating one thing

2015-09-01 Thread Singh, Krishneil K 

-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On 
Behalf Of Maninder Singh
Sent: Thursday, June 18, 2015 9:08 PM
To: Kirsher, Jeffrey T ; Brandeburg, Jesse 
; Nelson, Shannon ; 
Wyborny, Carolyn ; Skidmore, Donald C 
; Vick, Matthew ; Ronciak, 
John ; Williams, Mitch A ; 
intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; 
linux-kernel@vger.kernel.org
Cc: Maninder Singh ; panka...@samsung.com
Subject: [Intel-wired-lan] [PATCH 1/1] ixgbe: use kzalloc for allocating one 
thing

Use kzalloc rather than kcalloc(1..

The semantic patch that makes this change is as follows:

// 
@@
@@

- kcalloc(1,
+ kzalloc(
  ...)
// 

and removing checkpatch below CHECK:
CHECK: Prefer kzalloc(sizeof(*fwd_adapter)...) over kzalloc(sizeof(struct 
ixgbe_fwd_adapter)...)

Signed-off-by: Maninder Singh 
Reviewed-by: Vaneet Narang 
---
 
Tested-By: Krishneil Singh 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [Intel-wired-lan] [PATCH 1/1] ixgbe: use kzalloc for allocating one thing

2015-09-01 Thread Singh, Krishneil K 

-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On 
Behalf Of Maninder Singh
Sent: Thursday, June 18, 2015 9:08 PM
To: Kirsher, Jeffrey T ; Brandeburg, Jesse 
; Nelson, Shannon ; 
Wyborny, Carolyn ; Skidmore, Donald C 
; Vick, Matthew ; Ronciak, 
John ; Williams, Mitch A ; 
intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; 
linux-kernel@vger.kernel.org
Cc: Maninder Singh ; panka...@samsung.com
Subject: [Intel-wired-lan] [PATCH 1/1] ixgbe: use kzalloc for allocating one 
thing

Use kzalloc rather than kcalloc(1..

The semantic patch that makes this change is as follows:

// 
@@
@@

- kcalloc(1,
+ kzalloc(
  ...)
// 

and removing checkpatch below CHECK:
CHECK: Prefer kzalloc(sizeof(*fwd_adapter)...) over kzalloc(sizeof(struct 
ixgbe_fwd_adapter)...)

Signed-off-by: Maninder Singh 
Reviewed-by: Vaneet Narang 
---
 
Tested-By: Krishneil Singh 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/