Re: [PATCH 1/2] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING

On Tue, May 2, 2017 at 9:30 PM, Casey Leedom <lee...@chelsio.com> wrote: > | From: Alexander Duyck <alexander.du...@gmail.com> > | Date: Tuesday, May 2, 2017 11:10 AM > | ... > | So for example, in the case of x86 it seems like there are multiple > | root complexes that

Re: [PATCH 1/2] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING

On Tue, May 2, 2017 at 12:34 PM, Raj, Ashok <ashok@intel.com> wrote: > On Tue, May 02, 2017 at 11:10:22AM -0700, Alexander Duyck wrote: >> On Tue, May 2, 2017 at 9:53 AM, Raj, Ashok <ashok@intel.com> wrote: >> > On Tue, May 02, 2017 at 09:39:34AM -0700, Alexa

Re: [PATCH 1/2] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING

On Tue, May 2, 2017 at 9:53 AM, Raj, Ashok <ashok@intel.com> wrote: > On Tue, May 02, 2017 at 09:39:34AM -0700, Alexander Duyck wrote: >> On Mon, May 1, 2017 at 4:13 PM, Casey Leedom <lee...@chelsio.com> wrote: >> > The new flag PCI_DEV_FLAGS_NO_RELAXED_ORDER

Re: [PATCH 1/2] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING

On Mon, May 1, 2017 at 4:13 PM, Casey Leedom wrote: > The new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING indicates that the Relaxed > Ordering Attribute should not be used on Transaction Layer Packets destined > for the PCIe End Node so flagged. Initially flagged this way are

Re: [PATCH net-next 1/4] ixgbe: sparc: rename the ARCH_WANT_RELAX_ORDER to IXGBE_ALLOW_RELAXED_ORDER

On Wed, Apr 26, 2017 at 2:26 AM, Ding Tianhong wrote: > Hi Amir: > > It is really glad to hear that the mlx5 will support RO mode this year, if > so, do you agree that enable it dynamic by ethtool -s xxx, > we have try it several month ago but there was only one drivers

Re: Re: [Intel-wired-lan] [PATCH] ixgbe: initialize u64_stats_sync structures early at ixgbe_probe

On Tue, Apr 25, 2017 at 8:39 AM, Lino Sanfilippo wrote: > Hi, > >> This patch doesn't look right to me. I would suggest rejecting it. >> >> The call to initialize the stats should be done when the ring is >> allocated, not in ixgbe_probe(). This should probably be done in

Re: [Intel-wired-lan] [PATCH] ixgbe: initialize u64_stats_sync structures early at ixgbe_probe

On Mon, Apr 24, 2017 at 4:00 PM, Singh, Krishneil K wrote: > > > > -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Liwei Song > Sent: Sunday, December 4, 2016 7:41 PM > To: Kirsher, Jeffrey T

Re: [PATCH V2 net] netdevice: Include NETIF_F_HW_CSUM when intersecting features

On Fri, Apr 21, 2017 at 10:33 AM, Vladislav Yasevich wrote: > On Fri, Apr 21, 2017 at 1:33 AM, Michal Kubecek wrote: >> On Thu, Apr 20, 2017 at 07:19:55PM -0400, Vlad Yasevich wrote: >>> >>> Having said that, the other alternative is to inherit hw_features

Re: [PATCH net-next 1/5] nfp: make use of the DMA_ATTR_SKIP_CPU_SYNC attr

On Fri, Apr 21, 2017 at 7:20 AM, Jakub Kicinski wrote: > DMA unmap may destroy changes CPU made to the buffer. To make XDP > run correctly on non-x86 platforms we should use the > DMA_ATTR_SKIP_CPU_SYNC attribute. > > Thanks to using the attribute we can now push

Re: [PATCH V2 net] netdevice: Include NETIF_F_HW_CSUM when intersecting features

On Thu, Apr 20, 2017 at 4:19 PM, Vlad Yasevich <vyase...@redhat.com> wrote: > On 04/20/2017 06:31 PM, Alexander Duyck wrote: >> On Thu, Apr 20, 2017 at 12:17 PM, Vladislav Yasevich >> <vyasev...@gmail.com> wrote: >>> While hardware device use either NETIF_F_(

Re: [PATCH V2 net] netdevice: Include NETIF_F_HW_CSUM when intersecting features

instance but you would still end up advertising checksum offload via HW_CSUM. > CC: Michal Kubecek <mkube...@suse.cz> > CC: Alexander Duyck <alexander.du...@gmail.com> > CC: Tom Herbert <t...@herbertland.com> > Signed-off-by: Vladislav Yasevich <vyase...@redh

Re: [PATCH net] netdevice: Prefer NETIF_F_HW_CSUM when intersecting features

On Wed, Apr 19, 2017 at 6:12 PM, Vladislav Yasevich wrote: > While hardware device use either NETIF_F_(IP|IPV6)_CSUM or > NETIF_F_HW_CSUM, all of the software devices use HW_CSUM. > This results in an interesting situation when the software > device is configured on top of hw

Re: [Intel-wired-lan] [next-queue v6 PATCH 5/7] i40e: Add TX and RX support over port netdev's in switchdev mode

On Wed, Mar 29, 2017 at 5:22 PM, Sridhar Samudrala wrote: > In switchdev mode, broadcasts from VFs are received by the PF and passed > to corresponding port representor netdev. > Any frames sent via port netdevs are sent as directed transmits to the > corresponding

Re: How to debug DMAR errors?

On Fri, Apr 14, 2017 at 9:19 AM, Ben Greear <gree...@candelatech.com> wrote: > > > On 04/14/2017 08:45 AM, Alexander Duyck wrote: >> >> On Thu, Apr 13, 2017 at 11:12 AM, Ben Greear <gree...@candelatech.com> >> wrote: >>> >>> Hello, >&

Re: How to debug DMAR errors?

On Thu, Apr 13, 2017 at 11:12 AM, Ben Greear wrote: > Hello, > > I have been seeing a regular occurrence of DMAR errors, looking something > like this when testing my ath10k driver/firmware under some specific loads > (maximum receive of 512 byte frames in AP mode): > >

Re: [PATCH net-next 1/1] skbuff: Extend gso_type to unsigned int.

On Mon, Apr 3, 2017 at 1:15 AM, Steffen Klassert wrote: > All available gso_type flags are currently in use, so > extend gso_type from 'unsigned short' to 'unsigned int' > to be able to add further flags. > > We also reorder the struct skb_shared_info to use > two

Re: [net-next 1/4] i40e/i40evf: Add capability exchange for outer checksum

On Thu, Apr 6, 2017 at 11:38 PM, Or Gerlitz wrote: > On Fri, Apr 7, 2017 at 6:23 AM, Jeff Kirsher > wrote: >> From: Preethi Banala >> >> This patch adds a capability negotiation between VF and PF using ENCAP/ >>

Re: [Intel-wired-lan] [PATCH] igb: Allow to remove administratively set MAC on VFs

On Tue, Apr 4, 2017 at 10:16 AM, Duyck, Alexander H wrote: >> -Original Message- >> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On >> Behalf Of Corinna Vinschen >> Sent: Tuesday, April 4, 2017 8:11 AM >> To:

Re: [Intel-wired-lan] [next-queue v6 PATCH 2/7] i40e: Introduce Port Representor netdevs and switchdev mode.

On Tue, Apr 4, 2017 at 4:58 AM, Or Gerlitz wrote: > On Mon, Apr 3, 2017 at 9:41 PM, Samudrala, Sridhar > wrote: >> On 3/30/2017 12:17 AM, Or Gerlitz wrote: >>> On Thu, Mar 30, 2017, Sridhar Samudrala wrote: > Port Representator netdevs are

Re: [next-queue v6 PATCH 7/7] i40e: Add support to get switch id and port number for port netdevs

On Thu, Mar 30, 2017 at 2:45 PM, Jakub Kicinski wrote: > On Wed, 29 Mar 2017 17:22:55 -0700, Sridhar Samudrala wrote: >> Introduce switchdev_ops to PF and port netdevs to return the switch id via >> SWITCHDEV_ATTR_ID_PORT_PARENT_ID attribute. >> Also,

[net-next PATCH v3 2/8] tcp: Record Rx hash and NAPI ID in tcp_child_process

From: Alexander Duyck <alexander.h.du...@intel.com> While working on some recent busy poll changes we found that child sockets were being instantiated without NAPI ID being set. In our first attempt to fix it, it was suggested that we should just pull programming the NAPI ID into the fu

[net-next PATCH v3 4/8] net: Change return type of sk_busy_loop from bool to void

From: Alexander Duyck <alexander.h.du...@intel.com> >From what I can tell there is only a couple spots where we are actually checking the return value of sk_busy_loop. As there are only a few consumers of that data, and the data being checked for can be replaced with a check for !skb_qu

[net-next PATCH v3 1/8] net: Busy polling should ignore sender CPUs

From: Alexander Duyck <alexander.h.du...@intel.com> This patch is a cleanup/fix for NAPI IDs following the changes that made it so that sender_cpu and napi_id were doing a better job of sharing the same location in the sk_buff. One issue I found is that we weren't validating the napi_id as

[net-next PATCH v3 8/8] net: Introduce SO_INCOMING_NAPI_ID

ceived. If the NAPI ID actually represents a sender_cpu then the value is ignored and 0 is returned. Signed-off-by: Sridhar Samudrala <sridhar.samudr...@intel.com> Signed-off-by: Alexander Duyck <alexander.h.du...@intel.com> Acked-by: Eric Dumazet <eduma...@google.com> --- arc

[net-next PATCH v3 6/8] net: Commonize busy polling code to focus on napi_id instead of socket

; Signed-off-by: Alexander Duyck <alexander.h.du...@intel.com> Acked-by: Eric Dumazet <eduma...@google.com> --- include/net/busy_poll.h | 20 +++- net/core/dev.c | 21 - net/core/sock.c | 11 +++ 3 files changed, 34 ins

[net-next PATCH v3 7/8] epoll: Add busy poll support to epoll with socket fds.

; Signed-off-by: Alexander Duyck <alexander.h.du...@intel.com> --- fs/eventpoll.c | 93 1 file changed, 93 insertions(+) diff --git a/fs/eventpoll.c b/fs/eventpoll.c index 341251421ced..5420767c9b68 100644 --- a/fs/eventpoll.c ++

[net-next PATCH v3 5/8] net: Track start of busy loop instead of when it should end

From: Alexander Duyck <alexander.h.du...@intel.com> This patch flips the logic we were using to determine if the busy polling has timed out. The main motivation for this is that we will need to support two different possible timeout values in the future and by recording the start time

[net-next PATCH v3 3/8] net: Only define skb_mark_napi_id in one spot instead of two

From: Alexander Duyck <alexander.h.du...@intel.com> Instead of defining two versions of skb_mark_napi_id I think it is more readable to just match the format of the sk_mark_napi_id functions and just wrap the contents of the function instead of defining two versions of the function. This

[net-next PATCH v3 0/8] Add busy poll support for epoll

always reset to 0. Added "Acked-by" for patches that received acks. --- Alexander Duyck (5): net: Busy polling should ignore sender CPUs tcp: Record Rx hash and NAPI ID in tcp_child_process net: Only define skb_mark_napi_id in one spot instead of two net: Change

[net PATCH] net: Do not allow negative values for busy_read and busy_poll sysctl interfaces

From: Alexander Duyck <alexander.h.du...@intel.com> This change basically codifies what I think was already the limitations on the busy_poll and busy_read sysctl interfaces. We weren't checking the lower bounds and as such could input negative values. The behavior when that wa

Re: [net-next PATCH v2 5/8] net: Track start of busy loop instead of when it should end

On Fri, Mar 24, 2017 at 4:16 AM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Thu, 2017-03-23 at 22:55 -0700, Alexander Duyck wrote: > >> Right, but time_after assumes roll over. When you are using a time >> value based off of local_clock() >> 10, you don't

Re: [net-next PATCH v2 5/8] net: Track start of busy loop instead of when it should end

On Thu, Mar 23, 2017 at 9:27 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Thu, 2017-03-23 at 20:42 -0700, Alexander Duyck wrote: >> On Thu, Mar 23, 2017 at 6:24 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: >> > On Thu, 2017-03-23 at 14:37 -0700, Ale

Re: [net-next PATCH v2 5/8] net: Track start of busy loop instead of when it should end

On Thu, Mar 23, 2017 at 6:24 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Thu, 2017-03-23 at 14:37 -0700, Alexander Duyck wrote: >> From: Alexander Duyck <alexander.h.du...@intel.com> >> > >> The last bit I changed is to move from using a shift

Re: [net-next PATCH v2 8/8] net: Introduce SO_INCOMING_NAPI_ID

On Thu, Mar 23, 2017 at 3:43 PM, Andy Lutomirski <l...@kernel.org> wrote: > On Thu, Mar 23, 2017 at 2:38 PM, Alexander Duyck > <alexander.du...@gmail.com> wrote: >> From: Sridhar Samudrala <sridhar.samudr...@intel.com> >> >> This socket option returns the

Re: [net-next PATCH v2 0/8] Add busy poll support for epoll

On Thu, Mar 23, 2017 at 3:07 PM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Thu, Mar 23, 2017 at 02:36:29PM -0700, Alexander Duyck wrote: >> This is my second pass at trying to add support for busy polling when using >> epoll. It is pretty much a full r

[net-next PATCH v2 6/8] net: Commonize busy polling code to focus on napi_id instead of socket

; Signed-off-by: Alexander Duyck <alexander.h.du...@intel.com> --- include/net/busy_poll.h | 20 +++- net/core/dev.c | 21 - net/core/sock.c | 11 +++ 3 files changed, 34 insertions(+), 18 deletions(-) diff --git a/include

[net-next PATCH v2 0/8] Add busy poll support for epoll

patches which enable epoll support and add support for obtaining the NAPI ID of a given socket. With these It becomes possible for an application to make use of epoll and get optimal busy poll utilization by stacking multiple sockets with the same NAPI ID on the same epoll context. --- Alexander

[net-next PATCH v2 8/8] net: Introduce SO_INCOMING_NAPI_ID

ceived. If the NAPI ID actually represents a sender_cpu then the value is ignored and 0 is returned. Signed-off-by: Sridhar Samudrala <sridhar.samudr...@intel.com> Signed-off-by: Alexander Duyck <alexander.h.du...@intel.com> --- arch/alpha/include/uapi/asm/socket.h |2 ++ arch/avr3

[net-next PATCH v2 7/8] epoll: Add busy poll support to epoll with socket fds.

; Signed-off-by: Alexander Duyck <alexander.h.du...@intel.com> --- fs/eventpoll.c | 93 1 file changed, 93 insertions(+) diff --git a/fs/eventpoll.c b/fs/eventpoll.c index 341251421ced..5420767c9b68 100644 --- a/fs/eventpoll.c ++

[net-next PATCH v2 5/8] net: Track start of busy loop instead of when it should end

From: Alexander Duyck <alexander.h.du...@intel.com> This patch flips the logic we were using to determine if the busy polling has timed out. The main motivation for this is that we will need to support two different possible timeout values in the future and by recording the start time

[net-next PATCH v2 4/8] net: Change return type of sk_busy_loop from bool to void

From: Alexander Duyck <alexander.h.du...@intel.com> >From what I can tell there is only a couple spots where we are actually checking the return value of sk_busy_loop. As there are only a few consumers of that data, and the data being checked for can be replaced with a check for !skb_qu

[net-next PATCH v2 3/8] net: Only define skb_mark_napi_id in one spot instead of two

From: Alexander Duyck <alexander.h.du...@intel.com> Instead of defining two versions of skb_mark_napi_id I think it is more readable to just match the format of the sk_mark_napi_id functions and just wrap the contents of the function instead of defining two versions of the function. This

[net-next PATCH v2 1/8] net: Busy polling should ignore sender CPUs

From: Alexander Duyck <alexander.h.du...@intel.com> This patch is a cleanup/fix for NAPI IDs following the changes that made it so that sender_cpu and napi_id were doing a better job of sharing the same location in the sk_buff. One issue I found is that we weren't validating the napi_id as

[net-next PATCH v2 2/8] tcp: Record Rx hash and NAPI ID in tcp_child_process

From: Alexander Duyck <alexander.h.du...@intel.com> While working on some recent busy poll changes we found that child sockets were being instantiated without NAPI ID being set. In our first attempt to fix it, it was suggested that we should just pull programming the NAPI ID into the fu

[net-next PATCH 0/2] NAPI ID fixups related to busy polling

on a received patcket, but not recording the hash or NAPI ID of the packet that was used to instanciate them. --- Alexander Duyck (2): net: Busy polling should ignore sender CPUs tcp: Record Rx hash and NAPI ID in tcp_child_process include/net/busy_poll.h | 11 +-- net/core

[net-next PATCH 1/2] net: Busy polling should ignore sender CPUs

From: Alexander Duyck <alexander.h.du...@intel.com> This patch is a cleanup/fix for NAPI IDs following the changes that made it so that sender_cpu and napi_id were doing a better job of sharing the same location in the sk_buff. One issue I found is that we weren't validating the napi_id as

[net-next PATCH 2/2] tcp: Record Rx hash and NAPI ID in tcp_child_process

From: Alexander Duyck <alexander.h.du...@intel.com> While working on some recent busy poll changes we found that child sockets were being instantiated without NAPI ID being set. In our first attempt to fix it, it was suggested that we should just pull programming the NAPI ID into the fu

Re: Performance issue with igb with lots of different src-ip addrs.

gt; > Thanks, > Ben > > > On 03/16/2017 07:35 PM, Alexander Duyck wrote: >> >> Can you include the pktgen script you are running? >> >> Also when you say you are driving traffic through the bridge are you >> sending from something external on the system or

Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in socket receive paths

On Thu, Mar 16, 2017 at 7:57 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Thu, 2017-03-16 at 19:40 -0700, Alexander Duyck wrote: > >> What I probably can do is go through and replace all the spots where >> we where checking for sk_napi_id being 0, and instead re

Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in socket receive paths

On Thu, Mar 16, 2017 at 3:50 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Thu, 2017-03-16 at 15:33 -0700, Alexander Duyck wrote: >> On Thu, Mar 16, 2017 at 3:05 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > >> > It is not clear why this patch is nee

Re: Performance issue with igb with lots of different src-ip addrs.

Can you include the pktgen script you are running? Also when you say you are driving traffic through the bridge are you sending from something external on the system or are you actually directing the traffic from pktgen into the bridge directly? - Alex On Thu, Mar 16, 2017 at 3:49 PM, Ben

Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in socket receive paths

On Thu, Mar 16, 2017 at 3:05 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Thu, 2017-03-16 at 11:32 -0700, Alexander Duyck wrote: >> From: Sridhar Samudrala <sridhar.samudr...@intel.com> >> >> Fix sk_mark_napi_id() and sk_mark_napi_id_once() to set s

Re: [net-next PATCH 5/5] epoll: Add busy poll support to epoll with socket fds.

On Thu, Mar 16, 2017 at 3:11 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Thu, 2017-03-16 at 11:33 -0700, Alexander Duyck wrote: >> From: Sridhar Samudrala <sridhar.samudr...@intel.com> > >> +/* >> + * If busy polling is on and the file is a socket, re

Re: [net-next PATCH 2/5] net: Call sk_mark_napi_id() in the ACK receive path

On Thu, Mar 16, 2017 at 3:04 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Thu, 2017-03-16 at 11:32 -0700, Alexander Duyck wrote: >> From: Sridhar Samudrala <sridhar.samudr...@intel.com> >> >> Call sk_mark_napi_id() in the ACK receive path of a TCP_N

[net-next PATCH 2/5] net: Call sk_mark_napi_id() in the ACK receive path

igned-off-by: Sridhar Samudrala <sridhar.samudr...@intel.com> Signed-off-by: Alexander Duyck <alexander.h.du...@intel.com> --- net/ipv4/tcp_ipv4.c |1 + 1 file changed, 1 insertion(+) diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c index 08d870e45658..b86002a296f1 100644 ---

[net-next PATCH 0/5] Add busy poll support for epoll under certain circumstances

This patch series is meant to add busy polling support to epoll when all of the sockets on a given epoll are either local or are being sourced by the same NAPI ID. In order to support this the first two patches clean up a few issues we found with the NAPI ID tracking and infrastructure. In the

[net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in socket receive paths

Signed-off-by: Sridhar Samudrala <sridhar.samudr...@intel.com> Signed-off-by: Alexander Duyck <alexander.h.du...@intel.com> --- include/net/busy_poll.h |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/include/net/busy_poll.h b/include/net/busy_poll.h index c0

[net-next PATCH 3/5] net: Introduce SO_INCOMING_NAPI_ID

ceived. Signed-off-by: Sridhar Samudrala <sridhar.samudr...@intel.com> Signed-off-by: Alexander Duyck <alexander.h.du...@intel.com> --- arch/alpha/include/uapi/asm/socket.h |2 ++ arch/avr32/include/uapi/asm/socket.h |2 ++ arch/frv/include/uapi/asm/socket.h |2 ++ arch

[net-next PATCH 4/5] net: Commonize busy polling code to focus on napi_id instead of socket

; Signed-off-by: Alexander Duyck <alexander.h.du...@intel.com> --- include/net/busy_poll.h |9 + net/core/dev.c | 16 net/core/sock.c | 18 ++ 3 files changed, 35 insertions(+), 8 deletions(-) diff --git a/include/net/busy_po

[net-next PATCH 5/5] epoll: Add busy poll support to epoll with socket fds.

, busy polling is done on the associated queue to pull the packets. Signed-off-by: Sridhar Samudrala <sridhar.samudr...@intel.com> Signed-off-by: Alexander Duyck <alexander.h.du...@intel.com> --- fs/eventpoll.c | 115 1 file chang

[net-next PATCH 2/2] mqprio: Modify mqprio to pass user parameters via ndo_setup_tc.

..@intel.com> Signed-off-by: Alexander Duyck <alexander.h.du...@intel.com> --- drivers/net/ethernet/amd/xgbe/xgbe-drv.c |3 ++- drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c |5 - drivers/net/ethernet/broadcom/bnxt/bnxt.c |4 +++- drivers/net/ethernet/free

[net-next PATCH 1/2] mqprio: Change handling of hw u8 to allow for multiple hardware offload modes

From: Alexander Duyck <alexander.h.du...@intel.com> This patch is meant to allow for support of multiple hardware offload type for a single device. There is currently no bounds checking for the hw member of the mqprio_qopt structure. This results in us being able to pass values from 1

[net-next PATCH 0/2] Add support for passing more information in mqprio offload

ng drivers that don't support this can just fall back to their legacy configuration. --- Alexander Duyck (1): mqprio: Change handling of hw u8 to allow for multiple hardware offload modes Amritha Nambiar (1): mqprio: Modify mqprio to pass user parameters via ndo_setup_tc. drivers/net/et

Re: [Intel-wired-lan] Question on ixgbe flow director

On Wed, Mar 8, 2017 at 11:30 AM, tndave <tushar.n.d...@oracle.com> wrote: > > > On 03/08/2017 07:39 AM, Alexander Duyck wrote: >> >> On Tue, Mar 7, 2017 at 3:43 PM, tndave <tushar.n.d...@oracle.com> >> wrote: >>> >>> Hi, >>>

Re: [Intel-wired-lan] Question on ixgbe flow director

On Tue, Mar 7, 2017 at 3:43 PM, tndave wrote: > Hi, > > I have few questions regarding ixgbe flow director. > As per my understanding flow director in ixgbe can work in 2 exclusive ways, > a. Using ATR filters - where flow director is setup in HW by driver > identifying

Re: [PATCH net] net/tunnel: set inner protocol in network gro hooks

d0d1e ("udp: Generalize skb_udp_segment") > Signed-off-by: Paolo Abeni <pab...@redhat.com> Looks good to me. Acked-by: Alexander Duyck <alexander.h.du...@intel.com> > --- > net/ipv4/af_inet.c | 4 +++- > net/ipv6/ip6_offload.c | 4 +++- > 2 files changed, 6

Re: [PATCH RFC net-next v2 1/4] skbuff: add stub to help computing crc32c on SCTP packets

On Mon, Mar 6, 2017 at 1:51 PM, Davide Caratti <dcara...@redhat.com> wrote: > On Tue, 2017-02-28 at 14:46 -0800, Alexander Duyck wrote: >> On Tue, Feb 28, 2017 at 2:32 AM, Davide Caratti <dcara...@redhat.com> wrote: >> > >> > sctp_compute_checksum requires cr

Re: [PATCH v2 net] net: solve a NAPI race

On Wed, Mar 1, 2017 at 2:41 AM, David Laight <david.lai...@aculab.com> wrote: > From: Alexander Duyck >> Sent: 28 February 2017 17:20 > ... >> You might want to consider just using a combination AND, divide, >> multiply, and OR to avoid having to have any condition

Re: [PATCH RFC net-next v2 1/4] skbuff: add stub to help computing crc32c on SCTP packets

On Tue, Feb 28, 2017 at 2:32 AM, Davide Caratti wrote: > sctp_compute_checksum requires crc32c symbol (provided by libcrc32c), so > it can't be used in net core. Like it has been done previously with other > symbols (e.g. ipv6_dst_lookup), introduce a stub struct

Re: [PATCH v2 net] net: solve a NAPI race

On Mon, Feb 27, 2017 at 6:21 AM, Eric Dumazet wrote: > From: Eric Dumazet > > While playing with mlx4 hardware timestamping of RX packets, I found > that some packets were received by TCP stack with a ~200 ms delay... > > Since the timestamp was

Re: [PATCH v2 net] net: solve a NAPI race

On Mon, Feb 27, 2017 at 8:19 AM, David Miller wrote: > From: Eric Dumazet > Date: Mon, 27 Feb 2017 06:21:38 -0800 > >> A NAPI driver normally arms the IRQ after the napi_complete_done(), >> after NAPI_STATE_SCHED is cleared, so that the hard irq

Re: [PATCH v3 net-next 08/14] mlx4: use order-0 pages for RX

On Wed, Feb 22, 2017 at 6:06 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Wed, 2017-02-22 at 17:08 -0800, Alexander Duyck wrote: > >> >> Right but you were talking about using both halves one after the >> other. If that occurs you have nothing left that you

Re: [PATCH v3 net-next 08/14] mlx4: use order-0 pages for RX

On Wed, Feb 22, 2017 at 10:21 AM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Wed, 2017-02-22 at 09:23 -0800, Alexander Duyck wrote: >> On Wed, Feb 22, 2017 at 8:22 AM, Eric Dumazet <eric.duma...@gmail.com> wrote: >> > On Mon, 2017-02-13 at 11:58 -0800, Eric Dum

Re: [PATCH v3 net-next 08/14] mlx4: use order-0 pages for RX

On Wed, Feb 22, 2017 at 8:22 AM, Eric Dumazet wrote: > On Mon, 2017-02-13 at 11:58 -0800, Eric Dumazet wrote: >> Use of order-3 pages is problematic in some cases. >> >> This patch might add three kinds of regression : >> >> 1) a CPU performance regression, but we will add

Re: Questions on XDP

On Mon, Feb 20, 2017 at 11:55 PM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Mon, Feb 20, 2017 at 08:00:57PM -0800, Alexander Duyck wrote: >> >> I assumed "toy Tx" since I wasn't aware that they were actually >> allowing writing

Re: Questions on XDP

On Mon, Feb 20, 2017 at 7:39 PM, John Fastabend <john.fastab...@gmail.com> wrote: > On 17-02-20 07:18 PM, Alexei Starovoitov wrote: >> On Sat, Feb 18, 2017 at 06:16:47PM -0800, Alexander Duyck wrote: >>> >>> I was thinking about the fact that the Mellanox driv

Re: Focusing the XDP project

On Mon, Feb 20, 2017 at 3:39 PM, Jesper Dangaard Brouer <bro...@redhat.com> wrote: > On Mon, 20 Feb 2017 12:09:30 -0800 > Alexander Duyck <alexander.du...@gmail.com> wrote: > >> On Mon, Feb 20, 2017 at 2:13 AM, Jesper Dangaard Brouer >> <bro...@redhat.com>

Re: Focusing the XDP project

On Mon, Feb 20, 2017 at 2:57 PM, Saeed Mahameed <sae...@mellanox.com> wrote: > > > On 02/20/2017 10:09 PM, Alexander Duyck wrote: >> On Mon, Feb 20, 2017 at 2:13 AM, Jesper Dangaard Brouer >> <bro...@redhat.com> wrote: >>> >>> First thing

Re: Focusing the XDP project

On Mon, Feb 20, 2017 at 2:13 AM, Jesper Dangaard Brouer wrote: > > First thing to bring in order for the XDP project: > > RX batching is missing. > > I don't want to discuss packet page-sizes or multi-port forwarding, > before we have established the most fundamental

Re: Questions on XDP

On Sat, Feb 18, 2017 at 3:48 PM, John Fastabend <john.fastab...@gmail.com> wrote: > On 17-02-18 03:31 PM, Alexei Starovoitov wrote: >> On Sat, Feb 18, 2017 at 10:18 AM, Alexander Duyck >> <alexander.du...@gmail.com> wrote: >>> >>>> XDP

Re: Questions on XDP

On Sat, Feb 18, 2017 at 9:41 AM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Sat, 2017-02-18 at 17:34 +0100, Jesper Dangaard Brouer wrote: >> On Thu, 16 Feb 2017 14:36:41 -0800 >> John Fastabend <john.fastab...@gmail.com> wrote: >> >> > On 17-02-16

Re: [net-next 06/14] ixgbe: Update driver to make use of DMA attributes in Rx path

PM >> To: da...@davemloft.net >> Cc: Alexander Duyck; netdev@vger.kernel.org; nhor...@redhat.com; >> sassm...@redhat.com; jogre...@redhat.com; Jeff Kirsher >> Subject: [net-next 06/14] ixgbe: Update driver to make use of DMA attributes >> in >> Rx path >> >&g

Questions on XDP

So I'm in the process of working on enabling XDP for the Intel NICs and I had a few questions so I just thought I would put them out here to try and get everything sorted before I paint myself into a corner. So my first question is why does the documentation mention 1 frame per page for XDP? Is

Re: [PATCH v3 net-next 08/14] mlx4: use order-0 pages for RX

On Tue, Feb 14, 2017 at 10:46 AM, Jesper Dangaard Brouer <bro...@redhat.com> wrote: > On Tue, 14 Feb 2017 09:29:54 -0800 > Alexander Duyck <alexander.du...@gmail.com> wrote: > >> On Tue, Feb 14, 2017 at 6:56 AM, Tariq Toukan <ttoukan.li...@gmail.com> >> wrot

Re: [PATCH v3 net-next 08/14] mlx4: use order-0 pages for RX

On Tue, Feb 14, 2017 at 6:56 AM, Tariq Toukan wrote: > > > On 14/02/2017 3:45 PM, Eric Dumazet wrote: >> >> On Tue, Feb 14, 2017 at 4:12 AM, Jesper Dangaard Brouer >> wrote: >> >>> It is important to understand that there are two cases for the cost of

Re: [PATCH v3 net-next 08/14] mlx4: use order-0 pages for RX

On Mon, Feb 13, 2017 at 4:57 PM, Eric Dumazet wrote: > >> Alex, be assured that I implemented the full thing, of course. > > Patch was : > > diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c > b/drivers/net/ethernet/mellanox/mlx4/en_rx.c > index >

Re: [PATCH v3 net-next 08/14] mlx4: use order-0 pages for RX

On Mon, Feb 13, 2017 at 4:22 PM, Eric Dumazet <eduma...@google.com> wrote: > On Mon, Feb 13, 2017 at 3:47 PM, Alexander Duyck > <alexander.du...@gmail.com> wrote: > >> Actually it depends on the use case. In the case of pktgen packets >> they are usually dropped

Re: [PATCH v3 net-next 08/14] mlx4: use order-0 pages for RX

On Mon, Feb 13, 2017 at 3:29 PM, Eric Dumazet <eduma...@google.com> wrote: > On Mon, Feb 13, 2017 at 3:26 PM, Alexander Duyck > <alexander.du...@gmail.com> wrote: > >> >> Odds are for a single TCP flow you won't notice. This tends to be >> more of a small

Re: [PATCH v3 net-next 08/14] mlx4: use order-0 pages for RX

On Mon, Feb 13, 2017 at 3:22 PM, Eric Dumazet <eduma...@google.com> wrote: > On Mon, Feb 13, 2017 at 3:16 PM, Alexander Duyck > <alexander.du...@gmail.com> wrote: > >> Any plans to add the bulk page count updates back at some point? I >> just got around to adding

Re: [PATCH v3 net-next 08/14] mlx4: use order-0 pages for RX

On Mon, Feb 13, 2017 at 1:09 PM, Eric Dumazet <eduma...@google.com> wrote: > On Mon, Feb 13, 2017 at 12:51 PM, Alexander Duyck > <alexander.du...@gmail.com> wrote: >> On Mon, Feb 13, 2017 at 11:58 AM, Eric Dumazet <eduma...@google.com> wrote: > >>> +

Re: [PATCH v3 net-next 08/14] mlx4: use order-0 pages for RX

On Mon, Feb 13, 2017 at 11:58 AM, Eric Dumazet wrote: > Use of order-3 pages is problematic in some cases. > > This patch might add three kinds of regression : > > 1) a CPU performance regression, but we will add later page > recycling and performance should be back. > > 2)

Re: Disabling msix interrupts

On Mon, Feb 6, 2017 at 7:33 AM, David Laight wrote: > netdev probably isn't the right list for this, but I suspect people > reading it understand what happens. > > I'm fairly sure that an msix interrupt can get raised after > the kernel thinks it has masked it. > > When

Re: [PATCH net-next] ixgbe: get rid of custom busy polling code

Not only we remove lot's of code, we also remove one lock > operation in fast path, and allow GRO to do its job. > > Signed-off-by: Eric Dumazet <eduma...@google.com> > Cc: Jeff Kirsher <jeffrey.t.kirs...@intel.com> Looks good to me Acked-by: Alexander Duyck <alexander.h.du...@intel.com>

Re: [PATCH net-next] ixgbevf: get rid of custom busy polling code

Not only we remove lot's of code, we also remove one lock > operation in fast path, and allow GRO to do its job. > > Signed-off-by: Eric Dumazet <eduma...@google.com> > Cc: Jeff Kirsher <jeffrey.t.kirs...@intel.com> Looks good to me Acked-by: Alexander Duyck <alexander.h.du...@intel.com>

Re: [PATCH net-next 2/2] add one config to select relax order mode in intel NIC's Kconfig

On Fri, Feb 3, 2017 at 1:30 AM, Mao Wenan wrote: > This patch allows one to enable relax order mode in intel NIC's > Kconfig. CONFIG_ARCH_WANT_RELAX_ORDER is a common macro for some > CPU architecture to use relax order mode in NIC's source codes. >

Re: Understanding mutual exclusion between rtnl_lock and rcu_read_lock

On Thu, Feb 2, 2017 at 3:47 PM, Joel Cunningham wrote: > Hi, > > I’m studying the synchronization used on different parts of struct net_device > and I’m struggling to understand how structure member modifications in > dev_ioctl are synchronized. Getters in

Re: NAPI on USB network drivers

On Wed, Jan 25, 2017 at 5:33 AM, Oliver Hartkopp wrote: > On 01/25/2017 10:39 AM, Hayes Wang wrote: >> >> Oliver Neukum [mailto:oneu...@suse.com] >>> >>> Sent: Wednesday, January 25, 2017 5:35 PM >> >> [...] >>> >>> looking at r8152 I noticed that it uses NAPI. I never

Re: [PATCH v2 net-next] net:add one common config ARCH_WANT_RELAX_ORDER to support relax ordering.

On Mon, Jan 23, 2017 at 1:44 AM, David Laight <david.lai...@aculab.com> wrote: > Alexander Duyck >> Sent: 19 January 2017 15:55 > ... >> >> The Relaxed Ordering attribute doesn't get applied across the board. >> >> It ends up being limited t

Re: [PATCH v2 net-next] net:add one common config ARCH_WANT_RELAX_ORDER to support relax ordering.

On Thu, Jan 19, 2017 at 3:43 AM, David Laight <david.lai...@aculab.com> wrote: > From: Alexander Duyck >> Sent: 18 January 2017 17:25 >> On Wed, Jan 18, 2017 at 8:22 AM, David Laight <david.lai...@aculab.com> >> wrote: >> > From: David Miller >&

Re: [PATCH v2 net-next] net:add one common config ARCH_WANT_RELAX_ORDER to support relax ordering.

On Wed, Jan 18, 2017 at 8:22 AM, David Laight wrote: > From: David Miller >> Sent: 17 January 2017 19:16 >> > Relax ordering(RO) is one feature of 82599 NIC, to enable this feature can >> > enhance the performance for some cpu architecure, such as SPARC and so on. >> >

<    1   2   3   4   5   6   7   8   9   10   >