[net-next PATCH RFC 11/26] arch/metag: Add option to skip DMA sync as a part of map and unmap

This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to avoid invoking cache line invalidation if the driver will just handle it via a sync_for_cpu or sync_for_device call. Cc: James Hogan <james.ho...@imgtec.com> Cc: linux-me...@vger.kernel.org Signed-off-by: Alexander

[net-next PATCH RFC 12/26] arch/microblaze: Add option to skip DMA sync as a part of map and unmap

This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to avoid invoking cache line invalidation if the driver will just handle it via a sync_for_cpu or sync_for_device call. Cc: Michal Simek <mon...@monstr.eu> Signed-off-by: Alexander Duyck <alexander.h.du...@intel.com&g

[net-next PATCH RFC 16/26] arch/parisc: Add option to skip DMA sync as a part of map and unmap

x.de> Cc: linux-par...@vger.kernel.org Signed-off-by: Alexander Duyck <alexander.h.du...@intel.com> --- arch/parisc/kernel/pci-dma.c | 20 +++- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/arch/parisc/kernel/pci-dma.c b/arch/parisc/kernel/pci-dma.c index 02d9ed

[net-next PATCH RFC 14/26] arch/nios2: Add option to skip DMA sync as a part of map and unmap

This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to avoid invoking cache line invalidation if the driver will just handle it via a sync_for_cpu or sync_for_device call. Cc: Ley Foon Tan <lf...@altera.com> Signed-off-by: Alexander Duyck <alexander.h.du...@intel.com&g

[net-next PATCH RFC 04/26] arch/arm: Add option to skip sync on DMA map and unmap

The use of DMA_ATTR_SKIP_CPU_SYNC was not consistent across all of the DMA APIs in the arch/arm folder. This change is meant to correct that so that we get consistent behavior. Cc: Russell King <li...@armlinux.org.uk> Signed-off-by: Alexander Duyck <alexander.h.du...@intel.com> -

[net-next PATCH RFC 18/26] arch/sh: Add option to skip DMA sync as a part of mapping

t; Cc: linux...@vger.kernel.org Signed-off-by: Alexander Duyck <alexander.h.du...@intel.com> --- arch/sh/kernel/dma-nommu.c |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/sh/kernel/dma-nommu.c b/arch/sh/kernel/dma-nommu.c index eadb669..47fee3b 100644 --- a/arch/sh/kernel

Re: [Intel-wired-lan] [PATCH V3 RFC 2/2] ixgbe: ixgbe_atr() compute l4_proto only if non-paged data has network/transport headers

ed-off-by: Sowmini Varadhan <sowmini.varad...@oracle.com> This all looks correct to me. I would recommend having Jeff pull it in to be submitted to the net queue. Reviewed-by: Alexander Duyck <alexander.h.du...@intel.com>

Re: [Intel-wired-lan] [PATCH V2 RFC 2/2] ixgbe: ixgbe_atr() compute l4_proto only if non-paged data has network/transport headers

On Mon, Oct 17, 2016 at 12:18 PM, Sowmini Varadhan <sowmini.varad...@oracle.com> wrote: > On (10/17/16 11:15), Alexander Duyck wrote: >> I would say you probably only need the first check here for skb->data >> and could probably skip the second part. You will be testing

Re: [Intel-wired-lan] [PATCH V2 RFC 2/2] ixgbe: ixgbe_atr() compute l4_proto only if non-paged data has network/transport headers

On Mon, Oct 17, 2016 at 10:25 AM, Sowmini Varadhan wrote: > For some Tx paths (e.g., tpacket_snd()), ixgbe_atr may be > passed down an sk_buff that has the network and transport > header in the paged data, so it needs to make sure these > headers are available in the

Re: [Intel-wired-lan] Kernel 4.6.7-rt13: Intel Ethernet driver igb causes huge latencies in cyclictest

On Mon, Oct 17, 2016 at 8:00 AM, Koehrer Mathias (ETAS/ESW5) wrote: > Hi Julia! >> > > Have you tested on a vanilla (non-RT) kernel? I doubt there is >> > > anything RT specific about what you are seeing, but it might be nice >> > > to get confirmation. Also, bisection

Re: igb driver can cause cache invalidation of non-owned memory?

On Thu, Oct 13, 2016 at 4:00 AM, Nikita Yushchenko wrote: It would make more sense to update the DMA API for __dma_page_cpu_to_dev on ARM so that you don't invalidate the cache if the direction is DMA_FROM_DEVICE. >>> >>> No, in generic case it's

Re: igb driver can cause cache invalidation of non-owned memory?

On Wed, Oct 12, 2016 at 11:12 AM, Nikita Yushchenko wrote: >> It would make more sense to update the DMA API for >> __dma_page_cpu_to_dev on ARM so that you don't invalidate the cache if >> the direction is DMA_FROM_DEVICE. > > No, in generic case it's unsafe. > >

Re: igb driver can cause cache invalidation of non-owned memory?

On Wed, Oct 12, 2016 at 9:11 AM, Nikita Yushchenko wrote: To get some throughput improvement, I propose removal of that sync_for_device() before reusing buffer. Will you accept such a patch ;) >>> >>> Not one that gets rid of sync_for_device() in the

Re: igb driver can cause cache invalidation of non-owned memory?

On Tue, Oct 11, 2016 at 11:55 PM, Nikita Yushchenko wrote: The main reason why this isn't a concern for the igb driver is because we currently pass the page up as read-only. We don't allow the stack to write into the page by keeping the page count

Re: [PATCH kernel v2] PCI: Enable access to custom VPD for Chelsio devices (cxgb3)

On Mon, Oct 10, 2016 at 9:08 PM, Alexey Kardashevskiy <a...@ozlabs.ru> wrote: > On 11/10/16 02:23, Alexander Duyck wrote: >> On Wed, Sep 28, 2016 at 10:21 PM, Alexey Kardashevskiy <a...@ozlabs.ru> >> wrote: >>> There is at least one Chelsio 10Gb card which us

Re: igb driver can cause cache invalidation of non-owned memory?

On Mon, Oct 10, 2016 at 10:00 AM, Nikita Yushchenko wrote: > Hi Alexander > > Thanks for your explanation. > >> The main reason why this isn't a concern for the igb driver is because >> we currently pass the page up as read-only. We don't allow the stack >> to

Re: [PATCH kernel v2] PCI: Enable access to custom VPD for Chelsio devices (cxgb3)

On Wed, Sep 28, 2016 at 10:21 PM, Alexey Kardashevskiy wrote: > There is at least one Chelsio 10Gb card which uses VPD area to store > some custom blocks (example below). However pci_vpd_size() returns > the length of the first block only assuming that there can be only > one VPD

Re: igb driver can cause cache invalidation of non-owned memory?

On Mon, Oct 10, 2016 at 5:27 AM, Nikita Yushchenko wrote: >>> Hmm... I'm not about device writing to memory. >> >> This absolutely is about whether the device wrote into the >> area or not. > > Not only. > >>> Sequence in igb driver is: >>> >>> dma_map(full_page)

[net-next PATCH v2] i40e: Clean up handling of msglevel flags and debug parameter

-by: Alexander Duyck <alexander.h.du...@intel.com> --- v2: Consolidated setup for msg_enable and hw.debug_mask to one point in probe. drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 18 -- drivers/net/ethernet/intel/i40e/i40e_ethtool.c |7 ++- drivers/net/ethernet

[net-next PATCH] i40e: Clean up handling of msg_enable flags and debug parameter

-by: Alexander Duyck <alexander.h.du...@intel.com> --- So I am running this through a slightly different process than standard because there are some items here that might be objectionable so I want to have that ironed out before I deal with the out-of-tree Intel driver. I just want to

Re: [PATCH net-next] net/vxlan: Avoid unaligned access in vxlan_build_skb()

On Wed, Sep 28, 2016 at 10:03 AM, Sowmini Varadhan <sowmini.varad...@oracle.com> wrote: > On (09/23/16 17:43), Alexander Duyck wrote: >> > On (09/23/16 10:38), Alexander Duyck wrote: > ; >> >> almost think of it as us doing something like the inverse of &

Re: [net-next 5/5] PCI: disable FLR for 82579 device

Since I worked with Sasha on this I will provide a bit of information from what I understand of this bug as well. On Tue, Sep 27, 2016 at 12:13 PM, Alex Williamson wrote: > On Tue, 27 Sep 2016 13:17:02 -0500 > Bjorn Helgaas wrote: > >> On Sun, Sep

Re: [Intel-wired-lan] [PATCH net-next v2 1/2] i40e: remove superfluous I40E_DEBUG_USER statement

On Sat, Sep 24, 2016 at 4:13 AM, Stefan Assmann <sassm...@kpanic.de> wrote: > On 24.09.2016 04:48, Alexander Duyck wrote: >> On Fri, Sep 23, 2016 at 6:30 AM, Stefan Assmann <sassm...@kpanic.de> wrote: >>> This debug statement is confusing and never set in the cod

Re: [Intel-wired-lan] [PATCH net-next v2 2/2] i40e: fix setting debug parameter early

On Fri, Sep 23, 2016 at 6:30 AM, Stefan Assmann wrote: > pf->msg_enable is a bitmask, therefore assigning the value of the > "debug" parameter is wrong. It is initialized again later in > i40e_sw_init() so it didn't cause any problem, except that we missed > early debug

Re: [Intel-wired-lan] [PATCH net-next v2 1/2] i40e: remove superfluous I40E_DEBUG_USER statement

On Fri, Sep 23, 2016 at 6:30 AM, Stefan Assmann wrote: > This debug statement is confusing and never set in the code. Any debug > output should be guarded by the proper I40E_DEBUG_* statement which can > be enabled via the debug module parameter or ethtool. > Remove or convert

Re: [PATCH net-next] net/vxlan: Avoid unaligned access in vxlan_build_skb()

On Fri, Sep 23, 2016 at 4:41 PM, Sowmini Varadhan <sowmini.varad...@oracle.com> wrote: > On (09/23/16 10:38), Alexander Duyck wrote: >> >> So basically what I was thinking is we do something like reserving >> NET_IP_ALIGN and continue writing headers to skb->data

Re: [PATCH net-next] net/vxlan: Avoid unaligned access in vxlan_build_skb()

On Fri, Sep 23, 2016 at 10:20 AM, Sowmini Varadhan <sowmini.varad...@oracle.com> wrote: > On (09/23/16 07:17), Alexander Duyck wrote: >> >> Is this basically about, e.g., putting the vxlanhdr in its own >> >> skb_frag_t, or something else? >> > >> &g

Re: [PATCH RFC 05/11] skbuff: Extend gso_type to unsigned int.

On Fri, Sep 23, 2016 at 6:19 AM, David Laight wrote: > From: Steffen Klassert >> Sent: 23 September 2016 08:54 >> All available gso_type flags are currently in use, >> so extend gso_type to be able to add further flags. >> >> Signed-off-by: Steffen Klassert

Re: [PATCH net-next] net/vxlan: Avoid unaligned access in vxlan_build_skb()

's trick, by pushing >>> the headers into the frag list, forcing a pull and realignment >>> by the next protocol layer. >> >> What is the "Alexander Duyck trick" (hints about module or commit id, >> where this can be found, please)? >> >> I

Re: [RFC] PCI: Allow sysfs control over totalvfs

On Tue, Sep 20, 2016 at 8:49 AM, Yuval Mintz wrote: > [Sorry in advance if this was already discussed in the past] > > Some of the HW capable of SRIOV has resource limitations, where the > PF and VFs resources are drawn from a common pool. > In some cases, these

Re: [PATCH net-next v6] gso: Support partial splitting at the frag_list pointer

ket. > > > net/core/skbuff.c | 51 > +++--- > net/ipv4/af_inet.c | 14 ++ > net/ipv4/gre_offload.c | 6 -- > net/ipv4/tcp_offload.c | 13 +++-- > net/ipv4/udp_offload.c | 6 -- > net/ipv6/ip6_offload.c | 5 - > 6 files changed, 69 insertions(+), 26 deletions(-) Looks good. Acked-by: Alexander Duyck <alexander.h.du...@intel.com>

Re: [Intel-wired-lan] [net-next PATCH v3 1/3] e1000: track BQL bytes regardless of skb or not

On Mon, Sep 12, 2016 at 9:25 PM, Tom Herbert <t...@herbertland.com> wrote: > On Mon, Sep 12, 2016 at 8:00 PM, Alexander Duyck > <alexander.du...@gmail.com> wrote: >> On Mon, Sep 12, 2016 at 3:13 PM, John Fastabend >> <john.fastab...@gmail.com> wrote: >>&g

Re: [RFC V3 PATCH 03/26] net/netpolicy: get device queue irq information

On Tue, Sep 13, 2016 at 5:23 AM, Liang, Kan wrote: >> >> Hello. >> >> On 09/12/2016 05:55 PM, kan.li...@intel.com wrote: >> >> > From: Kan Liang >> > >> > Net policy needs to know device information. Currently, it's enough to >> > only get irq

Re: [Intel-wired-lan] [net-next PATCH v3 2/3] e1000: add initial XDP support

On Mon, Sep 12, 2016 at 3:13 PM, John Fastabend wrote: > From: Alexei Starovoitov > > This patch adds initial support for XDP on e1000 driver. Note e1000 > driver does not support page recycling in general which could be > added as a further improvement.

Re: [Intel-wired-lan] [net-next PATCH v3 1/3] e1000: track BQL bytes regardless of skb or not

On Mon, Sep 12, 2016 at 3:13 PM, John Fastabend wrote: > The BQL API does not reference the sk_buff nor does the driver need to > reference the sk_buff to calculate the length of a transmitted frame. > This patch removes an sk_buff reference from the xmit irq path and >

Re: [PATCH net-next v5] gso: Support partial splitting at the frag_list pointer

On Fri, Sep 9, 2016 at 12:25 AM, Steffen Klassert wrote: > Since commit 8a29111c7 ("net: gro: allow to build full sized skb") > gro may build buffers with a frag_list. This can hurt forwarding > because most NICs can't offload such packets, they need to be >

Re: [PATCH net-next v4] gso: Support partial splitting at the frag_list pointer

On Thu, Sep 8, 2016 at 4:33 AM, Steffen Klassert wrote: > Since commit 8a29111c7 ("net: gro: allow to build full sized skb") > gro may build buffers with a frag_list. This can hurt forwarding > because most NICs can't offload such packets, they need to be > segmented

Re: XPS configuration question (on tg3)

On Tue, Sep 6, 2016 at 11:46 AM, Michal Soltys wrote: > Hi, > > I've been testing different configurations and I didn't manage to get XPS to > "behave" correctly - so I'm probably misunderstanding or forgetting > something. The nic in question (under tg3 driver - BCM5720 and

Re: [RFC PATCH kernel] PCI: Enable access to custom VPD for Chelsio devices (cxgb3)

On Tue, Sep 6, 2016 at 8:48 AM, Bjorn Helgaas wrote: > Hi Alexey, > > On Thu, Aug 11, 2016 at 08:03:29PM +1000, Alexey Kardashevskiy wrote: >> There is at least one Chelsio 10Gb card which uses VPD area to store >> some custom blocks (example below). However pci_vpd_size()

Re: [PATCH net-next v3] gso: Support partial splitting at the frag_list pointer

On Mon, Sep 5, 2016 at 3:47 AM, Steffen Klassert wrote: > Since commit 8a29111c7 ("net: gro: allow to build full sized skb") > gro may build buffers with a frag_list. This can hurt forwarding > because most NICs can't offload such packets, they need to be > segmented

Re: [PATCH net-next v2] gso: Support partial splitting at the frag_list pointer

On Fri, Sep 2, 2016 at 12:25 AM, Steffen Klassert <steffen.klass...@secunet.com> wrote: > On Wed, Aug 31, 2016 at 10:25:59AM -0700, Alexander Duyck wrote: >> On Wed, Aug 31, 2016 at 3:41 AM, Steffen Klassert >> <steffen.klass...@secunet.com> wrote: >> > >&

Re: [PATCH net-next 4/4] xps_flows: XPS for packets that don't have a socket

On Thu, Sep 1, 2016 at 8:56 AM, Tom Herbert <t...@herbertland.com> wrote: > On Thu, Sep 1, 2016 at 8:36 AM, Alexander Duyck > <alexander.du...@gmail.com> wrote: >> On Wed, Aug 31, 2016 at 5:10 PM, Tom Herbert <t...@herbertland.com> wrote: >>> xps_

Re: [PATCH net-next 4/4] xps_flows: XPS for packets that don't have a socket

On Wed, Aug 31, 2016 at 5:10 PM, Tom Herbert wrote: > xps_flows maintains a per device flow table that is indexed by the > skbuff hash. The table is only consulted when there is no queue saved in > a transmit socket for an skbuff. > > Each entry in the flow table contains a

Re: [PATCH net-next v2] gso: Support partial splitting at the frag_list pointer

On Wed, Aug 31, 2016 at 3:41 AM, Steffen Klassert wrote: > Since commit 8a29111c7 ("net: gro: allow to build full sized skb") > gro may build buffers with a frag_list. This can hurt forwarding > because most NICs can't offload such packets, they need to be >

Re: [RFC PATCH 3/5] bnx2x: Add support for segmentation of tunnels with outer checksums

On Wed, Aug 31, 2016 at 4:31 AM, Yuval Mintz wrote: > One question I have regarding the feature, regarding the > partial offload compatible with ndo_features_check(). > > Consider the following example - > Let's assume my adapter is capable of doing outer-csum validation >

Re: [PATCH RFC 4/4] xfs: Transmit flow steering

On Tue, Aug 30, 2016 at 5:00 PM, Tom Herbert wrote: > XFS maintains a per device flow table that is indexed by the skbuff > hash. The XFS table is only consulted when there is no queue saved in > a transmit socket for an skbuff. > > Each entry in the flow table contains a

Re: [PATCH net-next v1] gso: Support partial splitting at the frag_list pointer

On Thu, Aug 25, 2016 at 4:00 AM, Steffen Klassert wrote: > diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c > index 989a362..ac46233 100644 > --- a/net/ipv4/af_inet.c > +++ b/net/ipv4/af_inet.c > @@ -1190,7 +1190,7 @@ EXPORT_SYMBOL(inet_sk_rebuild_header); >

Re: [PATCH net-next v1] gso: Support partial splitting at the frag_list pointer

On Fri, Aug 26, 2016 at 1:36 PM, Shmulik Ladkani <shmulik.ladk...@gmail.com> wrote: > Hi, > > On Thu, 25 Aug 2016 13:00:19 +0200 Steffen Klassert > <steffen.klass...@secunet.com> wrote: >> On Wed, Aug 24, 2016 at 09:27:54AM -0700, Alexander Duyck wrote: >>

Re: [PATCH net-next] documentation: Document issues with VMs and XPS and drivers enabling it on their own

tx-/xps_cpus > > +However, some NIC drivers will configure XPS at runtime for the > +interfaces they drive, via a call to netif_set_xps_queue. > + > == Suggested Configuration > > For a network device with a single transmission queue, XPS configuration So other than the one typo the rest of this looks good to me. Reviewed-by: Alexander Duyck <alexander.h.du...@intel.com>

Re: [RFC PATCH] net: Require socket to allow XPS to set queue mapping

On Thu, Aug 25, 2016 at 1:32 PM, Rick Jones <rick.jon...@hpe.com> wrote: > On 08/25/2016 12:49 PM, Eric Dumazet wrote: >> >> On Thu, 2016-08-25 at 12:23 -0700, Alexander Duyck wrote: >>> >>> A simpler approach is provided with this patch. With it w

Re: A second case of XPS considerably reducing single-stream performance

On Thu, Aug 25, 2016 at 1:18 PM, Rick Jones <rick.jon...@hpe.com> wrote: > On 08/25/2016 12:19 PM, Alexander Duyck wrote: >> >> The problem is that there is no socket associated with the guest from >> the host's perspective. This is resulting in the traffic bouncin

Re: A second case of XPS considerably reducing single-stream performance

On Wed, Aug 24, 2016 at 4:46 PM, Rick Jones wrote: > Also, while it doesn't seem to have the same massive effect on throughput, I > can also see out of order behaviour happening when the sending VM is on a > node with a ConnectX-3 Pro NIC. Its driver is also enabling XPS it

[RFC PATCH] net: Require socket to allow XPS to set queue mapping

or bridging situations in which XPS is likely more of a hinderance than a help. Signed-off-by: Alexander Duyck <alexander.h.du...@intel.com> --- net/core/dev.c | 28 +++- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/net/core/dev.c b/net/core/dev.c

Re: [RFC PATCH 3/5] bnx2x: Add support for segmentation of tunnels with outer checksums

t;> >> functionality allowing us to to segment tunneled frames that have an outer >> checksum. >> >> >> >> Signed-off-by: Alexander Duyck <adu...@mirantis.com> >> > >> > So it took me some [well, a lot] time to reach this, but I've finally &g

Re: [PATCH net-next v1] gso: Support partial splitting at the frag_list pointer

On Thu, Aug 25, 2016 at 4:00 AM, Steffen Klassert <steffen.klass...@secunet.com> wrote: > On Wed, Aug 24, 2016 at 09:27:54AM -0700, Alexander Duyck wrote: >> >> In you case though we maybe be able to make this easier. If I am not >> mistaken I believe we should

Re: [PATCH net-next v1] gso: Support partial splitting at the frag_list pointer

On Wed, Aug 24, 2016 at 2:32 AM, Steffen Klassert <steffen.klass...@secunet.com> wrote: > On Tue, Aug 23, 2016 at 07:47:32AM -0700, Alexander Duyck wrote: >> On Mon, Aug 22, 2016 at 10:20 PM, Steffen Klassert >> <steffen.klass...@secunet.com> wrote: >> > Sinc

Re: [RFC PATCH 3/5] bnx2x: Add support for segmentation of tunnels with outer checksums

gt;> tunneled >> frames that have an outer checksum. >> >> Signed-off-by: Alexander Duyck <adu...@mirantis.com> > > So it took me some [well, a lot] time to reach this, but I've finally gave > it a try. > I saw a performance boost with the partial support -

Re: [PATCH net-next v1] gso: Support partial splitting at the frag_list pointer

On Mon, Aug 22, 2016 at 10:20 PM, Steffen Klassert wrote: > Since commit 8a29111c7 ("net: gro: allow to build full sized skb") > gro may build buffers with a frag_list. This can hurt forwarding > because most NICs can't offload such packets, they need to be >

Re: [net-next PATCH] ethtool: Add support for SCTP verification tag in Rx NFC

On Mon, Aug 22, 2016 at 6:05 AM, Ben Hutchings <b...@decadent.org.uk> wrote: > On Sat, 2016-08-20 at 18:56 -0700, Alexander Duyck wrote: >> > On Sat, Aug 20, 2016 at 5:21 PM, Ben Hutchings <b...@decadent.org.uk> >> > wrote: >> > >> > On Fr

Re: [net-next PATCH] ethtool: Add support for SCTP verification tag in Rx NFC

On Sat, Aug 20, 2016 at 5:21 PM, Ben Hutchings <b...@decadent.org.uk> wrote: > On Fri, 2016-08-19 at 14:32 -0700, Alexander Duyck wrote: >> The i40e hardware has support for SCTP filtering via Rx NFC however the >> default configuration expects us to include the verif

[net-next PATCH] ethtool: Add support for SCTP verification tag in Rx NFC

a new structure to allow us to pass the verification tag for IPv4 or IPv6 SCTP traffic. Signed-off-by: Alexander Duyck <alexander.h.du...@intel.com> --- include/uapi/linux/ethtool.h | 50 +++--- 1 file changed, 46 insertions(+), 4 deletions(-) diff

Re: [PATCH net-next 2/3] net: mpls: Fixups for GSO

On Fri, Aug 19, 2016 at 10:09 AM, David Ahern wrote: > As reported by Lennert the MPLS GSO code is failing to properly segment > large packets. There are a couple of problems: > > 1. the inner protocol is not set so the gso segment functions for inner >protocol

Re: [PATCH] fib_trie: Fix the description of pos and bits

;bits - 1) - "C" - are the index > into > * n's child array, and will of course be different for each child. > * > - * The rest of the bits, from 0 to (n->pos + n->bits), are completely unknown > + * The rest of the bits, from 0 to (n->pos -1) - "u" - are completely unknown > * at this point. > */ > These comment fixes all look correct. Acked-by: Alexander Duyck <alexander.h.du...@intel.com>

Re: [PATCH net-next 2/3] net: mpls: Fixups for GSO

Thought I would go through and do a second pass since it sounds like the inner_mac_header idea isn't going to fly. If we can't push this as an L2 encapsulation there are few tweaks we probably need in order to make this work as an L3. I have included comments inline below. Also I haven't worked

Re: [PATCH net-next 2/3] net: mpls: Fixups for GSO

On Wed, Aug 17, 2016 at 4:23 PM, David Ahern <d...@cumulusnetworks.com> wrote: > On 8/17/16 5:16 PM, Alexander Duyck wrote: >>> diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c >>> index 1ecbd7715f6d..6d78f162a88b 100644 >>> --- a/net

Re: [PATCH net-next 2/3] net: mpls: Fixups for GSO

On Wed, Aug 17, 2016 at 2:49 PM, David Ahern wrote: > As reported by Lennert the MPLS GSO code is failing to properly segment > large packets. There are a couple of problems: > > 1. the inner protocol is not set so the gso segment functions for inner >protocol layers

Re: [Intel-wired-lan] [net-next] igb: add function to set I210 transmit mode

On Tue, Aug 9, 2016 at 11:48 PM, Gangfeng wrote: > From: Gangfeng Huang > > I210 supports two transmit modes, legacy and Qav. The transmit mode is > configured in TQAVCTRL.QavMode register. Before this patch igb driver > only support legacy mode.

Re: [PATCH/RFC net] gre: set inner_protocol on xmit

gt; lwtunnel metadata (which it always does). > > Fixes: 38720352412a ("gre: Use inner_proto to obtain inner header protocol") > Cc: Alexander Duyck <adu...@mirantis.com> > Reviewed-by: Dinan Gunawardena <dinan.gunaward...@netronome.com> > Acked-by: Jakub Kici

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

On Wed, Aug 10, 2016 at 4:54 PM, Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote: > On Wed, 2016-08-10 at 08:47 -0700, Alexander Duyck wrote: >> >> The problem is if we don't do this it becomes possible for a guest to >> essentially cripple a device on the

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

On Tue, Aug 9, 2016 at 5:03 PM, Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote: > On Tue, 2016-08-09 at 11:12 -0700, Alexander Duyck wrote: >> >> The PCI spec is what essentially assumes that there is only one block. >> If I am not mistaken in the case of this d

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

On Tue, Aug 9, 2016 at 5:54 AM, Alexey Kardashevskiy wrote: > On 10/02/16 08:04, Bjorn Helgaas wrote: >> On Wed, Jan 13, 2016 at 12:25:34PM +0100, Hannes Reinecke wrote: >>> PCI-2.2 VPD entries have a maximum size of 32k, but might actually >>> be smaller than that. To figure out

Re: order-0 vs order-N driver allocation. Was: [PATCH v10 07/12] net/mlx4_en: add page recycle to prepare rx ring for tx support

On Fri, Aug 5, 2016 at 8:33 AM, David Laight <david.lai...@aculab.com> wrote: > From: Alexander Duyck >> Sent: 05 August 2016 16:15 > ... >> > >> > interesting idea. Like dma_map 1GB region and then allocate >> > pages from it only? but the rest of

Re: order-0 vs order-N driver allocation. Was: [PATCH v10 07/12] net/mlx4_en: add page recycle to prepare rx ring for tx support

On Thu, Aug 4, 2016 at 8:55 PM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Thu, Aug 04, 2016 at 05:30:56PM -0700, Alexander Duyck wrote: >> On Thu, Aug 4, 2016 at 9:19 AM, Jesper Dangaard Brouer >> <bro...@redhat.com> wrote: >> > >>

Re: order-0 vs order-N driver allocation. Was: [PATCH v10 07/12] net/mlx4_en: add page recycle to prepare rx ring for tx support

On Thu, Aug 4, 2016 at 9:19 AM, Jesper Dangaard Brouer wrote: > > On Wed, 3 Aug 2016 10:45:13 -0700 Alexei Starovoitov > wrote: > >> On Mon, Jul 25, 2016 at 09:35:20AM +0200, Eric Dumazet wrote: >> > On Tue, 2016-07-19 at 12:16 -0700, Brenden

Re: [PATCH] ipv4: panic in leaf_walk_rcu due to stale node pointer

glad you emailed my Gmail because my Mirantis email is no more, I am back to working for Intel. Acked-by: Alexander Duyck <alexander.h.du...@intel.com>

Re: igb: question regarding auto-negotiation

On Fri, Jul 29, 2016 at 4:37 PM, Dominic Curran wrote: > Hi > > This question refers to igb codebase. > I have a question regarding the setting of hw->mac.autoneg. > > Is it correct to say for igb driver: >"if speed=1000 and duplex=FULL and media_type=COPPER then

Re: question: tg3 driver/nics and inconsistent RX ring count

On Tue, Jul 26, 2016 at 12:52 PM, Michal Soltys wrote: > Hi, > > I have a few of BCM5720 and BCM5719 kinds sitting in Dell R320 and R520 > servers - and all of them have certain peculiarity: they claim to have > up to 4 TX and RX rings (and this can be set/verified just fine

Re: patch for PCH_GBE rotten packet (Intel EG20T Platform Controller).

On Tue, Jul 26, 2016 at 9:00 AM, Tom Walsh wrote: > Not sure how this goes, but, we found a race condition in > drivers/net/ethernet/oki-semi/pch_gbe/ > > The attached patch corrects for this. > > TomW So a few minor changes are probably needed. First we don't recommend

Re: [PATCH 1/1] ixgbevf: replace enum with MACROs

On Wed, Jul 20, 2016 at 3:41 AM, wrote: > From: Zhu Yanjun > > With the original enum, when a several bits state is set, it is > possible that the wrong test occurs. > > For example, > > a state is 0x3, its bits are 11. When testing a state 0x2 whose

Re: [RFC PATCH 00/30] Kernel NET policy

On Sun, Jul 17, 2016 at 11:55 PM, wrote: > From: Kan Liang > > It is a big challenge to get good network performance. First, the network > performance is not good with default system settings. Second, it is too > difficult to do automatic tuning for all

Re: [RFC PATCH 23/30] i40e/ethtool: support RX_CLS_LOC_ANY

On Sun, Jul 17, 2016 at 11:56 PM, wrote: > From: Kan Liang > > The existing special location RX_CLS_LOC_ANY flag is designed for the > case which the caller does not know/care about the location. Now, this > flag is only handled in ethtool user space.

Re: [net-next PATCH RFC] mlx4: RX prefetch loop

On Tue, Jul 12, 2016 at 5:45 AM, Jesper Dangaard Brouer wrote: > On Mon, 11 Jul 2016 16:05:11 -0700 > Alexei Starovoitov wrote: > >> On Mon, Jul 11, 2016 at 01:09:22PM +0200, Jesper Dangaard Brouer wrote: >> > > - /* Process all completed CQEs */

Re: [PATCH net-next] drivers/net: fixup comments after "Future-proof tunnel offload handlers"

nks for cleaning this up. Acked-by: Alexander Duyck <adu...@mirantis.com>

Re: [PATCH net-next 0/4] net: cleanup for UDP tunnel's GRO

On Fri, Jul 8, 2016 at 4:04 PM, Hannes Frederic Sowa <han...@stressinduktion.org> wrote: > On 08.07.2016 18:11, Alexander Duyck wrote: >> On Fri, Jul 8, 2016 at 2:51 PM, Hannes Frederic Sowa >> <han...@stressinduktion.org> wrote: >>> On 08.07.2016 17:27, Alexa

Re: [PATCH net-next 0/4] net: cleanup for UDP tunnel's GRO

On Fri, Jul 8, 2016 at 2:51 PM, Hannes Frederic Sowa <han...@stressinduktion.org> wrote: > On 08.07.2016 17:27, Alexander Duyck wrote: >> On Fri, Jul 8, 2016 at 1:57 PM, Hannes Frederic Sowa >> <han...@stressinduktion.org> wrote: >>> On 08.07.2016 16:17, Shmul

Re: [PATCH net-next 0/4] net: cleanup for UDP tunnel's GRO

On Fri, Jul 8, 2016 at 1:57 PM, Hannes Frederic Sowa <han...@stressinduktion.org> wrote: > On 08.07.2016 16:17, Shmulik Ladkani wrote: >> On Fri, 8 Jul 2016 09:21:40 -0700 Alexander Duyck >> <alexander.du...@gmail.com> wrote: >>> On Thu, Jul 7, 2016 at 8:5

Re: [PATCH net-next 2/4] udp offload: allow GRO on 0 checksum packets

On Fri, Jul 8, 2016 at 9:56 AM, Hannes Frederic Sowa <han...@stressinduktion.org> wrote: > On 08.07.2016 12:46, Alexander Duyck wrote: >> On Thu, Jul 7, 2016 at 8:58 AM, Paolo Abeni <pab...@redhat.com> wrote: >>> currently, UDP packets with zero checksum are not al

Re: [PATCH net-next 2/4] udp offload: allow GRO on 0 checksum packets

On Thu, Jul 7, 2016 at 8:58 AM, Paolo Abeni wrote: > currently, UDP packets with zero checksum are not allowed to > use udp offload's GRO. This patch admits such packets to > GRO, if the related socket settings allow it: ipv6 packets > are not admitted if the sockets don't have

Re: [PATCH net-next 0/4] net: cleanup for UDP tunnel's GRO

On Thu, Jul 7, 2016 at 8:58 AM, Paolo Abeni wrote: > With udp tunnel offload in place, the kernel can do GRO for some udp tunnels > at the ingress device level. Currently both the geneve and the vxlan drivers > implement an additional GRO aggregation point via gro_cells. > The

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Thu, Jul 7, 2016 at 3:01 PM, Roland Dreier wrote: >>> struct skb_gso_cb { >>> int mac_offset; >>> int encap_level; >>> __u16 csum_start; >>> }; > >> This is based on an out-dated version of this struct. The 4.7 RC >> kernel has a few

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Wed, Jul 6, 2016 at 11:25 PM, Roland Dreier wrote: > On Thu, Jan 7, 2016 at 3:00 AM, Konstantin Khlebnikov > wrote: >> Or just shift GSO CB and add couple checks like >> BUILD_BUG_ON(sizeof(SKB_GSO_CB(skb)->room) < sizeof(*IPCB(skb))); > >

Re: [PATCH] net/ixgbe: Allow resetting VF admin mac to zero

On Wed, Jul 6, 2016 at 8:57 PM, Stephen Hemminger wrote: > On Fri, 1 Jul 2016 11:19:38 +0200 > Juerg Haefliger wrote: > >> The VF administrative mac addresses (stored in the PF driver) are >> initialized to zero when the PF driver starts up.

Re: DCB Auto turn off when link become up with Intel 82599ES ixgbe driver

On Tue, Jul 5, 2016 at 8:17 AM, ayuj wrote: > I'm trying to configure DCB in back-to-back scenario. > System details > > OS :- CentOS 7.2 > kernel 3.10.0-327.el7.x86_64 > lldpad:- lldpad v0.9.46 > dcbtool:- v0.9.46 > ixgbe :- ixgbe-4.3.15 > > steps followed:- > > # modporbe

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On Thu, Jun 23, 2016 at 10:20 PM, Yuval Mintz wrote: >>We already know of one firmware bug you guys have which makes >>it clear that the bnx2x is not doing hardware assisted GRO it is doing >>something else since it performs much worse than GRO if the MSS is >>less than

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On Thu, Jun 23, 2016 at 2:06 PM, Yuval Mintz wrote: Then again, if you're basically saying every HW-assisted offload on receive should be done under LRO flag, what would be the use case where a GRO-assisted offload would help? I.e., afaik LRO is

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On Wed, Jun 22, 2016 at 9:17 PM, Yuval Mintz wrote: >> Then again, if you're basically saying every HW-assisted offload on >> receive should be done under LRO flag, what would be the use case >> where a GRO-assisted offload would help? > >> I.e., afaik LRO is superior to

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On Wed, Jun 22, 2016 at 4:52 PM, Rick Jones <rick.jon...@hpe.com> wrote: > On 06/22/2016 03:56 PM, Alexander Duyck wrote: >> >> On Wed, Jun 22, 2016 at 3:47 PM, Eric Dumazet <eric.duma...@gmail.com> >> wrote: >>> >>> On Wed, 2016-06-22 at 14:

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On Wed, Jun 22, 2016 at 4:31 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Wed, 2016-06-22 at 15:56 -0700, Alexander Duyck wrote: > >> It could be that you and Rick are running different firmware. I >> believe you can expose that via "ethtool -i".

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On Wed, Jun 22, 2016 at 3:47 PM, Eric Dumazet wrote: > On Wed, 2016-06-22 at 14:52 -0700, Rick Jones wrote: >> On 06/22/2016 11:22 AM, Yuval Mintz wrote: >> > But seriously, this isn't really anything new but rather a step forward in >> > the direction we've already taken

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On Wed, Jun 22, 2016 at 11:22 AM, Yuval Mintz wrote: > This series adds driver support for the processing of tunnel > [specifically vxlan/geneve/gre tunnels] packets which are > aggregated [GROed] by the hardware before driver passes > such packets upto the

<    4   5   6   7   8   9   10   11   12   13   >