RE: [Intel-wired-lan] [PATCH] fm10k: mark PM functions as __maybe_unused
> -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 ; netdev@vger.kernel.org;
> Florian Westphal ; linux-ker...@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; netdev@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 = &fm10k_pm_ops,
> > },
> > -#endif /* CONFIG_PM */
> > .sriov_configure= fm10k_iov_configure,
> > .err_handler= &fm10k_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()
> -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: netdev@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()
> -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; netdev@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
-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: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux-ker...@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
-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 ; netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux-ker...@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
-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-ker...@vger.kernel.org; intel-wired-...@lists.osuosl.org; netdev@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 netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Intel-wired-lan] [PATCH] fm10k:Fix error handling in the function fm10k_setup_tc
-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-ker...@vger.kernel.org; intel-wired-...@lists.osuosl.org; netdev@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 netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Intel-wired-lan] [PATCH] fm10k:Fix error handling in the function fm10k_setup_tc for certain function calls
-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-ker...@vger.kernel.org; intel-wired-...@lists.osuosl.org; netdev@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 netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Intel-wired-lan] [PATCH 3/3] fm10k: use napi_schedule_irqoff()
-Original Message- From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On Behalf Of Alexander Duyck Sent: Tuesday, September 29, 2015 3:20 PM To: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org Subject: [Intel-wired-lan] [PATCH 3/3] fm10k: use napi_schedule_irqoff() The fm10k_msix_clean_rings function runs from hard interrupt context or with interrupts already disabled in netpoll. It can use napi_schedule_irqoff() instead of napi_schedule() Signed-off-by: Alexander Duyck --- Tested-by: Krishneil Singh -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Intel-wired-lan] [net PATCH 2/3] fm10k: Fix handling of napi budget when multiple queues are enabled per vector
-Original Message- From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On Behalf Of Alexander Duyck Sent: Tuesday, September 22, 2015 2:36 PM To: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org Subject: [Intel-wired-lan] [net PATCH 2/3] fm10k: Fix handling of napi budget when multiple queues are enabled per vector This patch corrects an issue in which the polling routine would increase the budget for Rx to at least 1 per queue if multiple queues were present. This would result in Rx packets being processed when the budget was 0 which is meant to indicate that no Rx can be handled. Signed-off-by: Alexander Duyck --- Tested-by: Krishneil Singh -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Intel-wired-lan] [PATCH v8 3/3] ixgbe, ixgbevf: Add new mbox API xcast mode
-Original Message- From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On Behalf Of Hiroshi Shimamoto Sent: Thursday, August 27, 2015 11:59 PM To: Or Gerlitz ; Alexander Duyck ; Skidmore, Donald C ; Rose, Gregory V ; Kirsher, Jeffrey T ; intel-wired-...@lists.osuosl.org; nhor...@redhat.com; jogre...@redhat.com; Linux Netdev List ; Choi, Sy Jong ; Rony Efraim ; Edward Cree ; David Miller ; sassm...@redhat.com Subject: [Intel-wired-lan] [PATCH v8 3/3] ixgbe, ixgbevf: Add new mbox API xcast mode From: Hiroshi Shimamoto 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 30 IPv6 addresses to a single VF. This patch introduces the new mailbox API, IXGBE_VF_UPDATE_XCAST_MODE, to update multicast mode of VF. This adds 3 modes; - NONE only L2 exact match addresses or Flow Director enabled - MULTIBAM and ROMPE set - ALLMULTI BAM, ROMPE and MPE set If a guest VF user wants over 30 MAC multicast addresses, set IFF_ALLMULTI to request PF to update xcast mode to enable VF multicast promiscuous mode. On the other hand, enabling VF multicast promiscuous mode may affect security and performance in the network of the NIC. Only trusted VF can enable multicast promiscuous mode. The behavior of untrusted VF is the same as previous version. Signed-off-by: Hiroshi Shimamoto --- Tested-by: Krishneil Singh -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v8 2/3] ixgbe: Add new ndo to trust VF
-Original Message- From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On Behalf Of Hiroshi Shimamoto Sent: Thursday, August 27, 2015 11:59 PM To: Or Gerlitz ; Alexander Duyck ; Skidmore, Donald C ; Rose, Gregory V ; Kirsher, Jeffrey T ; intel-wired-...@lists.osuosl.org; nhor...@redhat.com; jogre...@redhat.com; Linux Netdev List ; Choi, Sy Jong ; Rony Efraim ; Edward Cree ; David Miller ; sassm...@redhat.com Subject: [Intel-wired-lan] [PATCH v8 2/3] ixgbe: Add new ndo to trust VF From: Hiroshi Shimamoto Implements the new netdev op to trust VF in ixgbe. The administrator can turn on and off VF trusted by ip command which supports trust message. # ip link set dev eth0 vf 1 trust on or # ip link set dev eth0 vf 1 trust off Send a ping to reset VF on changing the status of trusting. VF driver will reconfigure its features on reset. Signed-off-by: Hiroshi Shimamoto --- Tested-by: Krishneil Singh -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v8 1/3] if_link: Add control trust VF
-Original Message- From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On Behalf Of Hiroshi Shimamoto Sent: Thursday, August 27, 2015 11:58 PM To: Or Gerlitz ; Alexander Duyck ; Skidmore, Donald C ; Rose, Gregory V ; Kirsher, Jeffrey T ; intel-wired-...@lists.osuosl.org; nhor...@redhat.com; jogre...@redhat.com; Linux Netdev List ; Choi, Sy Jong ; Rony Efraim ; Edward Cree ; David Miller ; sassm...@redhat.com Subject: [Intel-wired-lan] [PATCH v8 1/3] if_link: Add control trust VF From: Hiroshi Shimamoto Add netlink directives and ndo entry to trust VF user. This controls the special permission of VF user. The administrator will dedicatedly trust VF user to use some features which impacts security and/or performance. The administrator never turn it on unless VF user is fully trusted. Signed-off-by: Hiroshi Shimamoto CC: Choi, Sy Jong --- Tested-by: Krishneil Singh -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Intel-wired-lan] [PATCH] ixgbe: Limit lowest interrupt rate for adaptive interrupt moderation to 12K
-Original Message- From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On Behalf Of Jeff Kirsher Sent: Wednesday, September 2, 2015 3:07 AM To: Alexander Duyck Cc: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org Subject: Re: [Intel-wired-lan] [PATCH] ixgbe: Limit lowest interrupt rate for adaptive interrupt moderation to 12K On Tue, 2015-09-01 at 18:49 -0700, Alexander Duyck wrote: > On 07/30/2015 03:19 PM, Alexander Duyck wrote: > > This patch updates the lowest limit for adaptive interrupt interrupt > > moderation to roughly 12K interrupts per second. > > > > The way I came about reaching 12K as the desired interrupt rate is > by > > testing with UDP flows. Specifically I had a simple test that ran a > > netperf UDP_STREAM test at varying sizes. What I found was as the > packet > > sizes increased the performance fell steadily behind until we were > only > > able to receive at ~4Gb/s with a message size of 65507. A bit of > digging > > found that we were dropping packets for the socket in the network > stack, > > and looking at things further what I found was I could solve it by > increasing > > the interrupt rate, or increasing the rmem_default/rmem_max. What I > found was > > that when the interrupt coalescing resulted in more data being > processed > > per interrupt than could be stored in the socket buffer we started > losing > > packets and the performance dropped. So I reached 12K based on the > > following math. > > > > rmem_default = 212992 > > skb->truesize = 2994 > > 212992 / 2994 = 71.14 packets to fill the buffer > > > > packet rate at 1514 packet size is 812744pps > > 71.14 / 812744 = 87.9us to fill socket buffer > > > > >From there it was just a matter of choosing the interrupt rate and > > providing a bit of wiggle room which is why I decided to go with 12K > > interrupts per second as that uses a value of 84us. > > > > The data below is based on VM to VM over a direct assigned ixgbe > interface. > > The test run was: > > netperf -H -t UDP_STREAM" > > > > Socket Message Elapsed Messages CPU > Service > > SizeSize Time Okay Errors Throughput Util > Demand > > bytes bytessecs# # 10^6bits/sec % SS > us/KB > > Before: > > 212992 65507 60.00 1100662 0 9613.4 10.89 > 0.557 > > 212992 60.00 4734744135.4 11.27 > 0.576 > > > > After: > > 212992 65507 60.00 1100413 0 9611.2 10.73 > 0.549 > > 212992 60.00 9741328508.3 11.69 > 0.598 > > > > Using bare metal the data is similar but not as dramatic as the > throughput > > increases from about 8.5Gb/s to 9.5Gb/s. > > > > Signed-off-by: Alexander Duyck > > Has there been any update on this patch? I submitted it just over a > month ago now and it hasn't received any feedback. I was hoping this > could be submitted before the merge window closes for net-next. It will be in the next series I push later today. Tested-by: Krishneil Singh
RE: [Intel-wired-lan] [PATCH] ixgbe: Remove bimodal SR-IOV disabling
-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: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org;
linux-ker...@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: netdev@vger.kernel.org; linux-ker...@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 netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Intel-wired-lan] [PATCH 3/6] ethernet/ixgbe: advertise LRO support in vlan_features
-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-ker...@vger.kernel.org
Cc: netdev@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: netdev@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] [] register_vlan_dev+0xd
RE: [Intel-wired-lan] [PATCH 1/1] ixgbe: use kzalloc for allocating one thing
-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; netdev@vger.kernel.org; linux-ker...@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 netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Intel-wired-lan] [PATCH v2] fm10k: Report MAC address on driver load
-Original Message- From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On Behalf Of Alexander Duyck Sent: Thursday, June 18, 2015 7:41 PM To: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; Kirsher, Jeffrey T Subject: [Intel-wired-lan] [PATCH v2] fm10k: Report MAC address on driver load This change adds the MAC address to the list of values recorded on driver load. The MAC address represents the serial number of the unit and allows us to track the value should a card be replaced in a system. The log message should now be similar in output to that of ixgbe. Signed-off-by: Alexander Duyck --- Tested-By: Krishneil Singh ___ Intel-wired-lan mailing list intel-wired-...@lists.osuosl.org http://lists.osuosl.org/mailman/listinfo/intel-wired-lan -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Intel-wired-lan] [PATCH] fm10k: Don't assume page fragments are page size
-Original Message- From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On Behalf Of Alexander Duyck Sent: Tuesday, June 16, 2015 11:47 AM To: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; Kirsher, Jeffrey T Subject: [Intel-wired-lan] [PATCH] fm10k: Don't assume page fragments are page size This change pulls out the optimization that assumed that all fragments would be limited to page size. That hasn't been the case for some time now and to assume this is incorrect as the TCP allocator can provide up to a 32K page fragment. Signed-off-by: Alexander Duyck --- Tested-By: Krishneil Singh ___ Intel-wired-lan mailing list intel-wired-...@lists.osuosl.org http://lists.osuosl.org/mailman/listinfo/intel-wired-lan -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
