[PATCH net-next v2 04/14] iavf: rename i40e_status to iavf_status

This is just a rename of an internal variable i40e_status, but it was a pretty big change and so deserved it's own patch. Signed-off-by: Jesse Brandeburg --- drivers/net/ethernet/intel/iavf/i40e_adminq.c | 94 +- drivers/net/ethernet/intel/iavf/i40e_alloc.h | 8

[PATCH net-next v2 09/14] iavf: rename i40e_hw to iavf_hw

Fix up the i40e_hw names to new name, including versions inside other strings. Signed-off-by: Jesse Brandeburg --- drivers/net/ethernet/intel/iavf/i40e_adminq.c| 42 +++ drivers/net/ethernet/intel/iavf/i40e_alloc.h | 21 +++- drivers/net/ethernet/intel/iavf/i40e_common.c

[PATCH net-next v2 06/14] iavf: remove references to old names

Remove the register name references to I40E_VF* and change to IAVF_VF. Update the descriptor names and defines to the IAVF name. Signed-off-by: Jesse Brandeburg --- drivers/net/ethernet/intel/iavf/i40e_adminq.c | 28 ++-- drivers/net/ethernet/intel/iavf/i40e_common.c | 2 +- drivers/net

[PATCH net-next v2 08/14] iavf: rename I40E_ADMINQ_DESC

Take care of some renames containing I40E_ADMINQ_DESC. Signed-off-by: Jesse Brandeburg --- drivers/net/ethernet/intel/iavf/i40e_adminq.c | 18 +- drivers/net/ethernet/intel/iavf/i40e_adminq.h | 4 ++-- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/net

[PATCH net-next v2 07/14] iavf: rename device ID defines

Rename the device ID defines to have IAVF in them and remove all the unused defines. Signed-off-by: Jesse Brandeburg --- drivers/net/ethernet/intel/iavf/i40e_adminq.c | 22 +++ drivers/net/ethernet/intel/iavf/i40e_common.c | 29 +++ drivers/net/ethernet/intel/iavf

[PATCH net-next v2 10/14] iavf: replace i40e_debug with iavf version

Change another string (i40e_debug) Signed-off-by: Jesse Brandeburg --- drivers/net/ethernet/intel/iavf/i40e_adminq.c| 28 drivers/net/ethernet/intel/iavf/i40e_common.c| 12 +- drivers/net/ethernet/intel/iavf/i40e_osdep.h | 2 +- drivers/net/ethernet

[PATCH net-next v2 13/14] iavf: finish renaming files to iavf

This finishes the process of renaming the files that make sense to rename (skipping adminq related files that talk to i40e), and fixes up the build and the #includes so that everything builds nicely. Signed-off-by: Jesse Brandeburg --- drivers/net/ethernet/intel/iavf/Makefile

[PATCH net-next v2 11/14] iavf: tracing infrastructure rename

Rename the i40e_trace file and fix up all the callers to the new names inside the iavf_trace.h file. Signed-off-by: Jesse Brandeburg --- drivers/net/ethernet/intel/iavf/iavf_main.c| 2 +- .../intel/iavf/{i40e_trace.h => iavf_trace.h} | 28 +++--- drivers/

[PATCH net-next v2 05/14] iavf: move i40evf files to new name

Simply move the i40evf files to the new name, updating the #includes to track the new names, and updating the Makefile as well. A future patch will remove the i40e references (after the code removal patches later in this series). Signed-off-by: Jesse Brandeburg --- drivers/net/ethernet/intel

[PATCH net-next v2 14/14] intel-ethernet: use correct module license

We recently updated all our SPDX identifiers to correctly indicate our net/ethernet/intel/* drivers were always released and intended to be released under GPL v2, but the MODULE_LICENSE declaration was never updated. Fix the MODULE_LICENSE to be GPL v2, for all our drivers. Signed-off-by: Jesse

[PATCH net-next v2 02/14] iavf: diet and reformat

Remove a bunch of unused code and reformat a few lines. Also remove some now un-necessary files. Signed-off-by: Jesse Brandeburg --- drivers/net/ethernet/intel/iavf/i40e_adminq.c | 27 - drivers/net/ethernet/intel/iavf/i40e_adminq_cmd.h | 2277 + drivers/net/ethernet

[PATCH net-next v2 00/14] rename and shrink i40evf

ion, updated Kconfig migration in patch 1 v1: initial RFC Jesse Brandeburg (14): intel-ethernet: rename i40evf to iavf iavf: diet and reformat iavf: rename functions and structs to new name iavf: rename i40e_status to iavf_status iavf: move i40evf files to new name iavf: remove references

[PATCH net-next v2 01/14] intel-ethernet: rename i40evf to iavf

a MODULE_ALIAS to the old name. Signed-off-by: Jesse Brandeburg --- v2: add Kconfig migration as suggested by davem --- Documentation/networking/00-INDEX| 4 ++-- Documentation/networking/{i40evf.txt => iavf.txt}| 16 +--- MAINTAIN

Re: [RFC PATCH net-next v1 00/14] rename and shrink i40evf

On Fri, 14 Sep 2018 12:10:45 +0300 Or wrote: > On Fri, Sep 14, 2018 at 1:31 AM, Jesse Brandeburg > wrote: > on what HW ring format do you standardize? do i40e/Fortville and > ice/what's-the-intel-code-name? HWs can/use the same posting/completion > descriptor? The init

Re: [RFC PATCH net-next v1 00/14] rename and shrink i40evf

On Fri, 14 Sep 2018 13:39:17 +0900 Benjamin wrote: > > Jesse Brandeburg (14): > > intel-ethernet: rename i40evf to iavf > > Seems like patch 1 didn't make it to netdev > https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20180910/014025.html Hi Ben, Thanks

[RFC PATCH net-next v1 14/14] intel-ethernet: use correct module license

We recently updated all our SPDX identifiers to correctly indicate our net/ethernet/intel/* drivers were always released and intended to be released under GPL v2, but the MODULE_LICENSE declaration was never updated. Fix the MODULE_LICENSE to be GPL v2, for all our drivers. Signed-off-by: Jesse

[RFC PATCH net-next v1 10/14] iavf: replace i40e_debug with iavf version

Change another string (i40e_debug) Signed-off-by: Jesse Brandeburg --- drivers/net/ethernet/intel/iavf/i40e_adminq.c| 28 drivers/net/ethernet/intel/iavf/i40e_common.c| 12 +- drivers/net/ethernet/intel/iavf/i40e_osdep.h | 2 +- drivers/net/ethernet

[RFC PATCH net-next v1 13/14] iavf: finish renaming files to iavf

This finishes the process of renaming the files that make sense to rename (skipping adminq related files that talk to i40e) and fixes up the build and the #includes so that everything builds nicely. Signed-off-by: Jesse Brandeburg --- drivers/net/ethernet/intel/iavf/Makefile

[RFC PATCH net-next v1 09/14] iavf: rename i40e_hw to iavf_hw

Fix up the i40e_hw names to new name, including versions inside other strings. Signed-off-by: Jesse Brandeburg --- drivers/net/ethernet/intel/iavf/i40e_adminq.c| 42 +++ drivers/net/ethernet/intel/iavf/i40e_alloc.h | 21 +++- drivers/net/ethernet/intel/iavf/i40e_common.c

[RFC PATCH net-next v1 04/14] iavf: rename i40e_status to iavf_status

This is just a rename of an internal variable i40e_status, but it was a pretty big change and so deserved it's own patch. Signed-off-by: Jesse Brandeburg --- drivers/net/ethernet/intel/iavf/i40e_adminq.c | 94 +- drivers/net/ethernet/intel/iavf/i40e_alloc.h | 8

[RFC PATCH net-next v1 11/14] iavf: tracing infrastructure rename

Rename the i40e_trace file and fix up all the callers to the new names inside the iavf_trace.h file. Signed-off-by: Jesse Brandeburg --- drivers/net/ethernet/intel/iavf/iavf_main.c| 2 +- .../intel/iavf/{i40e_trace.h => iavf_trace.h} | 28 +++--- drivers/

[RFC PATCH net-next v1 00/14] rename and shrink i40evf

IG_I40EVF. Existing user configurations may have to change, but the module alias in patch 1 helps a bit here. --- v1: initial RFC Jesse Brandeburg (14): intel-ethernet: rename i40evf to iavf iavf: diet and reformat iavf: rename functions and structs to new name iavf: rename i40e_status t

[RFC PATCH net-next v1 06/14] iavf: remove references to old names

Remove the register name references to I40E_VF* and change to IAVF_VF. Update the descriptor names and defines to the IAVF name. Signed-off-by: Jesse Brandeburg --- drivers/net/ethernet/intel/iavf/i40e_adminq.c | 28 ++-- drivers/net/ethernet/intel/iavf/i40e_common.c | 2 +- drivers/net

[RFC PATCH net-next v1 08/14] iavf: rename I40E_ADMINQ_DESC

Take care of some renames containing I40E_ADMINQ_DESC. Signed-off-by: Jesse Brandeburg --- drivers/net/ethernet/intel/iavf/i40e_adminq.c | 18 +- drivers/net/ethernet/intel/iavf/i40e_adminq.h | 4 ++-- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/net

[RFC PATCH net-next v1 02/14] iavf: diet and reformat

Remove a bunch of unused code and reformat a few lines. Also remove some now un-necessary files. Signed-off-by: Jesse Brandeburg --- drivers/net/ethernet/intel/iavf/i40e_adminq.c | 27 - drivers/net/ethernet/intel/iavf/i40e_adminq_cmd.h | 2276 + drivers/net/ethernet

[RFC PATCH net-next v1 05/14] iavf: move i40evf files to new name

Simply move the i40evf files to the new name, updating the #includes to track the new names, and updating the Makefile as well. A future patch will remove the i40e references (after the code removal patches later in this series). Signed-off-by: Jesse Brandeburg --- v3: renamed more files after

[RFC PATCH net-next v1 07/14] iavf: rename device ID defines

Rename the device ID defines to have IAVF in them and remove all the unused defines. Signed-off-by: Jesse Brandeburg --- drivers/net/ethernet/intel/iavf/i40e_adminq.c | 22 +++ drivers/net/ethernet/intel/iavf/i40e_common.c | 29 +++ drivers/net/ethernet/intel/iavf

Re: [RFC PATCH net-next 10/12] vhost_net: build xdp buff

On Mon, 21 May 2018 17:04:31 +0800 Jason wrote: > This patch implement build XDP buffers in vhost_net. The idea is do > userspace copy in vhost_net and build XDP buff based on the > page. Vhost_net can then submit one or an array of XDP buffs to > underlayer socket (e.g TUN). TUN can choose to do

Re: [RFC PATCH net-next 04/12] vhost_net: split out datacopy logic

On Mon, 21 May 2018 17:04:25 +0800 Jason wrote: > Instead of mixing zerocopy and datacopy logics, this patch tries to > split datacopy logic out. This results for a more compact code and > specific optimization could be done on top more easily. > > Signed-off-by: Jason Wang

Re: [RFC PATCH net-next 03/12] vhost_net: introduce vhost_has_more_pkts()

On Mon, 21 May 2018 17:04:24 +0800 Jason wrote: > Signed-off-by: Jason Wang > --- > drivers/vhost/net.c | 12 +--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c > index de544ee..4ebac76 100644 > ---

Re: [RFC PATCH net-next 02/12] vhost_net: introduce vhost_exceeds_weight()

On Mon, 21 May 2018 17:04:23 +0800 Jason wrote: > Signed-off-by: Jason Wang > --- > drivers/vhost/net.c | 13 - > 1 file changed, 8 insertions(+), 5 deletions(-) > > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c > index 15d191a..de544ee 100644 > ---

Re: [RFC PATCH net-next 01/12] vhost_net: introduce helper to initialize tx iov iter

Hi Jason, a few nits. On Mon, 21 May 2018 17:04:22 +0800 Jason wrote: > Signed-off-by: Jason Wang > --- > drivers/vhost/net.c | 34 +++--- > 1 file changed, 23 insertions(+), 11 deletions(-) > > diff --git a/drivers/vhost/net.c

Re: [Intel-wired-lan] [PATCH 12/15] ice: Add stats and ethtool support

On Tue, 13 Mar 2018 12:17:10 -0700 Eric Dumazet wrote: > > Yes, this is a recurring mistake > > See commit > bf909456f6a89654cb65c01fe83a4f9b133bf978 Revert "net: hns3: Add packet > statistics of netdev" Thanks for the pointer, that was a useful thread to review. I

Re: [Intel-wired-lan] [PATCH] i40e: Delete an error message for a failed memory allocation in i40e_init_interrupt_scheme()

> This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net> Thanks for the patch. Acked-by: Jesse Brandeburg <jesse.brandeb...@intel.com>

Re: [Intel-wired-lan] [PATCH v2 next-queue 08/10] ixgbe: process the Tx ipsec offload

On Tue, 12 Dec 2017 21:45:13 -0800 Shannon Nelson wrote: > > Also you are still setting the TCP flag for these packets. I'm > > wondering if the TCP flag is really needed. I get that your current > > setup only runs on TCP flows but what about other types of flows? > >

Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 5/5] dev: Cap number of queues even with accel_priv

since the actual number of > queues are being reported via real_num_tx_queues. Makes sense. Reviewed-by: Jesse Brandeburg <jesse.brandeb...@intel.com>

Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 2/5] fm10k: Fix VLAN configuration for macvlan offload

traffic without any > issues. Reviewed-by: Jesse Brandeburg <jesse.brandeb...@intel.com>

Re: [Intel-wired-lan] [PATCH] i40e: make const array patterns static, reduces object code size

0, x86-64) > > Signed-off-by: Colin Ian King <colin.k...@canonical.com> Looks good, thanks Colin! Acked-by: Jesse Brandeburg <jesse.brandeb...@intel.com>

Re: [RFC PATCH 00/12] Implement XDP bpf_redirect vairants

On Sun, 16 Jul 2017 10:23:08 +0200 Jesper Dangaard Brouer wrote: > On Tue, 11 Jul 2017 12:37:10 -0700 John Fastabend > wrote: > > [...] > > > > hmm maybe Jesse or Alex have some clues. Adding them to the CC list. > > This seems related to

Re: [Intel-wired-lan] [PATCH] intel: i40e: virtchnl: fix incorrect variable assignment

is > updated at line 1602 just before return, so assigning a value to this > variable in this code block is useless. > > Addresses-Coverity-ID: 1397693 > Signed-off-by: Gustavo A. R. Silva <garsi...@embeddedor.com> Thanks for the fix, looks reasonable. Acked-by: Jesse Brandeburg <jesse.brandeb...@intel.com>

Re: [E1000-devel] jitter / latency reduction

On Mon, 6 Mar 2017 08:09:42 -0800 Mahmood Qazen wrote: > greetings Leonardo > this is the slide / pdf I found and towards the end it asks if we > could help. > enjoy > Mahmood - Hi developers, thanks for your interest, we’d love to have help, but the good/bad news is that this

[PATCH NET] ethtool: silence warning on bit loss

is actually bogus, as no bits are really lost, but we can get rid of the sparse warning with this one small change. Reported-by: Preethi Banala <preethi.ban...@intel.com> Signed-off-by: Jesse Brandeburg <jesse.brandeb...@intel.com> --- include/uapi/linux/ethtool.h | 3 +-- 1 fil

Re: [Intel-wired-lan] [PATCH v2 net-next 0/2] e1000e: fix PTP on e1000_pch_variants

On Sat, 23 Jul 2016 12:44:32 -0400 Jarod Wilson wrote: > This little series factors out the systim sanitization code first, then > adds e1000_pch_lpt as a new case in the switch that calls the sanitize > function, fixing PTP clock issues I've had reported against an Intel >

Re: [net PATCH v2] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet

ed per packet and this would result in 9 DMA buffers. I updated the > code so that we only allow 8 in the case of a single send, otherwise we > go into the function that walks the frags to verify each block. > > I have tested this using rds-stress and it seems to run traffic w

Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet

On Wed, 30 Mar 2016 10:35:55 -0700 Alexander Duyck wrote: > On Wed, Mar 30, 2016 at 10:20 AM, Sowmini Varadhan > wrote: > > On (03/30/16 10:12), Alexander Duyck wrote: > >> Yeah. The patch was sort of a knee-jerk reaction to being told

Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet

On Wed, 30 Mar 2016 10:12:51 -0700 Alexander Duyck wrote: > On Wed, Mar 30, 2016 at 10:00 AM, Sowmini Varadhan > wrote: > > On (03/29/16 23:44), Alexander Duyck wrote: > >> This patch has been sanity checked only. I cannot yet guarantee

Re: [net-next 02/16] i40e/i40evf: Rewrite logic for 8 descriptor per packet check

stupid gmail... sent again to the list, sorry for duplicate (but formatted better this time) Hey Alex, this patch appears to have caused a regression (probably both i40e/i40evf). Easily reproducible running rds-stress (see the thread titled "i40e card Tx resets", the middle post by sowmini has

Re: [PATCH v1] ethtool: properly indent man sub-options

On Thu, 7 Jan 2016 17:50:43 -0800 Jesse Brandeburg <jesse.brandeb...@intel.com> wrote: > The ethtool.8 file was full of lots of incorrectly indented > bits. This fixes the arguments to options to be indented in > a visually appealing way. Hey Ben (ethtool maintainer), I never

Re: WARN trace - skb_warn_bad_offload - vxlan - large udp packet - udp checksum disabled

On Tue, 15 Dec 2015 01:35:27 + "Nelson, Shannon" wrote: > Using a slightly modified version of udpspam (see diff below - hopefully > not mangled by corporate email servers), where I set the SO_NO_CHECK > socket option and can specify a large buffer size, I can

Re: [net-next 09/15] i40e: use priv flags to control packet split

On Sat, Dec 5, 2015 at 1:25 PM, Or Gerlitz wrote: > HDS is a generic feature,and even if you think only Intel hardware is > the only hardware that supports that, you have multiple drivers.. > right? why not go the right way of adding new netdev feature and > enable/disable

Re: [RFC 1/4] net: support per queue tx_usecs in sysfs

On Tue, 1 Dec 2015 14:13:34 -0800 Florian Fainelli wrote: > On 01/12/15 00:01, kan.li...@intel.com wrote: > > From: Kan Liang > > > > Network devices usually have many queues. Each queue has its own > > tx_usecs options. Currently, we can only set all

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Mon, 23 Nov 2015 16:38:59 -0800 Tom Herbert wrote: > >> > > >> > Sorry, I still don't like this. Grant it least it gets rid of of VXLAN > >> > specific ops, but the problem is there no such things as a common set > >> > of encapsulations in the kernel (e.g. foo-over-udp

Re: [PATCH] i40evf: fix 32 bit build warnings

On Tue, 13 Oct 2015 13:37:04 +0200 Arnd Bergmann <a...@arndb.de> wrote: > On Monday 12 October 2015 23:18:21 you wrote: > > On Wed, 2015-10-07 at 22:13 +0200, Arnd Bergmann wrote: > > > Jesse Brandeburg fixed a bug for 32-bit systems in the i40e driver > > > in co

Re: [PATCH] i40evf: fix 32 bit build warnings

Arnd > > Huh are you sure you used by dev-queue branch? I ask because this is > what I am getting when I try to apply your patch: > > git am .apply/i40evf-fix-32-bit-build-warnings.patch > Applying: Jesse Brandeburg fixed a bug for 32-bit systems in the i40e > driver > error

Re: [PATCH] i40evf: fix 32 bit build warnings

On Wed, 7 Oct 2015 22:13:19 +0200 Arnd Bergmann <a...@arndb.de> wrote: > Jesse Brandeburg fixed a bug for 32-bit systems in the i40e driver > in commit 9c70d7cebfec5 ("i40e: fix 32 bit build warnings"), but the > same code still exists in the i40evf driver and causes comp

Re: [PATCH 1/1] i40e: re-use %*ph specifier to hexdump a data

On Fri, 2 Oct 2015 12:18:16 +0300 Andy Shevchenko <andriy.shevche...@linux.intel.com> wrote: > Instead of using a custom approach change the code to use %*ph format > specifier. > > Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com> Nice catch,

Re: [RFC PATCH] Fix false positives in can_checksum_protocol()

On Mon, Sep 28, 2015 at 12:37 PM, Tom Herbert wrote: > On Mon, Sep 28, 2015 at 12:26 PM, David Woodhouse wrote: >> On Mon, 2015-09-28 at 12:13 -0700, Tom Herbert wrote: >>> >>> > Perhaps a better solution would be a bit in the skbuff which indicates >>>

[net-next PATCH] net: fix endian check warning in etherdevice.h

on x86_64) Fixes: 2c722fe1c821 (etherdevice: Optimize a few is_foo_ether_addr functions) Signed-off-by: Jesse Brandeburg jesse.brandeb...@intel.com CC: Joe Perches j...@perches.com --- include/linux/etherdevice.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux

Re: [net-next 07/15] i40e/i40evf: Add TX/RX outer UDP checksum support for X722

On Wed, 5 Aug 2015 17:13:21 -0700 Tom Herbert t...@herbertland.com wrote: On Wed, Aug 5, 2015 at 4:52 PM, Jeff Kirsher jeffrey.t.kirs...@intel.com wrote: From: Anjali Singhai Jain anjali.sing...@intel.com if (vsi-back-flags I40E_FLAG_WB_ON_ITR_CAPABLE)

[PATCH] pktgen: pktgen should not print info that it is spinning

when using pktgen to send delay packets the module prints repeatedly to the kernel log: sleeping for X sleeping for X ... This is probably just a debugging item left in and should not be enabled for regular use of the module. Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] CC: Robert Olsson

[PATCH] ethtool: update license field in specfile to be correctly defined

From: Jesse Brandeburg [EMAIL PROTECTED] The ethtool spec file needs to have the correct syntax license line. Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] --- ethtool.spec.in |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/ethtool.spec.in b/ethtool.spec.in index

Re: 2.6.21rc7 e1000 media-detect oddness.

On 4/15/07, Dave Jones [EMAIL PROTECTED] wrote: I booted up 2.6.21rc7 without an ethernet cable plugged in, and noticed this.. e1000: :02:00.0: e1000_probe: The EEPROM Checksum Is Not Valid e1000: probe of :02:00.0 failed with error -5 I plugged a cable in, did rmmod e1000;modprobe

Re: [BUG] ethX misnumbered and one missing in mii-tool

added netdev. On 3/29/07, Andrei Popa [EMAIL PROTECTED] wrote: In a dual core 2 server with an intel motherboard and 5 network cards(two onboard) and 1 pci express card with two slots and one pci-x pci64 card the kernel sees all of them in dmesg but in mii-tool are misnumbered and one card is

Re: [PATCH 09/15] [TCP]: Introduce tcp_hdrlen() and tcp_optlen()

On 3/13/07, Arnaldo Carvalho de Melo [EMAIL PROTECTED] wrote: Introduce tcp_hdrlen() and tcp_optlen(): The ip_hdrlen() buddy, created to reduce the number of skb-h.th- uses and to avoid the longer, open coded equivalent. +static inline unsigned int tcp_hdrlen(const struct sk_buff *skb) +{ +

Re: [PATCH 09/15] [TCP]: Introduce tcp_hdrlen() and tcp_optlen()

On 3/13/07, Jesse Brandeburg [EMAIL PROTECTED] wrote: acme, good stuff, but does the * 4 generate equivalent assembly with gcc 3/4 as 2 ? I could assume that the compiler would be smart enough, but every time I assume I know what the compiler is doing I get myself in trouble. nevermind, I

Re: meaningful spinlock contention when bound to non-intr CPU?

On 2/1/07, Rick Jones [EMAIL PROTECTED] wrote: snip With some help from Lee Schermerhorn and Alan Brunelle I got a lockmeter kernel going, and it is suggesting that the greatest spinlock contention comes from the routines: SPINLOCKS HOLDWAIT UTIL CONMEAN( MAX )

Re: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)

someone else is testing this kernel on this nic chipset. Upon some further investigation with Allen, I got this info, and it appears that his system is not freeing MSI irq's correctly. from our discussion: Allen wrote: Jesse Brandeburg wrote: I believe you may have an interrupt delivery problem

Re: [2.6 patch] the scheduled eepro100 removal

On 1/2/07, Eric Piel [EMAIL PROTECTED] wrote: Hi, I've been using e100 for years with no problem, however more by curiosity than necessity I'd like to know how will be handled the devices which are (supposedly) supported by eepro100 and not by e100? According to modinfo eepro100 and modinfo

Re: Network drivers that don't suspend on interface down

On 12/20/06, Arjan van de Ven [EMAIL PROTECTED] wrote: Yeah, I guess that's a problem. From a user perspective, the functionality is only really useful if the latency is very small. I think where possible we'd want to power down the chip while keeping the phy up, but it would be nice to

Re: Intel 82559 NIC corrupted EEPROM

On 12/1/06, John [EMAIL PROTECTED] wrote: can you try adding mdelay(100); in e100_eeprom_load before the for loop, and then change the multiple udelay(4) to mdelay(1) in e100_eeprom_read I applied the attached patch. Loading the driver now takes around one minute :-) ouch, but yep, thats

Re: e100 breakage located

sorry for the delay, your mail got marked as spam. In the future please copy networking issues to netdev@vger.kernel.org, and be sure to copy the maintainers of the driver you're having problems with (they are in the MAINTAINERS file) On 11/22/06, Amin Azez [EMAIL PROTECTED] wrote: I notice a

Re: 2.6.19-rc6: irq 48: nobody cared

On 11/16/06, Krzysztof Sierota [EMAIL PROTECTED] wrote: Hi, I'm getting the following in dmesg with 2.6.19-rc5 and 2.6.19-rc6 kernels quad opteron server running 64bit kernel, and the network card gets disabled. On identical server running 32bit kernel, same cards, same slots, same

Re: Intel 82559 NIC corrupted EEPROM

On 11/9/06, John [EMAIL PROTECTED] wrote: The second thought is that the adapter is in D3, and something about your kernel or the driver doesn't successfully wake it up to D0. On my NICs, the EEPROM ID (Word 0Ah) is set to 0x40a2. Thus DDPD (bit 6) is set to 0. DDPD is the Disable Deep Power

Re: Intel 82559 NIC corrupted EEPROM

On 11/8/06, John [EMAIL PROTECTED] wrote: Hello all, [ E-mail address is a bit-bucket. I *do* monitor the mailing lists. ] I will try and summarize the problem as I understand it at this point. I've written two messages so far: http://groups.google.com/group/linux.kernel/msg/3a05d819c66474db

Re: e1000 driver 2.6.18 - how to waste processor cycles

included netdev... On 11/8/06, Jeff V. Merkey [EMAIL PROTECTED] wrote: Is there a good reason the skb refill routine in e1000_alloc_rx_buffers needs to go and touch and remap skb memory on already loaded descriptors/ This seems extremely wasteful of processor cycles when refilling the ring

Re: Strange errors from e1000 driver (2.6.18)

On 10/22/06, Martin J. Bligh [EMAIL PROTECTED] wrote: Martin J. Bligh wrote: I'm getting a lot of these type of errors if I run 2.6.18. If I run the standard Ubuntu Dapper kernel, I don't get them. What do they indicate? Hi Martin, they indicate that you're getting transmit hangs. Means

Re: Strange errors from e1000 driver (2.6.18)

Analysis follows, but I wanted to ask you to bisect back if you can to find the apparent patch to make the difference. Basically at this point I'd say its not likely to be an e1000 issue, but I'd like to follow up and make sure. On 10/22/06, Martin J. Bligh [EMAIL PROTECTED] wrote:

Re: Strange errors from e1000 driver (2.6.18)

On 10/22/06, Martin J. Bligh [EMAIL PROTECTED] wrote: Jesse Brandeburg wrote: Analysis follows, but I wanted to ask you to bisect back if you can to find the apparent patch to make the difference. Basically at this point I'd say its not likely to be an e1000 issue, but I'd like to follow up

Re: [PATCH] e1000: Real time packets and bytes statistics

On 10/11/06, Jean Delvare [EMAIL PROTECTED] wrote: Hi all, This patch is posted for review and comments. Let the e1000 driver report the most important statistics (rx/tx_bytes and rx/tx_packets) in real time, rather than every other second. This is similar to what the e100 driver is doing.

Re: Network problem with 2.6.18-mm1 ?

On 9/28/06, Sukadev Bhattiprolu [EMAIL PROTECTED] wrote: $ cat /proc/interrupts CPU0 CPU1 28: 0 0 IO-APIC-fasteoi eth0 NMI: 96 35 LOC: 18251 18524 ERR: 0 you should be getting an interrupt every two seconds from the

Re: Network problem with 2.6.18-mm1 ?

On 9/28/06, Sukadev Bhattiprolu [EMAIL PROTECTED] wrote: Thanks. See below for additional info Auke Kok [EMAIL PROTECTED] wrote: | Sukadev Bhattiprolu wrote: | | I am unable to get networking to work with 2.6.18-mm1 on my system. | | But 2.6.18 kernel on same system works fine. Here is some

Re: e1000 Detected Tx Unit Hang

On 9/3/06, Paul Aviles [EMAIL PROTECTED] wrote: Hey Jesse, thanks for your reply. Here is the stuff on /procs. The weird no problem, part is that I have several other identical systems and only one is affected. Today I moved the hard drive to another similar system and I am not seeing the

Re: e1000 Detected Tx Unit Hang

On 9/2/06, Paul Aviles [EMAIL PROTECTED] wrote: I am getting e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang using stock 2.6.17.11, 2.6.17.5 or 2.6.17.4 kernels on centos 4.3. The server is a Tyan GS12 ( 82541GI/PI and 82547GI) and is connected to a Netgear GS724T Gig switch. I can

Re: myri10ge conversion to non-contiguous skb

On 8/24/06, Brice Goglin [EMAIL PROTECTED] wrote: During the submission of the myri10ge driver, some people raised the question of using pages (or any kind of non-contiguous skb) instead of our current 16kB contiguous skb. We are looking at this right now and it is not clear what solution is the

Re: [RFC] avoid unnecessary alignement overhead in skb-data allocation.

On 8/7/06, Herbert Xu [EMAIL PROTECTED] wrote: On Mon, Aug 07, 2006 at 11:31:03AM +0400, Evgeniy Polyakov wrote: Only if they form contiguous region? Jesse, is it possible for every e1000 chip to split frame into several page-sized chunks i.e. create some kind of receiving scatter-gather?

Re: [PATCH] move skb-dev assignment into netdev_alloc_skb

On 8/7/06, David Miller [EMAIL PROTECTED] wrote: From: Christoph Hellwig [EMAIL PROTECTED] Date: Sat, 5 Aug 2006 15:01:09 +0200 All caller of netdev_alloc_skb need to assign skb-dev shortly afterwards. Move it into common code. I also had to fixup a little bit of the surrounding control

Re: [PATCH] Replace pci_module_init with pci_register_driver in drivers/net

/ixgb changes. (Jesse heads off to change his out of tree driver kcompat.h) Acked-by: Jesse Brandeburg [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [e1000]: Remove unnecessary tx_lock

On 8/6/06, jamal [EMAIL PROTECTED] wrote: Q: Do you know the historical context of why TX_WAKE_THRESHOLD and E1000_TX_WEIGHT are hard-coded (and not for example related to the size of the ring)? Jesse? Otherwise i would like to submit a patch for the above. eventually probably even allow the

Re: [RFC] driver adjusts qlen, increases CPU

On 8/4/06, Rick Jones [EMAIL PROTECTED] wrote: Problem we've seen is that setting this shorter queue causes a large spike in cpu when transmitting using UDP: 100Mb/s link txqueuelen: 1000 Throughput: 92.44 CPU: 5.00 txqueuelen: 100 Throughput: 93.80 CPU: 61.59 Is this expected? any

Re: problems with e1000 and jumboframes

On 8/4/06, Evgeniy Polyakov [EMAIL PROTECTED] wrote: On Fri, Aug 04, 2006 at 08:34:46AM -0700, Chris Leech ([EMAIL PROTECTED]) wrote: So how many skb allocation schemes do you code into a single driver? Kmalloc everything, page alloc everything, combination of kmalloc and page buffers for

Re: jumbo frames and memory fragmentation

On 6/30/06, Chris Friesen [EMAIL PROTECTED] wrote: Evgeniy Polyakov wrote: It definitely will. Packet split in hardware means separating data and headers into different pages in different reads, while software page split means that skb has a list of fragments where part of the packet will

Re: [PATCH 11/21] e1000: disable CRC stripping workaround

On 6/21/06, Ben Greear [EMAIL PROTECTED] wrote: Kok, Auke wrote: CRC stripping is breaking SMBUS-connected BMC's. We disable this feature to make it work. This fixes related bugs regarding SOL. Shouldn't you also have to subtract 4 bytes when setting the skb len in the receive logic? Perhaps

Re: [PATCH 11/21] e1000: disable CRC stripping workaround

On 6/22/06, Ben Greear [EMAIL PROTECTED] wrote: Jesse Brandeburg wrote: On 6/21/06, Ben Greear [EMAIL PROTECTED] wrote: Kok, Auke wrote: CRC stripping is breaking SMBUS-connected BMC's. We disable this feature to make it work. This fixes related bugs regarding SOL. Shouldn't you also

Re: Intel ixgb driver bug in linux-2.6.17-rc6-mm2

On 6/20/06, Linas Vepstas [EMAIL PROTECTED] wrote: Hi, I sat down to do some testing of the ixgb driver a few days ago, and get failures within seconds. From what I can tell, I'm getting either a DMA to a bad address or some other PCI bus error, not sure which. The problem appears to happen

Re: soft lockup detected with 2.6.16 kernel + e1000 driver under load

On 6/20/06, Massimiliano Poletto [EMAIL PROTECTED] wrote: Shaw Vrana asked me to resend the message below (originally posted to lkml) to this list. Note that I managed to make the problem go away by adding the boot options pci=usepirqmask acpi=noirq. I got the hint by reading dmesg output and

Re: [PATCH 03/16] 64bit resource: fix up printks for resources in networks drivers

First, added netdev, On 6/12/06, Greg KH [EMAIL PROTECTED] wrote: From: Greg Kroah-Hartman [EMAIL PROTECTED] This is needed if we wish to change the size of the resource structures. Based on an original patch from Vivek Goyal [EMAIL PROTECTED] Cc: Vivek Goyal [EMAIL PROTECTED] Cc: Andrew

Re: [PATCH 2.6.17-rc6] Remove Prism II support from Orinoco

On 6/12/06, John W. Linville [EMAIL PROTECTED] wrote: On Mon, Jun 12, 2006 at 01:49:54AM +0300, Faidon Liambotis wrote: Having two drivers supporting the same set of hardware seems pretty pointless to me. Plus, it confuses hotplugging/automatic detection. This subject comes-up from time to

Re: [patch, -rc5-mm1] lock validator: special locking: net/ipv4/igmp.c #2

On 5/31/06, Ingo Molnar [EMAIL PROTECTED] wrote: * Jesse Brandeburg [EMAIL PROTECTED] wrote: well, when running e1000 through some code paths on FC4 + 2.6.17-rc5-mm1 + ingo's latest rollup patch, with this lockdep debug option enabled I got this: e1000: eth1: e1000_watchdog_task: NIC Link

2.6.17-rc5-mm1 lockdep output

well, when running e1000 through some code paths on FC4 + 2.6.17-rc5-mm1 + ingo's latest rollup patch, with this lockdep debug option enabled I got this: e1000: eth1: e1000_watchdog_task: NIC Link is Up 1000 Mbps Full Duplex == [ BUG: bad unlock ordering

Re: e1000 poor network performance - 2.6.17-rc5-g705af309

On 5/26/06, Aravind Gottipati [EMAIL PROTECTED] wrote: Hi, I recently started running linux on a new x60 thinkpad and started noticing really poor network performance with this kernel. I saw some archived threads from a while back saying this could be related to conntracking. Disabled that

  1   2   3   >