RE: [RFC 5/5] i40e/ethtool: support coalesce setting by queue

> From: Liang, Kan > Sent: Friday, December 18, 2015 1:06 PM > > Hi sln, > > Thanks for the comments. I will fix it in V2. > > Could you please check if the following code can find and set/get vector > correctly? > > Get rx_usecs and tx_usecs per queue > > + if (queue > 0) { > +

RE: [RFC 5/5] i40e/ethtool: support coalesce setting by queue

> From: Kan Liang > > This patch implements set_per_queue_coalesce for i40e driver. > For i40e driver, only rx and tx usecs has per queue value. Changing > these two parameters only impact the specific queue. For other interrupt > coalescing parameters, they are shared among

RE: [RFC 4/5] i40e/ethtool: support coalesce getting by queue

> From: Kan Liang > > This patch implements get_per_queue_coalesce for i40e driver. > For i40e driver, only rx and tx usecs has per queue value. So only these > two parameters are read from specific registers. For other interrupt > coalescing parameters, they are shared

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

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 reliably get the following WARN trace. I have reproduced this on both ixgbe and i40e drivers

RE: [PATCH v6] i40e: Look up MAC address in Open Firmware or IDPROM

> From: David Miller [mailto:da...@davemloft.net] > Sent: Thursday, November 05, 2015 8:29 AM > > From: Sowmini Varadhan > Date: Thu, 5 Nov 2015 11:28:31 -0500 > > > On (11/05/15 11:05), David Miller wrote: > >> From: David Miller > >> Date:

RE: [PATCH v5] i40e: Look up MAC address in Open Firmware or IDPROM

> From: Sowmini Varadhan [mailto:sowmini.varad...@oracle.com] > Sent: Wednesday, November 04, 2015 11:40 AM > > > This is the i40e equivalent of commit c762dff24c06 ("ixgbe: Look up MAC > address in Open Firmware or IDPROM"). > > As with that fix, attempt to look up the MAC address in Open

RE: [PATCH v5] i40e: Look up MAC address in Open Firmware or IDPROM

> From: Andy Shevchenko [mailto:andy.shevche...@gmail.com] > Sent: Wednesday, November 04, 2015 11:59 AM > > On Wed, Nov 4, 2015 at 9:39 PM, Sowmini Varadhan > wrote: > > > > This is the i40e equivalent of commit c762dff24c06 ("ixgbe: Look up MAC > > address in Open

RE: [PATCH v6] i40e: Look up MAC address in Open Firmware or IDPROM

> From: Sowmini Varadhan [mailto:sowmini.varad...@oracle.com] > Sent: Wednesday, November 04, 2015 3:21 PM > > This is the i40e equivalent of commit c762dff24c06 ("ixgbe: Look up MAC > address in Open Firmware or IDPROM"). > > As with that fix, attempt to look up the MAC address in Open Firmware

RE: [PATCH v3 net] i40e: Look up MAC address in Open Firmware or IDPROM

> -Original Message- > From: Sowmini Varadhan [mailto:sowmini.varad...@oracle.com] > Sent: Sunday, November 01, 2015 4:07 PM > > On (11/01/15 21:03), Nelson, Shannon wrote: > > .. In the meantime, be sure to test what happens over a reset, such as > what

RE: [PATCH v4 RFC net] i40e: Look up MAC address in Open Firmware or IDPROM

> -Original Message- > From: Sowmini Varadhan [mailto:sowmini.varad...@oracle.com] > Sent: Sunday, November 01, 2015 8:25 AM > > This is the i40e equivalent of commit c762dff24c06 ("ixgbe: Look up MAC > address in Open Firmware or IDPROM"). > > As with that fix, attempt to look up the

RE: [PATCH v3 net] i40e: Look up MAC address in Open Firmware or IDPROM

> -Original Message- > From: Sowmini Varadhan [mailto:sowmini.varad...@oracle.com] > Sent: Sunday, November 01, 2015 8:24 AM > [...] > So I figured out why it all "seemed to work" - my test env had another > obscure init process that was marking the link promiscuous. I guess > that was

RE: [PATCH v3 net] i40e: Look up MAC address in Open Firmware or IDPROM

> -Original Message- > From: Sowmini Varadhan [mailto:sowmini.varad...@oracle.com] > Sent: Friday, October 30, 2015 12:25 PM > > On (10/30/15 18:57), Nelson, Shannon wrote: > > > > > > > > Going along with this being the equivalent of the ixgbe

RE: [PATCH v3 net] i40e: Look up MAC address in Open Firmware or IDPROM

> -Original Message- > From: Sowmini Varadhan [mailto:sowmini.varad...@oracle.com] > Sent: Friday, October 30, 2015 11:37 AM > To: > Subject: Re: [PATCH v3 net] i40e: Look up MAC address in Open Firmware or > IDPROM > > On (10/30/15 18:28), Nelson, Shannon wr

RE: [PATCH v3 net] i40e: Look up MAC address in Open Firmware or IDPROM

> -Original Message- > From: Sowmini Varadhan [mailto:sowmini.varad...@oracle.com] > Sent: Friday, October 30, 2015 8:04 AM > To: > Subject: [PATCH v3 net] i40e: Look up MAC address in Open Firmware or IDPROM > > > This is the i40e equivalent of commit c762dff24c06 ("ixgbe: Look up MAC

RE: [PATCH] intel: i40e: fix confused code

> From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk] > Sent: Tuesday, October 20, 2015 12:22 AM > > On Mon, Oct 19 2015, "Nelson, Shannon" <shannon.nel...@intel.com> wrote: > > >> From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk] >

RE: [PATCH] intel: i40e: fix confused code

> -Original Message- > From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk] > Sent: Saturday, October 17, 2015 1:58 PM > Subject: [PATCH] intel: i40e: fix confused code > > This code is pretty confused. The variable name 'bytes_not_copied' > clearly indicates that the programmer knew

RE: [PATCH] intel: i40e: fix confused code

> From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk] > Sent: Saturday, October 17, 2015 1:58 PM > Subject: [PATCH] intel: i40e: fix confused code > > This code is pretty confused. The variable name 'bytes_not_copied' > clearly indicates that the programmer knew the semantics of >

[PATCH -mm] [RFC] I/OAT: Handle incoming udp through ioatdma

[RFC] I/OAT: Handle incoming udp through ioatdma From: Shannon Nelson [EMAIL PROTECTED] If the incoming udp packet is larger than sysctl_udp_dma_copybreak, try pushing it through the ioatdma asynchronous memcpy. This is very much the same as the tcp copy offload. This is an RFC because we know

RE: [PATCH -mm] [RFC] I/OAT: Handle incoming udp through ioatdma

From: J Hadi Salim [mailto:[EMAIL PROTECTED] On Behalf Of jamal On Thu, 2007-29-11 at 12:08 -0800, Nelson, Shannon wrote: [RFC] I/OAT: Handle incoming udp through ioatdma From: Shannon Nelson [EMAIL PROTECTED] If the incoming udp packet is larger than sysctl_udp_dma_copybreak, try

RE: [2.6 patch] unexport softnet_data

From: David Miller [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 06, 2007 11:41 PM From: Nelson, Shannon [EMAIL PROTECTED] Date: Fri, 26 Oct 2007 08:38:55 -0700 There is no creation of a pinned_list yet in this path, so I don't think this would do us much good. The pinned list

RE: [2.6 patch] unexport softnet_data

-Original Message- From: David Miller [mailto:[EMAIL PROTECTED] From: Adrian Bunk [EMAIL PROTECTED] Date: Wed, 24 Oct 2007 18:24:25 +0200 The EXPORT_PER_CPU_SYMBOL(softnet_data) is no longer used. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] I wanted to apply this, but in validing

RE: net-2.6.24 plans

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Miller Sent: Monday, September 17, 2007 2:18 PM To: netdev@vger.kernel.org Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: net-2.6.24 plans [...] Andrew, I removed the troublesome IOAT patch. The only

[PATCH] IOAT: Fix ioatdma descriptor cache miss

(copying from linux-kernel to net-dev) The layout for struct ioat_desc_sw is non-optimal and causes an extra cache hit for every descriptor processed. By tightening up the struct layout and removing one item, we pull in the fields that get used in the speedpath and get a little better

RE: NET_DMA: where do we ever call dma_skb_copy_datagram_iovec() with NULL pinned_list?

Al Viro: AFAICS, all callers of dma_skb_copy_datagram_iovec() are either * recursive for fragments, pass pinned_list unchanged or * called from tcp, with pinned_list coming from tp-ucopy.pinned_list and only when tp-ucopy.dma_chan is non-NULL. Now, all non-NULL assignments