Re: [E1000-devel] [net] Intel Wired LAN Driver Updates
From: Jeff Kirsher jeffrey.t.kirs...@intel.com Date: Tue, 31 Mar 2015 21:27:53 -0700 On Tue, 2015-03-31 at 19:19 -0700, Jeff Kirsher wrote: On Tue, 2015-03-31 at 13:22 -0400, David Miller wrote: From: Jeff Kirsher jeffrey.t.kirs...@intel.com Date: Fri, 27 Mar 2015 16:04:10 -0700 The following are changes since commit dde93dfea53c72b07907d9e44a6e4b1545f6bdc4: cxgb4: Fix frame size warning for 32 bit arch and are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue master Jeff Kirsher (1): MAINTAINERS: Update Intel Wired Ethernet Driver info Looks great but it looks like nothing is pushed there? [davem@localhost net]$ git pull git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue master From git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue * branchmaster - FETCH_HEAD Already up-to-date. [davem@localhost net]$ Sorry, I forgot to scrub the cover letter to remove the pull info, since it was a single patch, I did not think it would require a pull. :-) I can apply it to my net-queue tree, master branch if you need or want. I have gone ahead and pushed the patch to my net-queue tree for you to pull. Pulled, thanks Jeff. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [net] Intel Wired LAN Driver Updates
From: Jeff Kirsher jeffrey.t.kirs...@intel.com Date: Fri, 27 Mar 2015 16:04:10 -0700 The following are changes since commit dde93dfea53c72b07907d9e44a6e4b1545f6bdc4: cxgb4: Fix frame size warning for 32 bit arch and are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue master Jeff Kirsher (1): MAINTAINERS: Update Intel Wired Ethernet Driver info Looks great but it looks like nothing is pushed there? [davem@localhost net]$ git pull git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue master From git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue * branchmaster - FETCH_HEAD Already up-to-date. [davem@localhost net]$ -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net-next] ethernet: Use bool function returns of true/false instead of 1/0
From: Joe Perches j...@perches.com Date: Sun, 29 Mar 2015 18:25:12 -0700 Use bool constants as the return values instead of 1 and 0. Signed-off-by: Joe Perches j...@perches.com Applied, thanks Joe. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH v2 net-next 0/7] Stacked vlan TSO
From: Toshiaki Makita makita.toshi...@lab.ntt.co.jp Date: Fri, 27 Mar 2015 14:31:09 +0900 On the basis of Netdev 0.1 discussion[1], I made a patch set to enable TSO for packets with multiple vlans. Series applied, thank you. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net 0/4] Fix checksum error when using stacked vlan
From: Toshiaki Makita makita.toshi...@lab.ntt.co.jp Date: Thu, 29 Jan 2015 20:37:06 +0900 When I was testing 802.1ad, I found several drivers don't take into account 802.1ad or multiple vlans when retrieving L3 (IP/IPv6) or L4 (TCP/UDP) protocol for checksum offload. It is mainly due to vlan_get_protocol(), which extracts ether type only when it is tagged with single 802.1Q. When 802.1ad is used or there are multiple vlans, it extracts vlan protocol and drivers cannot determine which L3/L4 protocol is used. Those drivers, most of which have IP_CSUM/IPV6_CSUM features, get L3/L4 header-offset by software, so it seems that their checksum offload works with multiple vlans if we can parse protocols correctly. (They know mac header length, and probably don't care about what is in it.) And another thing, some of Intel's drivers seem to use skb-protocol where vlan_get_protocol() is more suitable. I tested that at least igb/igbvf on I350 works with this patch set. Note: We can hand a double tagged packet with CHECKSUM_PARTIAL to a HW driver by creating a vlan device on a bridge device and enabling vlan_filtering of the bridge with 802.1ad protocol. Series applied, thank you. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH] igb in linux-3.18.0: some potential bugs
From: Jia-Ju Bai baijiaju1...@163.com Date: Sat, 20 Dec 2014 20:59:18 +0800 Thank for the reply! Please do not top-post. Etiquette on these mailing lists is that you quote a minimal amount of material from the email you are replying to to give enough context to the reader, than you give your response _after_ the quoted material, not before. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH] e100 in linux-3.18.0: some potential bugs
Your patch submissions are not usable by us. Instead of immediately sending your patch 10 seconds after you receive feedback, take your time and make sure you do everything calmly and cleanly and as tidy as possible. There is absolutely no rush with these changes. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] ixgbe/linux/sparc perf issues
From: Sowmini Varadhan sowmini.varad...@oracle.com Date: Thu, 11 Dec 2014 14:45:42 -0500 1. lockstat and perf report that iommu-lock is the hot-lock (in a typical instance, I get about 21M contentions out of 27M acquisitions, 25 us avg wait time). Even if I fix this issue (see below), I see: The real overhead is unavoidable due to the way the hypervisor access to the IOMMU is implemented in sun4v. If we had direct access to the hardware, we could avoid all of the real overhead in %99 of all IOMMU mappings, as we do for pre-sun4v systems. On sun4u systems, we never flush the IOMMU until we wrap around the end of the IOMMU arena to the beginning in order to service an allocation. Such an optimization is impossible with the hypervisor call interface in sun4v. I've known about this issue for a decade and I do not think there is anything we can really do about this. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] ixgbe/linux/sparc perf issues
From: Sowmini Varadhan sowmini.varad...@oracle.com Date: Thu, 11 Dec 2014 15:21:00 -0500 All this may be true, but it would also be true for Solaris, which manages to do line-speed (for the exact same setup), so there must be some other bottleneck going on? They have DMA mapping interfaces which pre-allocate large batches of mapping at a time. And fwiw, removing the iommu lock contention out of lockstat did not make any difference to the throughput, which seems to indicate that the bottleneck is elsewhere. Like I said, it's in the hypervisor IOMMU interfaces implementing the hardware accesses to flush the hardware and adjust the DMA mappings. The lock just shows because the overhead bubbles up to the closest non-hypervisor code. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] ixgbe/linux/sparc perf issues
From: David Miller da...@davemloft.net Date: Thu, 11 Dec 2014 15:24:17 -0500 (EST) From: Sowmini Varadhan sowmini.varad...@oracle.com Date: Thu, 11 Dec 2014 15:21:00 -0500 All this may be true, but it would also be true for Solaris, which manages to do line-speed (for the exact same setup), so there must be some other bottleneck going on? They have DMA mapping interfaces which pre-allocate large batches of mapping at a time. BTW, Solaris also does things which are remotely exploitable, so these optimizations that get them line rate have a serious cost. In their NIU driver, the recycle all buffers in an RX queue rather than allocating new buffers. This means that a maliciously running TCP application can read a lot of data from a bulk sender, then simply stop reading completely. This will put the entire RX queue of packets in limbo in the TCP stack, which will never be recycled back to the NIU driver, thus stalling all traffic completely which steers to that RX queue. So that, is how Solaris gets line rate with this kind of hardware. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH] e100: Don't enable WoL by default on Toshiba devices
From: Ondrej Zary li...@rainbow-software.org Date: Wed, 12 Nov 2014 23:47:25 +0100 Enabling WoL on some Toshiba laptops (such as Portege R100) causes battery drain after shutdown (WoL is active even on battery). These laptops have the WoL bit set in EEPROM ID, causing e100 driver to enable WoL by default. Check subsystem vendor ID and if it's Toshiba, don't enable WoL by default from EEPROM settings. Fixes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/110784 Signed-off-by: Ondrej Zary li...@rainbow-software.org Jeff, are you gonna pick this up? -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATHC] net: napi_reuse_skb() should check pfmemalloc
From: Eric Dumazet eric.duma...@gmail.com Date: Thu, 23 Oct 2014 06:30:30 -0700 From: Eric Dumazet eduma...@google.com Do not reuse skb if it was pfmemalloc tainted, otherwise future frame might be dropped anyway. Signed-off-by: Eric Dumazet eduma...@google.com Applied, thanks Eric. -- ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH v2] fm10k: Add skb-xmit_more support
From: Jeff Kirsher jeffrey.t.kirs...@intel.com Date: Sat, 11 Oct 2014 04:14:43 -0700 On Fri, 2014-10-10 at 14:30 -0700, alexander.du...@gmail.com wrote: From: Alexander Duyck alexander.h.du...@redhat.com This change adds support for skb-xmit_more based on the changes that were made to igb to support the feature. The main changes are moving up the check for maybe_stop_tx so that we can check netif_xmit_stopped to determine if we must write the tail because we can add no further buffers. Acked-by: Matthew Vick matthew.v...@intel.com Signed-off-by: Alexander Duyck alexander.h.du...@redhat.com --- v2: Minor fix to patch description for typo. drivers/net/ethernet/intel/fm10k/fm10k_main.c | 65 + 1 file changed, 34 insertions(+), 31 deletions(-) Acked-by: Jeff Kirsher jeffrey.t.kirs...@intel.com Its like you never left Intel Alex... :-) Dave, please pull this. Applied, thanks everyone. -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH] networking: fm10k: Fix build failure
From: Pranith Kumar bobby.pr...@gmail.com Date: Fri, 10 Oct 2014 00:55:29 -0400 The latest linus git tip (3.18-rc1) fails with the following build failure. Fix this by making PTP support explicit for fm10k driver. rivers/built-in.o: In function `fm10k_ptp_register': (.text+0x12e760): undefined reference to `ptp_clock_registER' drivers/built-in.o: In function `fm10k_ptp_unregister': (.text+0x12e7dc): undefined reference to `ptp_clock_unregister' Makefile:930: recipe for target 'vmlinux' failed Signed-off-by: Pranith Kumar bobby.pr...@gmail.com Please follow what other drivers do, which is to use select on this Kconfig symbol. Thanks. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH v2] networking: fm10k: Fix build failure
From: Pranith Kumar bobby.pr...@gmail.com Date: Fri, 10 Oct 2014 01:19:06 -0400 The latest linus git tip (3.18-rc1) fails with the following build failure. Fix this by making PTP support explicit for fm10k driver. rivers/built-in.o: In function `fm10k_ptp_register': (.text+0x12e760): undefined reference to `ptp_clock_registER' drivers/built-in.o: In function `fm10k_ptp_unregister': (.text+0x12e7dc): undefined reference to `ptp_clock_unregister' Makefile:930: recipe for target 'vmlinux' failed Signed-off-by: Pranith Kumar bobby.pr...@gmail.com Applied, thanks. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH v2 0/8] Fix TSO and checksum issues with non-accelerated vlan traffic.
From: Vladislav Yasevich vyasev...@gmail.com Date: Mon, 25 Aug 2014 10:34:47 -0400 I've recently ran across something rather interesting when testing vlans from inside VMs. In some scenarios I was getting awfull thruput. Some debugging uncovered a very scary packet corruption. I was seeing packets that had original TSO length as IP total length and their ip checksum was 0. This was with e1000e driver. A bit more debugging uncovered an assumption made by that driver that skb-protocol will contain l3 protocol information. This was not the case in my setup since I manually turned off vlan tx acceleration for the device. This caused the driver to not initialize the tso information correctly and resulted in corrupt TSO frames on the wire. I decided to do some auditing of the usage of skb-protocols in the drivers. Out of all the drivers, the included 8 appear to be effected. They all allow user to control vlan acceleration settings, all support TSO on vlan devices, and all use skb-protocol to decide how to encode TSO information. Some also have similar problems when initializing hw checksum information. On such device, it is simple enough to reproduce the issue. Simply turn off TX VLAN acceleration on the device, create a vlan, and run you favorite network performance tool. There is 1 driver I ran across that I belive will trigger a BUG in the system when used with vlans. That driver is tile/tilepro.c I have not changed it in this patch set and would hope that the maintainer has time to look at it. V2: Fix i40ev using the wrong function name. Full build. Applied, thanks. -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH 5/8] i40e: Fix TSO and hw checksums for non-accelerated vlan packets.
From: vyasev...@gmail.com Date: Fri, 22 Aug 2014 22:17:07 -0400 @@ -2295,7 +2295,7 @@ static netdev_tx_t i40e_xmit_frame_ring(struct sk_buff *skb, goto out_drop; /* obtain protocol of skb */ - protocol = skb-protocol; + protocol = get_vlan_protocol(skb); I don't think this even compiles. It's vlan_get_protocol not get_vlan_protocol. -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [linux-nics] linux-next: Tree for Aug 11 (net/ethernet/intel/i40e)
From: Jeff Kirsher jeffrey.t.kirs...@intel.com Date: Mon, 11 Aug 2014 12:53:06 -0700 On Mon, 2014-08-11 at 09:17 -0700, Randy Dunlap wrote: On 08/10/14 22:52, Stephen Rothwell wrote: Hi all, Please do not add code intended for v3.18 until after v3.17-rc1 is released. Changes since 20140808: on i386 and x86_64: ../drivers/net/ethernet/intel/i40e/i40e_fcoe.c: In function 'i40e_get_fcoe_tc_map': ../drivers/net/ethernet/intel/i40e/i40e_fcoe.c:354:23: error: 'IEEE_8021QAZ_APP_SEL_ETHERTYPE' undeclared (first use in this function) if (app.selector == IEEE_8021QAZ_APP_SEL_ETHERTYPE Needs to #include uapi/linux/dcbnl.h ?? Yeah, Dave has already accepted a patch to resolve that, which I believe went into his net tree. I see no such change in my tree. -- ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [linux-nics] linux-next: Tree for Aug 11 (net/ethernet/intel/i40e)
From: Jeff Kirsher jeffrey.t.kirs...@intel.com Date: Mon, 11 Aug 2014 15:16:32 -0700 On Mon, 2014-08-11 at 14:54 -0700, David Miller wrote: I see no such change in my tree. http://patchwork.ozlabs.org/patch/376699/ This is what I was referring to, it looks like you set the patch status to Awaiting upstream yet you responded that you applied it. So my bad, I thought you had already sucked it into you tree. I get this resolved and send you this and a few other fixes later today. My bad, I mis-replied to that patch, and indeed I do expect to get it upstream via your tree. Thanks for catching that Jeff. -- ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH] drivers: net: ethernet: intel: i40e: Fix missing uapi/linux/dcbnl.h include in i40e_fcoe.c
From: Lucas Tanure tan...@linux.com Date: Tue, 5 Aug 2014 10:11:43 -0300 Fix missing include in intel i40e driver. Without this include linux next tree won't compile. Signed-off-by: Lucas Tanure tan...@linux.com Applied, thank you. -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH 3/9] i40e: use correct structure type name in sizeof
From: Julia Lawall julia.law...@lip6.fr Date: Tue, 29 Jul 2014 17:16:45 +0200 From: Julia Lawall julia.law...@lip6.fr Correct typo in the name of the type given to sizeof. Because it is the size of a pointer that is wanted, the typo has no impact on compilation or execution. This problem was found using Coccinelle (http://coccinelle.lip6.fr/). The semantic patch used can be found in message 0 of this patch series. Signed-off-by: Julia Lawall julia.law...@lip6.fr I'll let the Intel driver folks pick this one up, thanks! -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH 0/25] Replace DEFINE_PCI_DEVICE_TABLE macro use
From: Benoit Taine benoit.ta...@lip6.fr Date: Fri, 18 Jul 2014 17:26:47 +0200 We should prefer `const struct pci_device_id` over `DEFINE_PCI_DEVICE_TABLE` to meet kernel coding style guidelines. This issue was reported by checkpatch. A simplified version of the semantic patch that makes this change is as follows (http://coccinelle.lip6.fr/): // smpl @@ identifier i; declarer name DEFINE_PCI_DEVICE_TABLE; initializer z; @@ - DEFINE_PCI_DEVICE_TABLE(i) + const struct pci_device_id i[] = z; // /smpl I have 103 patches ready, and will only send a few for you to judge if it is useful enough, and to prevent from spamming too much. I'm fine with this wrt. the networking changes, but I don't think this should be merged via my tree. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH 00/30] drivers/net: remove unnecessary break after return
From: Fabian Frederick f...@skynet.be Date: Sun, 20 Jul 2014 16:16:08 +0200 Second patchset after remove unnecessary break after goto addressing break redundancy on drivers/net branch (suggested by Joe Perches) All applied except the i40e patch, which did not apply to net-next at all. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH V2 0/9] drivers/net: remove unnecessary break after goto
From: Fabian Frederick f...@skynet.be Date: Sat, 12 Jul 2014 20:09:39 +0200 Small patchset addressing break redundancy on drivers/net branch (suggested by Joe Perches). V2: cc to maintainers of each section. Series applied to net-next, thanks. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck#174; Code Sight#153; - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH] e1000: Use time_after() for time comparison
From: Manuel Schölling manuel.schoell...@gmx.de Date: Thu, 22 May 2014 22:21:30 +0200 To be future-proof and for better readability the time comparisons are modified to use time_after() instead of plain, error-prone math. Signed-off-by: Manuel Schölling manuel.schoell...@gmx.de I'll let Jeff pick this up in his tree. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net-next] e1000: Use is_broadcast_ether_addr/is_multicast_ether_addr helpers
From: Tobias Klauser tklau...@distanz.ch Date: Fri, 16 May 2014 10:00:38 +0200 Use the is_broadcast_ether_addr/is_multicast_ether_addr helper functions from linux/etherdevice.h instead of open coding them. Signed-off-by: Tobias Klauser tklau...@distanz.ch I'll let Jeff Kirsher take this via his tree. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net-next] i40evf: Use is_multicast_ether_addr helper
From: Tobias Klauser tklau...@distanz.ch Date: Fri, 16 May 2014 10:00:34 +0200 Use the is_multicast_ether_addr helper function from linux/etherdevice.h instead of open coding the multicast address check. Signed-off-by: Tobias Klauser tklau...@distanz.ch Likewise, I'll let Jeff Kirsher take this via his tree. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH] [resend] net: get rid of SET_ETHTOOL_OPS
From: Wilfried Klaebe w-l...@lebenslange-mailadresse.de Date: Sun, 11 May 2014 00:12:32 + net: get rid of SET_ETHTOOL_OPS Dave Miller mentioned he'd like to see SET_ETHTOOL_OPS gone. This does that. Mostly done via coccinelle script: @@ struct ethtool_ops *ops; struct net_device *dev; @@ - SET_ETHTOOL_OPS(dev, ops); + dev-ethtool_ops = ops; Compile tested only, but I'd seriously wonder if this broke anything. Suggested-by: Dave Miller da...@davemloft.net Signed-off-by: Wilfried Klaebe w-l...@lebenslange-mailadresse.de Applied to net-next, thanks. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] fail to add 64 VLANs or more when SR-IOV is enabled
From: Madoka Komatsubara m-komatsub...@ab.jp.nec.com Date: Thu, 3 Apr 2014 01:12:13 + Thank you for the quick response. How can I increase the limit？ It's a hardware limit, you cannot increase it. -- ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net-next 5/9] ixgbe: Convert uses of __constant_foo to foo
From: Joe Perches j...@perches.com Date: Wed, 12 Mar 2014 10:22:34 -0700 The use of __constant_foo has been unnecessary for quite awhile now. Make these uses consistent with the rest of the kernel. Signed-off-by: Joe Perches j...@perches.com Will let the Intel folks pick this up. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net-next 6/9] ixgbevf: Convert uses of __constant_foo to foo
From: Joe Perches j...@perches.com Date: Wed, 12 Mar 2014 10:22:35 -0700 The use of __constant_foo has been unnecessary for quite awhile now. Make these uses consistent with the rest of the kernel. Signed-off-by: Joe Perches j...@perches.com Will let the Intel folks pick this up. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net-next 4/9] igbvf: Convert uses of __constant_foo to foo
From: Joe Perches j...@perches.com Date: Wed, 12 Mar 2014 10:22:33 -0700 The use of __constant_foo has been unnecessary for quite awhile now. Make these uses consistent with the rest of the kernel. Signed-off-by: Joe Perches j...@perches.com Will let the Intel folks pick this up. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net-next 2/9] e100: Convert uses of __constant_foo to foo
From: Joe Perches j...@perches.com Date: Wed, 12 Mar 2014 10:22:31 -0700 The use of __constant_foo has been unnecessary for quite awhile now. Make these uses consistent with the rest of the kernel. Signed-off-by: Joe Perches j...@perches.com Will let the Intel folks pick this up. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net-next 3/9] igb: Convert uses of __constant_foo to foo
From: Joe Perches j...@perches.com Date: Wed, 12 Mar 2014 10:22:32 -0700 The use of __constant_foo has been unnecessary for quite awhile now. Make these uses consistent with the rest of the kernel. Signed-off-by: Joe Perches j...@perches.com Will let the Intel folks pick this up. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH] e1000: do not allow watchdog to reenable transmits on shutdown
From: Marcelo Tosatti mtosa...@redhat.com Date: Fri, 7 Mar 2014 12:14:35 -0300 checkpatch.pl did not complain about those - feel free to fix them, thanks. The problem is that GIT does when the maintainer applies your patch. You can sanity check your patch using GIT without commiting it into the tree you are using by saying something like: git apply --check --whitespace=error-all $1 -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net-next] ixgbevf: fix skb-pkt_type checks
From: Florian Fainelli f.faine...@gmail.com Date: Wed, 26 Feb 2014 14:44:00 -0800 skb-pkt_type is not a bitmask, but contains only value at a time from the range defined in include/uapi/linux/if_packet.h. Checking it like if it was a bitmask of values would also cause PACKET_OTHERHOST, PACKET_LOOPBACK and PACKET_FASTROUTE to be matched by this check since their lower 2 bits are also set, although that does not fix a real bug due to how the checks are used, it is still potentially confusing. This bogus check was introduced in commit 815cccbf (ixgbe: add setlink, getlink support to ixgbe and ixgbevf). Signed-off-by: Florian Fainelli f.faine...@gmail.com Intel folks, I assume you will pick this up? -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net-next 00/35] net: Use pci_enable_msix_range() instead of pci_enable_msix()
From: Alexander Gordeev agord...@redhat.com Date: Tue, 18 Feb 2014 11:07:52 +0100 As result of deprecation of MSI-X/MSI enablement functions pci_enable_msix() and pci_enable_msi_block() all drivers using these two interfaces need to be updated to use the new pci_enable_msi_range() and pci_enable_msix_range() interfaces. Cc: e1000-devel@lists.sourceforge.net Cc: linux-dri...@qlogic.com Cc: linux-net-driv...@solarflare.com Cc: linux-...@vger.kernel.org Cc: linux-r...@vger.kernel.org Cc: net...@vger.kernel.org Cc: pv-driv...@vmware.com Cc: wil6...@qca.qualcomm.com Series applied, thanks. -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] ixgbevf: Use pci_enable_msix_range() instead of pci_enable_msix()
From: Amir Vadai am...@mellanox.com Date: Tue, 18 Feb 2014 14:01:38 +0200 On 18/02/14 11:11 +0100, Alexander Gordeev wrote: As result of deprecation of MSI-X/MSI enablement functions pci_enable_msix() and pci_enable_msi_block() all drivers using these two interfaces need to be updated to use the new pci_enable_msi_range() and pci_enable_msix_range() interfaces. Signed-off-by: Alexander Gordeev agord...@redhat.com Cc: Jeff Kirsher jeffrey.t.kirs...@intel.com Cc: Jesse Brandeburg jesse.brandeb...@intel.com Cc: Bruce Allan bruce.w.al...@intel.com Cc: e1000-devel@lists.sourceforge.net Cc: net...@vger.kernel.org Cc: linux-...@vger.kernel.org --- Acked-By: Amir Vadai am...@mellanox.com Since you obviously didn't intend to ACK this, I removed this ACK when I committed the series. -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net] igb: Fix Null-pointer dereference in igb_reset_q_vector
From: Christoph Paasch christoph.paa...@uclouvain.be Date: Tue, 18 Feb 2014 14:06:57 +0100 When igb_set_interrupt_capability() calls igb_reset_interrupt_capability() (e.g., because CONFIG_PCI_MSI is unset), num_q_vectors has been set but no vector has yet been allocated. igb_reset_interrupt_capability() will then call igb_reset_q_vector, which assumes that the vector is allocated. As this is not the case, we are accessing a NULL-pointer. This patch fixes it by checking that q_vector is indeed different from NULL. Fixes: 02ef6e1d0b0023 (igb: Fix queue allocation method to accommodate changing during runtime) Cc: Carolyn Wyborny carolyn.wybo...@intel.com Signed-off-by: Christoph Paasch christoph.paa...@uclouvain.be Intel folks, please queue this up, thanks. -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH 1/1] net: i40evf: Remove duplicate include
From: Sachin Kamat sachin.ka...@linaro.org Date: Mon, 17 Feb 2014 15:29:21 +0530 linux/sctp.h was included twice. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Applied to net-next, thank you. -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net-next V2] intel: Remove unnecessary OOM messages
From: Joe Perches j...@perches.com Date: Tue, 11 Feb 2014 17:30:52 -0800 Don't emit these as there's a generic OOM with a dump_stack() on allocation failures. Signed-off-by: Joe Perches j...@perches.com --- With patch attached this time... I expect the Intel folks to pick this up. -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net] e100: Fix disabling already-disabled device warning
From: Brown, Aaron F aaron.f.br...@intel.com Date: Fri, 31 Jan 2014 00:40:16 + From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On Behalf Of David Miller Sent: Thursday, January 30, 2014 4:28 PM To: mich...@acksyn.org Cc: net...@vger.kernel.org; e1000-devel@lists.sourceforge.net; idirect...@aim.com Subject: Re: [PATCH net] e100: Fix disabling already-disabled device warning From: Michele Baldessari mich...@acksyn.org Date: Thu, 30 Jan 2014 10:51:04 + In https://bugzilla.redhat.com/show_bug.cgi?id=994438 and https://bugzilla.redhat.com/show_bug.cgi?id=970480 we received different reports of e100 throwing the following warning: ... This patch removes pci_disable_device() from __e100_shutdown(). pci_clear_master() is enough. Signed-off-by: Michele Baldessari mich...@acksyn.org Tested-by: Mark Harig idirect...@aim.com Signed-off-by: Aaron Brown aaron.f.br...@intel.com Sorry if it's a duplicate, one I sent out earlier did not seem to hit netdev. I think this patch was posted twice, once without netdev properly CC:'d and you replied to that copy. Thanks Aaron, I'll apply this. -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH] [trivial] ixgbe: Fix format string in ixgbe_fcoe.c
From: Masanari Iida standby2...@gmail.com Date: Wed, 15 Jan 2014 01:14:42 +0900 cppcheck detected following warning in ixgbe_fcoe.c (warning) %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. Signed-off-by: Masanari Iida standby2...@gmail.com Intel folks, please be sure to pick this up. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH 1/2 Net-next] ixgbe: define IXGBE_MAX_VFS_DRV_LIMIT macro and cleanup const 63
From: ethan zhao ethan.z...@oracle.com Date: Thu, 16 Jan 2014 12:25:01 +0800 Signed-off-by: Ethan Zhao ethan.z...@oracle.com Signed-off-by: Ethan Zhao ethan.ker...@gmail.com Please don't give two signoffs for yourself, it is not appropriate at all. I am very genuinely curious where you got the idea to do that, particularly as I've never seen anyone else do it before. So it's really not possible that you got the idea from someone else's actions. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net V3 2/2] net: core: explicitly select a txq before doing l2 forwarding
From: Jason Wang jasow...@redhat.com Date: Fri, 10 Jan 2014 16:18:26 +0800 Currently, the tx queue were selected implicitly in ndo_dfwd_start_xmit(). The will cause several issues: - NETIF_F_LLTX were removed for macvlan, so txq lock were done for macvlan instead of lower device which misses the necessary txq synchronization for lower device such as txq stopping or frozen required by dev watchdog or control path. - dev_hard_start_xmit() was called with NULL txq which bypasses the net device watchdog. - dev_hard_start_xmit() does not check txq everywhere which will lead a crash when tso is disabled for lower device. Fix this by explicitly introducing a new param for .ndo_select_queue() for just selecting queues in the case of l2 forwarding offload. netdev_pick_tx() was also extended to accept this parameter and dev_queue_xmit_accel() was used to do l2 forwarding transmission. With this fixes, NETIF_F_LLTX could be preserved for macvlan and there's no need to check txq against NULL in dev_hard_start_xmit(). Also there's no need to keep a dedicated ndo_dfwd_start_xmit() and we can just reuse the code of dev_queue_xmit() to do the transmission. In the future, it was also required for macvtap l2 forwarding support since it provides a necessary synchronization method. Cc: John Fastabend john.r.fastab...@intel.com Cc: Neil Horman nhor...@tuxdriver.com Cc: e1000-devel@lists.sourceforge.net Signed-off-by: Jason Wang jasow...@redhat.com Applied. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH-next] intel ethernet: fix s390 build failure due to implicit prefetch.h
From: Paul Gortmaker paul.gortma...@windriver.com Date: Fri, 10 Jan 2014 14:28:16 -0500 As of commit 7f12ad741a4870b8b6e3aafbcd868d0191770802 (i40evf: transmit and receive functionality) the s390 builds (allyesconfig) fail with: drivers/net/ethernet/intel/i40evf/i40e_txrx.c: In function 'i40e_clean_rx_irq': drivers/net/ethernet/intel/i40evf/i40e_txrx.c:818:3: error: implicit declaration of function 'prefetch' make[5]: *** [drivers/net/ethernet/intel/i40evf/i40e_txrx.o] Error 1 due to an implicit assumption that the prototype from linux/prefetch.h will be present. Cc: Mitch Williams mitch.a.willi...@intel.com Cc: Greg Rose gregory.v.r...@intel.com Cc: Sibai Li sibai...@intel.com Cc: Jeff Kirsher jeffrey.t.kirs...@intel.com Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com I hope the Intel folks will pick this up quickly and push it to me. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net-next] net:drivers/net: Miscellaneous conversions to ETH_ALEN
From: Joe Perches j...@perches.com Date: Tue, 01 Oct 2013 19:04:40 -0700 Convert the memset/memcpy uses of 6 to ETH_ALEN where appropriate. Also convert some struct definitions and u8 array declarations of [6] to ETH_ALEN. Signed-off-by: Joe Perches j...@perches.com Looks fine, applied, thanks Joe. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH 00/10 - GIT PULL] drivers: net: Next block of Remove extern from function prototypes
From: Joe Perches j...@perches.com Date: Tue, 24 Sep 2013 14:09:54 -0700 The following changes since commit b0983d3c9b132c33b6fb2e28d157a1edc18a173c: tcp: fix dynamic right sizing (2013-09-24 11:07:32 -0400) are available in the git repository at: git://repo.or.cz/linux-2.6/trivial-mods.git 20130924_dn_externs_2 Pulled, thanks Joe. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH 02/10] intel: Remove extern from function prototypes
From: Ben Hutchings bhutchi...@solarflare.com Date: Tue, 24 Sep 2013 23:16:52 +0100 On Tue, 2013-09-24 at 15:07 -0700, Jeff Kirsher wrote: On Tue, 2013-09-24 at 14:09 -0700, Joe Perches wrote: There are a mix of function prototypes with and without extern in the kernel sources. Standardize on not using extern for function prototypes. Function prototypes don't need to be written with extern. extern is assumed by the compiler. Its use is as unnecessary as using auto to declare automatic/local variables in a block. So you are able to confirm that all compilers make this assumption correctly? The initial reason for using extern was because not all compilers made the assumption or made it correctly. You are probably thinking of global variables, where declarations without either 'extern' or an initialiser might or might not be treated as 'common'. On function declarations, 'extern' really is redundant. Furthermore, these networking headers include existing generic kernel headers which already have removed the 'extern' from function declarations in certain cases. So I don't think there isn't an issue, and if there is it has existed already for some time. :-) -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [net v7 0/8][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher jeffrey.t.kirs...@intel.com Date: Wed, 11 Sep 2013 02:50:48 -0700 git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net master Ok, I've pulled this. Please send fixups based upon the trivial issues a few folks have pointed out. Thanks. -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [net-next v5 8/8] i40e: include i40e in kernel proper
I'm kind of getting sick of the we'll fix it in a follow up patch talk. Please rename this Kbuild file to the normal Makefile instead of trying to be different from every single other driver in the networking for the sake of an issue that is your, and your problem alone. You guys should really be grateful that anyone at all not being paid to do so is reviewing such a huge body of code for you, rather than complaining that all the issues weren't discovered the first time this series was posted. Please start being more reasonable about this situation. Thank you. -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [net-next v5 8/8] i40e: include i40e in kernel proper
From: Joe Perches j...@perches.com Date: Fri, 06 Sep 2013 11:20:15 -0700 On Fri, 2013-09-06 at 17:28 +, Williams, Mitch A wrote: My goal was to make our out-of-tree driver as close as possible - including the makefiles - to the upstream driver. Doing this makes it simpler for us to backport and forward-port patches. It makes it less confusing for us when we're moving from one environment to the other. I think using things like #define i40e_memset memset is just odd. Agreed, this is rediculous. -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [net-next v4 7/8] i40e: sysfs and debugfs interfaces
From: Nelson, Shannon shannon.nel...@intel.com Date: Thu, 5 Sep 2013 01:25:47 + Will this work for you? You will fix the problems people are reporting with this patch series before I apply it. -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [net-next v4 7/8] i40e: sysfs and debugfs interfaces
From: Brandeburg, Jesse jesse.brandeb...@intel.com Date: Thu, 5 Sep 2013 04:08:39 + On Wed, 2013-09-04 at 23:19 -0400, David Miller wrote: You will fix the problems people are reporting with this patch series before I apply it. Okay, the quickest path to that might be to drop the sysfs patch for now. If that is acceptable I will re-spin the patches tonight. You're just going to ask me to add the sysfs code later, just make the appropriate fixes. Thanks. -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [net-next v3 1/8] i40e: main driver core
From: Stephen Hemminger step...@networkplumber.org Date: Fri, 30 Aug 2013 11:10:29 -0700 On Fri, 30 Aug 2013 09:32:48 -0700 Joe Perches j...@perches.com wrote: +static int debug = -1; +module_param(debug, int, 0); +MODULE_PARM_DESC(debug, Debug level (0=none,...,16=all)); Maybe make debug a bitfield instead? No Joe, this is the standard mapping of debug to msglevel used by most network devices. The debug parameter is converted to mask by netif_msg_init. Correct. -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net-next] drivers:net: Convert dma_alloc_coherent(...__GFP_ZERO) to dma_zalloc_coherent
From: Joe Perches j...@perches.com Date: Mon, 26 Aug 2013 22:45:23 -0700 __GFP_ZERO is an uncommon flag and perhaps is better not used. static inline dma_zalloc_coherent exists so convert the uses of dma_alloc_coherent with __GFP_ZERO to the more common kernel style with zalloc. Remove memset from the static inline dma_zalloc_coherent and add just one use of __GFP_ZERO instead. Trivially reduces the size of the existing uses of dma_zalloc_coherent. Realign arguments as appropriate. Signed-off-by: Joe Perches j...@perches.com Applied, thanks a lot Joe. -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [net-next v2 1/8] i40e: main driver core
From: Nelson, Shannon shannon.nel...@intel.com Date: Tue, 27 Aug 2013 20:34:04 + I understand the aesthetics as it does make the code look a little cleaner, and we can do this with a lot of our functions. However, there are several instances where one declaration initialization depends on a previous declaration, and trying to organize by line length breaks these relationships. Do you mind if we're not perfect on following this one? Put the assignments that can match the ordering rule into the declarations, put the remaining ones on seperate lines after the declarations. -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [net-next v2 2/8] i40e: transmit, receive, and napi
From: Stefan Assmann sassm...@kpanic.de
Date: Fri, 23 Aug 2013 14:42:07 +0200
On 23.08.2013 04:15, Jeff Kirsher wrote:
From: Jesse Brandeburg jesse.brandeb...@intel.com
This patch contains the transmit, receive, and napi routines, as well
as ancillary routines.
This file is code that is (will be) shared between the VF and PF
drivers.
Just some small nitpicks.
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
new file mode 100644
index 000..ceafef0
--- /dev/null
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
[...]
+static void i40e_receive_skb(struct i40e_ring *rx_ring,
+ struct sk_buff *skb, u16 vlan_tag)
+{
+struct i40e_vsi *vsi = rx_ring-vsi;
+struct i40e_q_vector *q_vector = rx_ring-q_vector;
+u64 flags = vsi-back-flags;
+
+if (vlan_tag VLAN_VID_MASK)
+__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vlan_tag);
Suggesting __constant_htons instead of htons here.
We don't suggest that anymore, because it's completely unnecessary
with the way the macros are implemented.
--
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel#174; Ethernet, visit
http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH RFC net-next] net: epoll support for busy poll
From: Eliezer Tamir eliezer.ta...@linux.intel.com Date: Wed, 21 Aug 2013 13:39:54 +0300 + SK_LL_STATE_MISS_2, /* data came through napi poll twice in a row */ Please rename this to SK_LL_STATE_MISS_MULTI or something like that. Thanks. -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net-next v3 0/3] net: finish renaming lls to busy poll
From: Eliezer Tamir eliezer.ta...@linux.intel.com
Date: Wed, 10 Jul 2013 17:13:07 +0300
Here are three patches that complete the rename of lls to busy-poll
1. rename include/net/ll_poll.h to include/net/busy_poll.h
2. Rename ndo_ll_poll to ndo_busy_poll.
Rename sk_mark_ll to sk_mark_napi_id.
Rename skb_mark_ll to skb_mark_napi_id.
Correct all useres of these functions.
Update comments and defines in include/net/busy_poll.h
3. Rename LL_SO to BUSY_POLL_SO
Rename sysctl_net_ll_{read,poll} to sysctl_busy_{read,poll}
Fix up users of these variables.
Fix documentation for sysctl.
v2 fixed forgetting the ndo changes in v1
v3 is a resend with -M
Series applied, thanks.
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel#174; Ethernet, visit
http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH v4 net-next] net: poll/select low latency socket support
From: Eliezer Tamir eliezer.ta...@linux.intel.com Date: Mon, 24 Jun 2013 10:28:03 +0300 select/poll busy-poll support. Split sysctl value into two separate ones, one for read and one for poll. updated Documentation/sysctl/net.txt Add a new poll flag POLL_LL. When this flag is set, sock_poll will call sk_poll_ll if possible. sock_poll sets this flag in its return value to indicate to select/poll when a socket that can busy poll is found. When poll/select have nothing to report, call the low-level sock_poll again until we are out of time or we find something. Once the system call finds something, it stops setting POLL_LL, so it can return the result to the user ASAP. Signed-off-by: Eliezer Tamir eliezer.ta...@linux.intel.com Looks good, applied, thanks! -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH v3 net-next 0/1] net: lls select poll support
From: Eliezer Tamir eliezer.ta...@linux.intel.com
Date: Wed, 19 Jun 2013 13:04:21 +0300
One question: do we need in sock_poll() to test that sock-sk is not null?
(Thanks to Willem de Bruijn for pointing this out.)
We should not have to.
Please clean up various things in this patch:
1) You have cases where you add tons of unnecessary empty lines, of the
form:
if (foo) {
/* EMPTY LINE */
code...
please get rid of them.
2) Some of the LL loops have conditions that are not properly formatted,
I see things like:
do {
...
} while (x y z
whatever)
That whatever is not properly indented. You must always indent
multi-line conditions like this:
xxx (x y
z ...)
That is, operators always end the line, the never begin the line.
And one the second and subsequent lines you must line up the first
character with the first column after the openning parenthesis of
the first line. You should not just use a series of only TAB
characters to indent these expressions.
Thanks.
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel#174; Ethernet, visit
http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH v3 net-next 0/4] net: low latency sockets follow ups
From: Eliezer Tamir eliezer.ta...@linux.intel.com Date: Thu, 13 Jun 2013 17:46:13 +0300 Here are three clean up patches, plus one that adds a socket option for LLS. Patch 1 converts low latency sockets to sched_clock. Patch 2 removes the config menu for NET_LL_RX_POLL and defaults to y. Patch 3 converts sysctl_net_ll_poll into an unsigned int Patch 4 adds an SO_LL socket option to allow per-socket control of busy polling. I will reply to this thread with a patch to sockperf that enables the socket option. (unchanged from v2) Again, thanks to everyone for their comments. Please respin with the overflow introduced by patch #3 corrected, everything else looks fine to me. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net-next 1/2] net: remove NET_LL_RX_POLL config menue
From: Eliezer Tamir eliezer.ta...@linux.intel.com Date: Tue, 11 Jun 2013 17:24:28 +0300 depends on X86_TSC Wait a second, I didn't notice this before. There needs to be a better way to test for the accuracy you need, or if the issue is lack of a proper API for cycle counter reading, fix that rather than add ugly arch specific dependencies to generic networking code. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH v10 net-next 0/6] net: low latency Ethernet device polling
From: Eliezer Tamir eliezer.ta...@linux.intel.com Date: Tue, 11 Jun 2013 09:49:31 +0300 I would like to hear opinions on what needs to be added to make this feature complete. The list I have so far is: 1. add a socket option 2. support for poll/select 3. support for epoll I actually would like to see the Kconfig option go away, that's my only request. Also, would you accept a trailing whitespace cleanup patch for fs/select.c? That's not really for my tree, sorry. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH v10 net-next 0/6] net: low latency Ethernet device polling
From: Eliezer Tamir eliezer.ta...@linux.intel.com Date: Mon, 10 Jun 2013 11:39:30 +0300 I removed the select/poll patch (was 5/7 in v9) from the set. The rest are the same patches that were in v9. Please consider applying. Thanks to everyone for their input. There used to be a really nice, detailed and verbose, description of the goals and general idea of these changes, along with a lot of benchmark data. Now I don't see it, either here in this posting, or in any of the patch commit messages. Don't get rid of stuff like that, for a set of changes of this magnitude you can basically consider such details descriptions and information mandatory. Reply to this email with some text to put in the merge commit, including basic benchmark results, so that I can apply this series. Thanks. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH v10 net-next 0/6] net: low latency Ethernet device polling
From: Eliezer Tamir eliezer.ta...@linux.intel.com Date: Tue, 11 Jun 2013 05:25:42 +0300 Here is the text from the RFC and v2 cover letters, updated and merged. If this is too long, please tell me what you think should be removed. It's perfect, and since this went through so many iterations I included the changelog too. Thanks! -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH v9 net-next 0/7] net: low latency Ethernet device polling
From: Eliezer Tamir eliezer.ta...@linux.intel.com Date: Wed, 05 Jun 2013 13:34:00 +0300 And here is v9. Except for typo fixes in comments/description, only 2/7 and 5/7 were changed. Thanks to everyone for their input. Since there is some discussion about the way the poll() bits work, might I suggest you make a v10 without the poll stuff, which I will apply to net-next, and then you can build the poll stuff on top of that? Thanks! -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH v7 net-next 0/5] net: low latency Ethernet device polling
From: Eliezer Tamir eliezer.ta...@linux.intel.com Date: Sun, 02 Jun 2013 17:02:33 +0300 Or I can submit a v8 with those fixes. Please submit v8 -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net-next 4/4] igb: enable auxiliary PHC functions for the i210.
From: Richard Cochran richardcoch...@gmail.com Date: Wed, 29 May 2013 09:24:45 +0200 Also, using ethtool or sysfs is not really attractive for embedded designs (let's not forget the poor embedded guys). I think we need to have a way to specify the pin functions at (or before) kernel boot time. Barring DT and kconfig, using a module parameter is the only way to accomplish this. No module parameters. The embedded guys can run an ethtool command early in boot right after the driver loads. -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH v3 net-next 3/4] ixgbe: Add support for ndo_ll_poll
From: Eilon Greenstein eil...@broadcom.com Date: Tue, 21 May 2013 10:06:43 +0300 Hopefully this series will be accepted so we can send follow up support for the bnx2x as well. I think in two or three more iterations it will be merged. There are no objections on the fundamentals, it's just implementation details and coding style at this point. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH v3 net-next 3/4] ixgbe: Add support for ndo_ll_poll
From: Or Gerlitz or.gerl...@gmail.com Date: Tue, 21 May 2013 11:24:41 +0300 On Tue, May 21, 2013 at 10:14 AM, David Miller da...@davemloft.net wrote: From: Eilon Greenstein eil...@broadcom.com Date: Tue, 21 May 2013 10:06:43 +0300 Hopefully this series will be accepted so we can send follow up support for the bnx2x as well. I think in two or three more iterations it will be merged. There are no objections on the fundamentals, it's just implementation details and coding style at this point. Dave, sorry, I might be a bit behind the rest of the reviewers, but I just fail to understand nor find any reference that explains the module param of ixgbe nor it makes sense to me to merge that piece of the code upstream (its not for staging, correct?), as I wrote here http://marc.info/?l=linux-netdevm=136908123432072w=2 basically, I know you're not a great fun of module params (to say the least) and surely not something named allow_unsafe_removal, thoughts? It's one of those implementation details, I hate it too. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH v3 net-next 1/4] net: implement support for low latency socket polling
From: Pekka Riikonen priik...@iki.fi
Date: Tue, 21 May 2013 19:02:19 +0200 (CEST)
On Tue, 21 May 2013, Eric Dumazet wrote:
: Alternatively, use a napi_id instead of a pointer.
:
: I'm not sure I understand what you propose.
:
: Oh well.
:
: To get a pointer to a struct net_device, we can use ifindex, and do a
: rcu lookup into a hash table to get the net_device. We do not need
: {pointer,ifindex} but {ifindex} is enough
:
: My suggestion is to not have skb-skb_ref but skb-napi_index : Its safe
: to copy its value from skb-napi_index to sk-napi_index without
: refcounting.
:
: All NAPI need to get a unique napi_index, and be inserted in a hash
: table for immediate/fast lookup.
:
Maybe even that's not needed. Couldn't skb-queue_mapping give the
correct NAPI instance in multiqueue nics? The NAPI instance could be made
easily available from skb-dev. In any case an index is much better than
a new pointer.
Queue mapping is more volatile, and consider layered devices.
--
Try New Relic Now We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel#174; Ethernet, visit
http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH v2 net-next 1/4] net: implement support for low latency socket polling
From: Eliezer Tamir eliezer.ta...@linux.intel.com
Date: Sun, 19 May 2013 13:25:33 +0300
+#ifndef _LINUX_NET_LL_POLL_H
+#define _LINUX_NET_LL_POLL_H
+#ifdef CONFIG_INET_LL_RX_POLL
Please put an empty line before the final ifdef test here.
+static inline void sk_mark_ll(struct sock *sk, struct sk_buff *skb)
+{
+ sk-dev_ref = skb-dev_ref;
^^^
One tab too many.
+#else /* CONFIG_INET_LL_RX_FLUSH */
+
+#define sk_valid_ll(sk) 0
+#define sk_poll_ll(sk, nonblock) do {} while (0)
+#define skb_mark_ll(napi, skb) do {} while (0)
+#define sk_mark_ll(sk, skb) do {} while (0)
Make these inline functions too, so that even if
CONFIG_INET_LL_RX_POLL is disabled, the arguments and return values
are still properly type checked.
{
struct socket *sock;
+ unsigned int poll_result;
Please order local variable declarations from longest line to
shortest line.
+ !(poll_result (POLLRDNORM | POLLERR | POLLRDHUP | POLLHUP))) {
+
+ struct sock *sk = sock-sk;
Please remove the empty line before the variable declaration.
--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel#174; Ethernet, visit
http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH v2 net-next 1/4] net: implement support for low latency socket polling
From: Joe Perches j...@perches.com
Date: Mon, 20 May 2013 01:29:47 -0700
On Mon, 2013-05-20 at 00:54 -0700, David Miller wrote:
From: Eliezer Tamir eliezer.ta...@linux.intel.com
[]
{
struct socket *sock;
+ unsigned int poll_result;
Please order local variable declarations from longest line to
shortest line.
reverse christmas tree doesn't seem especially valuable or
sensible for automatics.
It looks nicer to the eyes and provides a predictable pattern
to look at.
--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel#174; Ethernet, visit
http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH v2 net-next 1/4] net: implement support for low latency socket polling
From: Eliezer Tamir eliezer.ta...@linux.intel.com
Date: Mon, 20 May 2013 12:39:59 +0300
On 20/05/2013 10:54, David Miller wrote:
From: Eliezer Tamir eliezer.ta...@linux.intel.com
Date: Sun, 19 May 2013 13:25:33 +0300
+#else /* CONFIG_INET_LL_RX_FLUSH */
+
+#define sk_valid_ll(sk) 0
+#define sk_poll_ll(sk, nonblock) do {} while (0)
+#define skb_mark_ll(napi, skb) do {} while (0)
+#define sk_mark_ll(sk, skb) do {} while (0)
Make these inline functions too, so that even if
CONFIG_INET_LL_RX_POLL is disabled, the arguments and return values
are still properly type checked.
Is this what you had in mind?
static inline bool sk_valid_ll(struct sock *sk)
Yes.
--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel#174; Ethernet, visit
http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH v3 net-next 1/4] net: implement support for low latency socket polling
From: Eric Dumazet eric.duma...@gmail.com Date: Mon, 20 May 2013 08:29:24 -0700 Part of this information was in your 0/4 text, but it wont be included in the git tree. Yes it will, in the merge commit I make when I merge this stuff in. -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] getting VF link info seems to be broken in 3.9-rc8
From: Alexander Duyck alexander.h.du...@intel.com
Date: Thu, 25 Apr 2013 13:20:24 -0700
On 04/25/2013 12:24 PM, David Miller wrote:
From: Alexander Duyck alexander.h.du...@intel.com
Date: Thu, 25 Apr 2013 11:29:04 -0700
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index b65441d..23854b5 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1072,7 +1072,7 @@ static int rtnl_dump_ifinfo(struct sk_buff *skb,
struct netlink_callback *cb)
rcu_read_lock();
cb-seq = net-dev_base_seq;
-if (nlmsg_parse(cb-nlh, sizeof(struct rtgenmsg), tb, IFLA_MAX,
+if (nlmsg_parse(cb-nlh, sizeof(struct ifinfomsg), tb, IFLA_MAX,
ifla_policy) = 0) {
if (tb[IFLA_EXT_MASK])
@@ -1922,7 +1922,7 @@ static u16 rtnl_calcit(struct sk_buff *skb, struct
nlmsghdr *nlh)
u32 ext_filter_mask = 0;
u16 min_ifinfo_dump_size = 0;
-if (nlmsg_parse(nlh, sizeof(struct rtgenmsg), tb, IFLA_MAX,
+if (nlmsg_parse(nlh, sizeof(struct ifinfomsg), tb, IFLA_MAX,
ifla_policy) = 0) {
if (tb[IFLA_EXT_MASK])
ext_filter_mask = nla_get_u32(tb[IFLA_EXT_MASK]);
I thought that as well. I tried reverting it and the issue is still there.
However, I do think this may be part of the issue since I added a printk
to dump nlmsg_attrlen before going into the nlmsg_parse and with
ifinfomsg the attrlen is -12, with rtgenmsg it is 0.
I wonder if we are seeing two ways tools are making these calls, some are
passing rtgenmsg and some are passing ifinfomsg. The latter, I am mostly
convinced, is what we must see here from properly written applications.
That would be really unfortunate, but seeing a nlmsg_attrlen() of -12 would
seem to confirm that a rtgenmsg was used.
I guess you're using iproute2?
--
Try New Relic Now We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel#174; Ethernet, visit
http://communities.intel.com/community/wired
Re: [E1000-devel] getting VF link info seems to be broken in 3.9-rc8
From: Stephen Hemminger step...@networkplumber.org
Date: Thu, 25 Apr 2013 13:45:13 -0700
On Thu, 25 Apr 2013 13:36:06 -0700
Alexander Duyck alexander.h.du...@intel.com wrote:
On 04/25/2013 01:25 PM, David Miller wrote:
From: Alexander Duyck alexander.h.du...@intel.com
Date: Thu, 25 Apr 2013 13:20:24 -0700
On 04/25/2013 12:24 PM, David Miller wrote:
From: Alexander Duyck alexander.h.du...@intel.com
Date: Thu, 25 Apr 2013 11:29:04 -0700
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index b65441d..23854b5 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1072,7 +1072,7 @@ static int rtnl_dump_ifinfo(struct sk_buff *skb,
struct netlink_callback *cb)
rcu_read_lock();
cb-seq = net-dev_base_seq;
-if (nlmsg_parse(cb-nlh, sizeof(struct rtgenmsg), tb, IFLA_MAX,
+if (nlmsg_parse(cb-nlh, sizeof(struct ifinfomsg), tb, IFLA_MAX,
ifla_policy) = 0) {
if (tb[IFLA_EXT_MASK])
@@ -1922,7 +1922,7 @@ static u16 rtnl_calcit(struct sk_buff *skb, struct
nlmsghdr *nlh)
u32 ext_filter_mask = 0;
u16 min_ifinfo_dump_size = 0;
-if (nlmsg_parse(nlh, sizeof(struct rtgenmsg), tb, IFLA_MAX,
+if (nlmsg_parse(nlh, sizeof(struct ifinfomsg), tb, IFLA_MAX,
ifla_policy) = 0) {
if (tb[IFLA_EXT_MASK])
ext_filter_mask =
nla_get_u32(tb[IFLA_EXT_MASK]);
I thought that as well. I tried reverting it and the issue is still
there.
However, I do think this may be part of the issue since I added a printk
to dump nlmsg_attrlen before going into the nlmsg_parse and with
ifinfomsg the attrlen is -12, with rtgenmsg it is 0.
I wonder if we are seeing two ways tools are making these calls, some are
passing rtgenmsg and some are passing ifinfomsg. The latter, I am mostly
convinced, is what we must see here from properly written applications.
That would be really unfortunate, but seeing a nlmsg_attrlen() of -12 would
seem to confirm that a rtgenmsg was used.
I guess you're using iproute2?
Yes. All I am doing is ip link show and previously this would display
VF info as well as PF. Now the VF info is not there.
From what I can tell the problem call is rtnl_wilddump_req_filter since
it is only passing a rtgenmsg and asking us to dump the link with the
RTEXT_FILTER_VF filter mask.
It looks like a bug in the initial code for filter. in this case, it calls:
ip_list_flush_or_save
rtnl_wilddump_req_filter
which sends 'struct rtgenmsg'
This was probably a mistake in the original flags addition, not sure if we can
fix it now that ABI is set. Probably have to revert the kernel change.
But we know there are tools, just as widely deployed, passing in ifinfomsg.
That's what trigged inclusion of the patch above in the first place.
Let's just declare this an iproute2 bug, fix iproute2 to pass
ifinfomsg too, and keep an eye out for when other folks run into this
problem.
--
Try New Relic Now We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel#174; Ethernet, visit
http://communities.intel.com/community/wired
Re: [E1000-devel] [net] e100: Add dma mapping error check
From: Jeff Kirsher jeffrey.t.kirs...@intel.com Date: Wed, 10 Apr 2013 02:19:00 -0700 From: Neil Horman nhor...@tuxdriver.com e100 uses pci_map_single, but fails to check for a dma mapping error after its use, resulting in a stack trace: ... Easy fix, modify the cb paramter to e100_exec_cb to return an error, and do the dma_mapping_error check in the obvious place This was reported previously here: http://article.gmane.org/gmane.linux.network/257893 But nobody stepped up and fixed it. CC: Josh Boyer jwbo...@redhat.com CC: e1000-devel@lists.sourceforge.net Signed-off-by: Neil Horman nhor...@tuxdriver.com Reported-by: Michal Jaegermann mic...@harddata.com Tested-by: Aaron Brown aaron.f.br...@intel.com Signed-off-by: Jeff Kirsher jeffrey.t.kirs...@intel.com Applied, thanks. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net-next] drivers:net: dma_alloc_coherent: use __GFP_ZERO instead of memset(, 0)
From: Joe Perches j...@perches.com Date: Fri, 15 Mar 2013 10:23:58 -0700 Reduce the number of calls required to alloc a zeroed block of memory. Trivially reduces overall object size. Other changes around these removals o Neaten call argument alignment o Remove an unnecessary OOM message after dma_alloc_coherent failure o Remove unnecessary gfp_t stack variable Signed-off-by: Joe Perches j...@perches.com Looks good, applied, thanks Joe. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net-next] drivers:net: Remove dma_alloc_coherent OOM messages
From: Joe Perches j...@perches.com Date: Thu, 14 Mar 2013 16:07:21 -0700 I believe these error messages are already logged on allocation failure by warn_alloc_failed and so get a dump_stack on OOM. Remove the unnecessary additional error logging. Around these deletions: o Alignment neatening. o Remove unnecessary casts of dma_alloc_coherent. o Hoist assigns from ifs. Signed-off-by: Joe Perches j...@perches.com Applied, thanks Joe. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [RFC PATCH 1/5] net: implement support for low latency socket polling
From: Ben Hutchings bhutchi...@solarflare.com Date: Tue, 5 Mar 2013 16:43:01 + In general it appears to require a run-time check. You might need to augment asm/timex.h. On the other hand, unlike get_cycles, sched_clock() is always available. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [RFC PATCH 1/5] net: implement support for low latency socket polling
From: Eliezer Tamir eliezer.ta...@linux.intel.com Date: Tue, 05 Mar 2013 19:15:26 +0200 We are not very sensitive to this setting, anything on the order of your half round time trip plus a few standard deviations works well. We are busy waiting, so setting a higher value does not change the results much. This makes the argument for using sched_clock() even stronger. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [RFC PATCH 0/5] net: low latency Ethernet device polling
From: Eliezer Tamir eliezer.ta...@linux.jf.intel.com Date: Wed, 27 Feb 2013 09:55:49 -0800 This patchset adds the ability for the socket layer code to poll directly on an Ethernet device's RX queue. This eliminates the cost of the interrupt and context switch and with proper tuning allows us to get very close to the HW latency. This is a follow up to Jesse Brandeburg's Kernel Plumbers talk from last year http://www.linuxplumbersconf.org/2012/wp-content/uploads/2012/09/2012-lpc-Low-Latency-Sockets-slides-brandeburg.pdf I just wanted to say that I like this work a lot. It proves a lot of things I try to impress upon people who talk about how RDMA is such a must have because the software stack can't possibly give anything near HW latency. Obviously such arguments are complete bullshit as is shown by these changes. This is exactly the kind of approach that makes sense rather than trying to put entire TCP stacks in the network card firmware. Thanks again for doing this work and I look forward to applying this stuff once all the kinks are worked out. The folks in the Intel NIC group continue to impress me. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCHv2-net-3.8 0/3] fix kernel crash with macvtap on top of LRO
From: Michael S. Tsirkin m...@redhat.com Date: Thu, 7 Feb 2013 15:12:56 +0200 At the moment, macvtap crashes are observed if macvtap is attached to an interface with LRO enabled. The crash in question is BUG() in macvtap_skb_to_vnet_hdr. This happens because several drivers set gso_size but not gso_type in incoming skbs. This didn't use to be the case: with intel cards on 3.2 and older kernels, with qlogic - on 3.4 and older kernels, so it's a regression if not a recent one. The following patches fix this for qlogic, broadcom and intel drivers. I tested that the patch fixes the crash for ixgbe but don't have qlogic/broadcom hardware to test. I also only tested TCPv4. Please review, and consider for 3.8. Changes from v1: - added missing htons as suggested by Eric - backported the relevant bits from cbf1de72324a8105ddcc3d9ce9acbc613faea17e for bnx2x Applied to 'net', thanks. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH 0/2] fix kernel crash with macvtap on top of LRO
From: Ben Hutchings bhutchi...@solarflare.com Date: Thu, 7 Feb 2013 22:31:35 + On Thu, 2013-02-07 at 23:33 +0200, Michael S. Tsirkin wrote: We might want to add code to forward LRO status from macvlan (not macvtap) back to the lowerdev, so that setting up forwarding from macvlan disables LRO on the lowerdev, but that seems like another issue. I think it's the same issue! I do too, can someome please work to resolve this properly? Thanks. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH] drivers: net: Remove remaining alloc/OOM messages
From: Joe Perches j...@perches.com Date: Thu, 07 Feb 2013 13:46:27 -0800 alloc failures already get standardized OOM messages and a dump_stack. For the affected mallocs around these OOM messages: Converted kmallocs with multiplies to kmalloc_array. Converted a kmalloc/memcpy to kmemdup. Removed now unused stack variables. Removed unnecessary parentheses. Neatened alignment. Signed-off-by: Joe Perches j...@perches.com Applied, thanks Joe. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH 0/2] fix kernel crash with macvtap on top of LRO
From: Ben Hutchings bhutchi...@solarflare.com Date: Thu, 7 Feb 2013 16:20:46 + If the consensus is still that we must preserve packets exactly (aside from the usual modifications by IP routers) then LRO should be disabled on all devices for which forwarding is enabled. I believe this is still undoubtedly the consensus. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH 0/8] drivers/net: Remove unnecessary alloc/OOM messages
From: Joe Perches j...@perches.com Date: Sun, 3 Feb 2013 19:28:07 -0800 Remove all the OOM messages that follow kernel alloc failures as there is already a generic equivalent to these messages in the mm subsystem. Joe Perches (8): caif: Remove unnecessary alloc/OOM messages can: Remove unnecessary alloc/OOM messages ethernet: Remove unnecessary alloc/OOM messages, alloc cleanups drivers: net: usb: Remove unnecessary alloc/OOM messages wan: Remove unnecessary alloc/OOM messages wimax: Remove unnecessary alloc/OOM messages, alloc cleanups wireless: Remove unnecessary alloc/OOM messages, alloc cleanups drivers:net:misc: Remove unnecessary alloc/OOM messages Series applied, thanks Joe. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH 3.0.y 0/3] rtnetlink: Fix problem with buffer allocation
From: Ben Hutchings bhutchi...@solarflare.com
Date: Fri, 4 Jan 2013 00:30:49 +
These patches fix the problem that interface information including many
VFs is too large for the 4K buffers used by glibc and other clients.
This breaks many network services.
The first of these ('rtnetlink: Compute and store minimum ifinfo dump
size') went into 3.1 and has also been included in SLE11 SP2. The
second and third were acked by David Miller and included in 3.2.34.
I've applied and briefly tested these changes in conjunction with a
backport of the sfc driver to SLE11 SP3.
I'm fine with these going into 3.0.x-stable, thanks for doing the
backport.
--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel#174; Ethernet, visit
http://communities.intel.com/community/wired
Re: [E1000-devel] Should we report bus width/speed via ethtool?
From: Ben Greear gree...@candelatech.com Date: Wed, 05 Dec 2012 15:09:11 -0800 On 12/05/2012 02:36 PM, David Miller wrote: From: Ben Greear gree...@candelatech.com Date: Wed, 05 Dec 2012 13:35:01 -0800 It seems the only way to get the current pci-e bus speed width in ixgbe (and probably many other NICs) is by parsing output of lspci -vvv. I'd personally find it easier if this info were available via ethtool API. You could just as easily have ethtool determine the PCI device location (using existing facilities) and fetch the PCI-e info from the PCI sysfs files. Any particular sysfs file? I've been grubbing around in there and I don't see anything that specifies bus width or speed.. Maybe it's some binary blob that needs decoding? lspci might be a good place to figure this out :-) It's probably grovelling around in PCI config space to determine these things. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH v2] netfilter: take care of timewait sockets
From: Eric Dumazet eric.duma...@gmail.com Date: Mon, 03 Sep 2012 11:57:18 +0200 David, tell me if you prefer to change TCP demux to avoid timewait, as I have no strong opinion. It would be the stupidest thing ever to do the whole hash lookup just to throw the result away just because it's a timewait socket. [PATCH] net: sock_edemux() should take care of timewait sockets sock_edemux() can handle either a regular socket or a timewait socket Signed-off-by: Eric Dumazet eduma...@google.com Applied, thanks. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH] net: e100: ucode is optional in some cases
From: Bjørn Mork bj...@mork.no Date: Thu, 19 Jul 2012 11:33:13 +0200 + * http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/rcvbundl.h?rev=HEAD;content-type=text%2Fplain Please don't put URLs into the source code, they generally lack permanence. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH v2] net: e100: ucode is optional in some cases
From: Bjørn Mork bj...@mork.no Date: Thu, 19 Jul 2012 18:28:40 +0200 commit 9ac32e1b firmware: convert e100 driver to request_firmware() did a straight conversion of the in-driver ucode to external files. This introduced the possibility of the driver failing to enable an interface due to missing ucode. There was no evaluation of the importance of the ucode at the time. Based on comments in earlier versions of this driver, and in the source code for the FreeBSD fxp driver, we can assume that the ucode implements the CPU Cycle Saver feature on supported adapters. Although generally wanted, this is an optional feature. The ucode source is not available, preventing it from being included in free distributions. This creates unnecessary problems for the end users. Doing a network install based on a free distribution installer requires the user to download and insert the ucode into the installer. Making the ucode optional when possible improves the user experience and driver usability. The ucode for some adapters include a bugfix, making it essential. We continue to fail for these adapters unless the ucode is available. Signed-off-by: Bjørn Mork bj...@mork.no --- v2: removed URLs from the patch, converting them to generic descriptions of the sources of information Applied. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net-next 0/8] etherdevice: Rename random_ether_addr to eth_random_addr
From: Felipe Balbi ba...@ti.com Date: Mon, 16 Jul 2012 13:14:38 +0300 if you're really renaming the function, then this patch alone will break all of the below users. That should all be a single patch, I'm afraid. It would help if you actually read his patches before saying what they might or might not do. He provides a macro in the first patch that provides the old name, and this will get removed at the end. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net-next 0/8] etherdevice: Rename random_ether_addr to eth_random_addr
From: Felipe Balbi ba...@ti.com Date: Mon, 16 Jul 2012 14:12:19 +0300 Acked-by: Felipe Balbi ba...@ti.com You need to provide this in a reply to the patch you actually want to ACK, so that the patch tracking system attaches your ACK to the proper patch. Thank you. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net-next 0/8] etherdevice: Rename random_ether_addr to eth_random_addr
From: Joe Perches j...@perches.com Date: Thu, 12 Jul 2012 22:33:04 -0700 net-next commit ad7eee98be (etherdevice: introduce eth_broadcast_addr) added a new style API. Rename random_ether_addr to eth_random_addr to create some API symmetry. Series applied, thanks Joe. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH] e1000: save skb counts in TX to avoid cache misses
From: Jeff Kirsher tar...@gmail.com Date: Thu, 07 Jun 2012 14:38:17 -0700 Thanks! I have applied the patch to my queue Why? My impression is that this is a patch already in the tree, and it's being submitted for -stable but such minor performance hacks are absolutely not appropriate for -stable submission. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH] e1000e: disable rxhash when try to enable jumbo frame also rxhash and rxcsum have enabled
From: Joe Jin joe@oracle.com Date: Fri, 08 Jun 2012 09:06:40 +0800 Upstream commit 70495a5 check if both rxhash and rxcsum enabled when enabling jumbo frames and disallowed all of them enabled at the same time. Since jumbo frame widely be used in real world, so when try to enable jumbo frames but rxhash and rxcsum have enabled, change the default behavior to disable receive hashing. Signed-off-by: Joe Jin joe@oracle.com Signed-off-by: Guru Anbalagane guru.anbalag...@oracle.com Acked-by: Adnan Misherfi adnan.mishe...@oracle.com If I were the Intel developers I would not apply this patch, it sets a very bad precedence. The tool tells you that the combination you're attempting to use is invalid, and the kernel log message tells you exactly why. The driver should never automatically change configuration settings not actually requested by the user. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
