Re: [PATCH v5 09/21] IB/hns: Add hca support

On Wed, Apr 27, 2016 at 6:34 AM, oulijun wrote: > On 2016/4/26 22:25, Jiri Pirko wrote: >> Tue, Apr 26, 2016 at 04:18:21PM CEST, l...@kernel.org wrote: I appreciate your keen eye. this code is meant for ARM64bit therefore should run corretly for 64-bit AARCH64.

Re: [PATCH net 2/3] udp_offload: Set encapsulation before inner completes.

On Fri, Apr 29, 2016 at 3:28 PM, Jarno Rajahalme wrote: > UDP tunnel segmentation code relies on the inner offsets being set for > an UDP tunnel GSO packet. The inner *_complete() functions will set > the inner offsets only if the encapsulation is set before calling > them, but

[PATCH net 1/3] udp_tunnel: Remove redundant udp_tunnel_gro_complete().

The setting of the UDP tunnel GSO type is already performed by udp[46]_gro_complete(). Signed-off-by: Jarno Rajahalme --- drivers/net/geneve.c | 2 -- drivers/net/vxlan.c | 2 -- include/net/udp_tunnel.h | 9 - net/ipv4/fou.c | 2 -- 4 files changed, 15

Re: [PATCH net 2/3] udp_offload: Set encapsulation before inner completes.

On Fri, Apr 29, 2016 at 3:28 PM, Jarno Rajahalme wrote: > UDP tunnel segmentation code relies on the inner offsets being set for > an UDP tunnel GSO packet. The inner *_complete() functions will set > the inner offsets only if the encapsulation is set before calling > them, but

[PATCH net 2/3] udp_offload: Set encapsulation before inner completes.

UDP tunnel segmentation code relies on the inner offsets being set for an UDP tunnel GSO packet. The inner *_complete() functions will set the inner offsets only if the encapsulation is set before calling them, but udp_gro_complete() set it only after the inner *_complete() functions were done.

Re: [PATCH next-next 0/7] net: Cleanup IPv6 ip tunnels

On Fri, Apr 29, 2016 at 5:12 PM, Tom Herbert wrote: > The IPv6 tunnel code is very different from IPv4 code. There is a lot > of redundancy with the IPv4 code, particularly in the GRE tunneling. > > This patch set cleans up the tunnel code to make the IPv6 code look > more

[PATCH net-next] ipv6: add new struct ipcm6_cookie

From: Wei Wang In the sendmsg function of UDP, raw, ICMP and l2tp sockets, we use local variables like hlimits, tclass, opt and dontfrag and pass them to corresponding functions like ip6_make_skb, ip6_append_data and xxx_push_pending_frames. This is not a good practice and

[PATCH net-next 6/7] ipv6: Generic tunnel cleanup

A few generic changes to generalize tunnels in IPv6: - Export ip6_tnl_change_mtu so that it can be called by ip6_gre - Add tun_hlen to ip6_tnl structure. Signed-off-by: Tom Herbert --- include/net/ip6_tunnel.h | 5 - net/ipv6/ip6_tunnel.c| 7 +-- 2 files

[PATCH next-next 5/7] gre: Create common functions for transmit

Create common functions for both IPv4 and IPv6 GRE in transmit. These are put into gre.h. Common functions are for: - GRE checksum calculation. Move gre_checksum to gre.h. - Building a GRE header. Move GRE build_header and rename gre_build_header. Signed-off-by: Tom Herbert

[PATCH next-next 3/7] gre6: Cleanup GREv6 receive path, call common GRE functions

- Create gre_rcv function. This calls gre_parse_header and ip6gre_rcv. - Call ip6_tnl_rcv. Doing this and using gre_parse_header eliminates most of the code in ip6gre_rcv. Signed-off-by: Tom Herbert --- net/ipv6/ip6_gre.c | 140

[PATCH next-next 7/7] gre6: Cleanup GREv6 transmit path, call common GRE functions

Changes in GREv6 transmit path: - Call gre_checksum, remove gre6_checksum - Rename ip6gre_xmit2 to __gre6_xmit - Call gre_build_header utility function - Call ip6_tnl_xmit common function - Call ip6_tnl_change_mtu, eliminate ip6gre_tunnel_change_mtu Signed-off-by: Tom Herbert

[PATCH next-next 4/7] ipv6: Create ip6_tnl_xmit

This patch renames ip6_tnl_xmit2 to ip6_tnl_xmit and exports it. Other users like GRE will be able to call this. The original ip6_tnl_xmit function is renamed to ip6_tnl_start_xmit (this is an ndo_start_xmit function). Signed-off-by: Tom Herbert ---

[PATCH next-next 0/7] net: Cleanup IPv6 ip tunnels

The IPv6 tunnel code is very different from IPv4 code. There is a lot of redundancy with the IPv4 code, particularly in the GRE tunneling. This patch set cleans up the tunnel code to make the IPv6 code look more like the IPv4 code and use common functions between the two stacks where possible.

[PATCH next-next 1/7] ipv6: Cleanup IPv6 tunnel receive path

Some basic changes to make IPv6 tunnel receive path look more like IPv4 path: - Make ip6_tnl_rcv non-static so that GREv6 and others can call it - Make ip6_tnl_rcv look like ip_tunnel_rcv - Switch to gro_cells_receive - Make ip6_tnl_rcv non-static and export it Signed-off-by: Tom Herbert

[PATCH next-next 2/7] gre: Move utility functions to common headers

Several of the GRE functions defined in net/ipv4/ip_gre.c are usable for IPv6 GRE implementation (that is they are protocol agnostic). These include: - GRE flag handling functions are move to gre.h - GRE build_header is moved to gre.h and renamed gre_build_header - parse_gre_header is moved

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

On Fri, Apr 29, 2016 at 4:29 PM, Michael Chan wrote: > On Fri, Apr 29, 2016 at 2:31 PM, Alexander Duyck > wrote: > >> Okay so if that is the case we may want to make it so that we ignore >> checksum for both IPv4 and IPv6 and then we can just

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

On Fri, Apr 29, 2016 at 2:31 PM, Alexander Duyck wrote: > Okay so if that is the case we may want to make it so that we ignore > checksum for both IPv4 and IPv6 and then we can just provide it via > GSO_PARTIAL in the case we want it. Otherwise you are technically >

Cannot use NFS with linux-next 20160429

Hi, NFS is not working on a imx6q-sabresd board running linux-next 20160429: [ 15.753317] #0: wm8962-audio [ 15.759437] Root-NFS: no NFS server address [ 15.763649] VFS: Unable to mount root fs via NFS, trying floppy. [ 15.774223] VFS: Cannot open root device "nfs" or unknown

[net-next PATCH v2 9/9] bnxt: Add support for segmentation of tunnels with outer checksums

This patch assumes that the bnxt hardware will ignore existing IPv4/v6 header fields for length and checksum as well as the length and checksum fields for outer UDP and GRE headers. I have been told by Michael Chan that this is working. Though this might be somewhat redundant for IPv6 as they

[net-next PATCH v2 4/9] vxlan: Add checksum check to the features check function

We need to perform an additional check on the inner headers to determine if we can offload the checksum for them. Previously this check didn't occur so we would generate an invalid frame in the case of an IPv6 header encapsulated inside of an IPv4 tunnel. To fix this I added a secondary check to

[net-next PATCH v2 8/9] mlx5e: Fix IPv6 tunnel checksum offload

The mlx5 driver exposes support for TSO6 but not IPv6 csum for hardware encapsulated tunnels. This leads to issues as it triggers warnings in skb_checksum_help as it ends up being called as we report supporting the segmentation but not the checksumming for IPv6 frames. This patch corrects that

[net-next PATCH v2 6/9] mlx4: Add support for inner IPv6 checksum offloads and TSO

>From what I can tell the ConnectX-3 will support an inner IPv6 checksum and segmentation offload, however it cannot support outer IPv6 headers. This assumption is based on the fact that I could see the checksum being offloaded for inner header on IPv4 tunnels, but not on IPv6 tunnels. For this

[net-next PATCH v2 7/9] mlx5e: Add support for UDP tunnel segmentation with outer checksum offload

This patch assumes that the mlx5 hardware will ignore existing IPv4/v6 header fields for length and checksum as well as the length and checksum fields for outer UDP headers. Signed-off-by: Alexander Duyck --- drivers/net/ethernet/mellanox/mlx5/core/en_main.c |7 ++-

[net-next PATCH v2 5/9] mlx4: Add support for UDP tunnel segmentation with outer checksum offload

This patch assumes that the mlx4 hardware will ignore existing IPv4/v6 header fields for length and checksum as well as the length and checksum fields for outer UDP headers. Signed-off-by: Alexander Duyck --- drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 17

[net-next PATCH v2 3/9] net: Fix netdev_fix_features so that TSO_MANGLEID is only available with TSO

This change makes it so that we will strip the TSO_MANGLEID bit if TSO is not present. This way we will also handle ECN correctly of TSO is not present. Signed-off-by: Alexander Duyck --- net/core/dev.c |4 1 file changed, 4 insertions(+) diff --git

[net-next PATCH v2 1/9] net: Disable segmentation if checksumming is not supported

In the case of the mlx4 and mlx5 driver they do not support IPv6 checksum offload for tunnels. With this being the case we should disable GSO in addition to the checksum offload features when we find that a device cannot perform a checksum on a given packet type. Signed-off-by: Alexander Duyck

[net-next PATCH v2 2/9] gso: Only allow GSO_PARTIAL if we can checksum the inner protocol

This patch addresses a possible issue that can occur if we get into any odd corner cases where we support TSO for a given protocol but not the checksum or scatter-gather offload. There are few drivers floating around that setup their tunnels this way and by enforcing the checksum piece we can

[net-next PATCH v2 0/9] Fix Tunnel features and enable GSO partial for several drivers

This patch series is meant to allow us to get the best performance possible for Mellanox ConnectX-3/4 and Broadcom NetXtreme-C/E adapters in terms of VXLAN and GRE tunnels. The first few patches address issues I found when just trying to collect performance numbers. Specifically I was unable to

Re: [PATCH net 1/3] udp_tunnel: Remove redundant udp_tunnel_gro_complete().

This is a two patch series.. I had a third patch which fixed a bug that was already fixed, so I dropped it but failed to generate messages again, hence the “[12]/3”. Sorry for the noise, Jarno > On Apr 29, 2016, at 3:28 PM, Jarno Rajahalme wrote: > > The setting of the UDP

Re: [PATCH v3 net-next 5/7] sctp: prepare for socket backlog behavior change

On Fri, Apr 29, 2016 at 02:16:51PM -0700, Eric Dumazet wrote: > sctp_inq_push() will soon be called without BH being blocked > when generic socket code flushes the socket backlog. > > It is very possible SCTP can be converted to not rely on BH, > but this needs to be done by SCTP experts. > >

Re: [PATCH v3 net-next 6/7] net: do not block BH while processing socket backlog

On 4/29/16 2:16 PM, Eric Dumazet wrote: Socket backlog processing is a major latency source. With current TCP socket sk_rcvbuf limits, I have sampled __release_sock() holding cpu for more than 5 ms, and packets being dropped by the NIC once ring buffer is filled. All users are now ready to be

Re: [PATCH v3 net-next 2/7] tcp: do not block bh during prequeue processing

On 4/29/16 2:16 PM, Eric Dumazet wrote: AFAIK, nothing in current TCP stack absolutely wants BH being disabled once socket is owned by a thread running in process context. As mentioned in my prior patch ("tcp: give prequeue mode some care"), processing a batch of packets might take time, better

Re: [PATCH 0/2] sctp: Add GSO support

Cc'ing Xin. Sorry Xin. On Fri, Apr 29, 2016 at 06:33:31PM -0300, Marcelo Ricardo Leitner wrote: > This patchset adds sctp GSO support. > > Performance tests indicates that increases throughput by 10% if using > bigger chunk sizes, specially if bigger than MTU. For small chunks, it > doesn't help

New DSA design for cross-chip operations

Hi, Here's a proposal for a new design of DSA. It is meant to discuss the actual state and future implementation of the D (for distributed) in DSA, which consists of supporting several interconnected switch chips, exposed to the user as one big switch unit. There's still a lot of work to finish

[PATCH 2/2] sctp: Add GSO support

SCTP has this pecualiarity that its packets cannot be just segmented to (P)MTU. Its chunks must be contained in IP segments, padding respected. So we can't just generate a big skb, set gso_size to the fragmentation point and deliver it to IP layer. This patch takes a different approach. SCTP will

[PATCH 1/2] skbuff: export skb_gro_receive

sctp GSO requires it and sctp can be compiled as a module, so we need to export this function. Signed-off-by: Marcelo Ricardo Leitner --- net/core/skbuff.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index

[PATCH 0/2] sctp: Add GSO support

This patchset adds sctp GSO support. Performance tests indicates that increases throughput by 10% if using bigger chunk sizes, specially if bigger than MTU. For small chunks, it doesn't help much if not using heavy firewall rules. For small chunks it will probably be of more use once we get

[PATCH net] gre: do not pull header in ICMP error processing

iptunnel_pull_header expects that IP header was already pulled; with this expectation, it pulls the tunnel header. This is not true in gre_err. Furthermore, ipv4_update_pmtu and ipv4_redirect expect that skb->data points to the IP header. We cannot pull the tunnel header in this path. It's just a

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

On Fri, Apr 29, 2016 at 2:29 PM, Michael Chan wrote: > On Fri, Apr 29, 2016 at 2:17 PM, Alexander Duyck > wrote: >> On Wed, Apr 27, 2016 at 9:32 PM, Michael Chan >> wrote: >>> On Wed, Apr 27, 2016 at 8:21 AM,

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

On Fri, Apr 29, 2016 at 2:17 PM, Alexander Duyck wrote: > On Wed, Apr 27, 2016 at 9:32 PM, Michael Chan > wrote: >> On Wed, Apr 27, 2016 at 8:21 AM, Alexander Duyck >> wrote: >>> On Tue, Apr 26, 2016 at 10:55 PM,

Re: [PATCH] net: l2tp: fix reversed udp6 checksum flags

Is there any further suggestion or review? > 在 2016年4月29日，03:25，Wang Shanker 写道： > > I think this is a logic error, rather than a change to the default > UDP checksum setting. As expected, take rx for example, the flag > `L2TP_ATTR_UDP_ZERO_CSUM6_RX` is not set by

[PATCH v3 net-next 4/7] udp: prepare for non BH masking at backlog processing

UDP uses the generic socket backlog code, and this will soon be changed to not disable BH when protocol is called back. We need to use appropriate SNMP accessors. Signed-off-by: Eric Dumazet Acked-by: Soheil Hassas Yeganeh --- net/ipv4/udp.c | 4 ++--

[PATCH v3 net-next 5/7] sctp: prepare for socket backlog behavior change

sctp_inq_push() will soon be called without BH being blocked when generic socket code flushes the socket backlog. It is very possible SCTP can be converted to not rely on BH, but this needs to be done by SCTP experts. Signed-off-by: Eric Dumazet --- net/sctp/inqueue.c | 2

[PATCH v2 net-next 0/7] net: make TCP preemptible

Most of TCP stack assumed it was running from BH handler. This is great for most things, as TCP behavior is very sensitive to scheduling artifacts. However, the prequeue and backlog processing are problematic, as they need to be flushed with BH being blocked. To cope with modern needs, TCP

[PATCH v3 net-next 3/7] dccp: do not assume DCCP code is non preemptible

DCCP uses the generic backlog code, and this will soon be changed to not disable BH when protocol is called back. Signed-off-by: Eric Dumazet Acked-by: Soheil Hassas Yeganeh --- net/dccp/input.c | 2 +- net/dccp/ipv4.c| 4 ++-- net/dccp/ipv6.c|

[PATCH v3 net-next 6/7] net: do not block BH while processing socket backlog

Socket backlog processing is a major latency source. With current TCP socket sk_rcvbuf limits, I have sampled __release_sock() holding cpu for more than 5 ms, and packets being dropped by the NIC once ring buffer is filled. All users are now ready to be called from process context, we can

[PATCH v3 net-next 1/7] tcp: do not assume TCP code is non preemptible

We want to to make TCP stack preemptible, as draining prequeue and backlog queues can take lot of time. Many SNMP updates were assuming that BH (and preemption) was disabled. Need to convert some __NET_INC_STATS() calls to NET_INC_STATS() and some __TCP_INC_STATS() to TCP_INC_STATS() Before

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

On Wed, Apr 27, 2016 at 9:32 PM, Michael Chan wrote: > On Wed, Apr 27, 2016 at 8:21 AM, Alexander Duyck > wrote: >> On Tue, Apr 26, 2016 at 10:55 PM, Michael Chan >> wrote: >>> On Tue, Apr 19, 2016 at 12:06 PM,

[PATCH v3 net-next 2/7] tcp: do not block bh during prequeue processing

AFAIK, nothing in current TCP stack absolutely wants BH being disabled once socket is owned by a thread running in process context. As mentioned in my prior patch ("tcp: give prequeue mode some care"), processing a batch of packets might take time, better not block BH at all. Signed-off-by: Eric

Re: [PATCH net-next V1 00/11] Mellanox 100G extending mlx5 ethtool support

On Fri, Apr 29, 2016 at 11:34 PM, David Miller wrote: > From: Saeed Mahameed > Date: Fri, 29 Apr 2016 23:27:06 +0300 > >> but my concerns is when features A and B requires firmware commands A then B >> and firmware command B fails, there is no

Re: [PATCH v2 net-next 0/7] net: make TCP preemptible

On Fri, 2016-04-29 at 16:39 -0400, David Miller wrote: > From: Eric Dumazet > Date: Thu, 28 Apr 2016 20:10:42 -0700 > > > Most of TCP stack assumed it was running from BH handler. > > Assuming you are respinning this to fix that stats bumping typo. > > You should really

Re: [PATCH v2 net-next 0/7] net: make TCP preemptible

From: Eric Dumazet Date: Thu, 28 Apr 2016 20:10:42 -0700 > Most of TCP stack assumed it was running from BH handler. Assuming you are respinning this to fix that stats bumping typo. You should really look into how that got corrupted. :)

Re: [PATCH net-next V1 00/11] Mellanox 100G extending mlx5 ethtool support

From: Saeed Mahameed Date: Fri, 29 Apr 2016 23:27:06 +0300 > but my concerns is when features A and B requires firmware commands A then B > and firmware command B fails, there is no gurantee that roll back for > firmware command A will work. > > this is why in case of

Re: [PATCH net-next 00/12] Mellanox 100G mlx5 ethernet aRFS support

From: Saeed Mahameed Date: Fri, 29 Apr 2016 01:36:30 +0300 > This series adds accelerated RFS support for the mlx5e driver. Series applied, thanks Saeed.

Re: [PATCH net-next V1 00/11] Mellanox 100G extending mlx5 ethtool support

On Wed, Apr 27, 2016 at 12:41 AM, David Miller wrote: > From: Saeed Mahameed > Date: Tue, 26 Apr 2016 23:55:03 +0300 > >> It will be a nightmare to rollback in such case. What if the rollback >> failed ? > > It is absolutely essential to handle

Re: [PATCH v3 net-next 0/2] net: ethernet: enc28j60: small improvements

From: Michael Heimpold Date: Thu, 28 Apr 2016 22:06:13 +0200 > This series of two patches adds the following improvements to the driver: > > 1) Rework the central SPI read function so that it is compatible with >SPI masters which only support half duplex transfers. > > 2)

Re: [PATCH net-next v2 0/5] bridge: per-vlan stats

On 04/29/2016 10:12 PM, David Miller wrote: > From: Nikolay Aleksandrov > Date: Fri, 29 Apr 2016 21:49:17 +0200 > >> Because that is not needed for the per-vlan stats to work, I did to >> unify the paths and simplify the pvid code but I can easily drop it >> and

Re: [PATCH net-next] net: constify is_skb_forwardable's arguments

From: Nikolay Aleksandrov Date: Thu, 28 Apr 2016 17:59:28 +0200 > is_skb_forwardable is not supposed to change anything so constify its > arguments > > Signed-off-by: Nikolay Aleksandrov Applied, thanks.

Re: [PATCH net-next v2 0/5] bridge: per-vlan stats

From: Nikolay Aleksandrov Date: Fri, 29 Apr 2016 21:49:17 +0200 > Because that is not needed for the per-vlan stats to work, I did to > unify the paths and simplify the pvid code but I can easily drop it > and revert back to using the direct pvid id. The only fetch

Re: [PATCH v4 net-next 2/2] ppp: add rtnetlink device creation support

From: Guillaume Nault Date: Thu, 28 Apr 2016 17:55:30 +0200 > Define PPP device handler for use with rtnetlink. > The only PPP specific attribute is IFLA_PPP_DEV_FD. It is mandatory and > contains the file descriptor of the associated /dev/ppp instance (the > file

Re: [PATCH net-next v2 0/5] bridge: per-vlan stats

On 04/29/2016 09:33 PM, David Miller wrote: > From: Nikolay Aleksandrov > Date: Thu, 28 Apr 2016 17:52:46 +0200 > >> This set adds support for bridge per-vlan statistics. > > Between the counter bumps in fast paths and new levels of pointer > indirection in order to

[PATCH] Bluetooth: Use hci_conn_hash_lookup_le

Use the function hci_conn_hash_lookup_le that integrates type testing for looking up LE connections. See the patch 1b51c7b6 that introduced this function for more details. The semantic patch that (sort of) fixes this problem is as follows: (http://coccinelle.lip6.fr/) // @@ expression

Re: [RFC PATCH 2/5] mlx5: Add support for UDP tunnel segmentation with outer checksum offload

On Fri, Apr 29, 2016 at 12:27 PM, Saeed Mahameed wrote: > On Fri, Apr 29, 2016 at 4:59 AM, Alexander Duyck > wrote: >> On Thu, Apr 28, 2016 at 6:18 PM, Matthew Finlay wrote: >>> >>> >>> >>> >>> > > The mlx5

Re: [PATCH net-next v2 0/5] bridge: per-vlan stats

From: Nikolay Aleksandrov Date: Thu, 28 Apr 2016 17:52:46 +0200 > This set adds support for bridge per-vlan statistics. Between the counter bumps in fast paths and new levels of pointer indirection in order to RCU things, I have to agree with Stephen that this new

Re: [RFC PATCH 2/5] mlx5: Add support for UDP tunnel segmentation with outer checksum offload

On Fri, Apr 29, 2016 at 4:59 AM, Alexander Duyck wrote: > On Thu, Apr 28, 2016 at 6:18 PM, Matthew Finlay wrote: >> >> >> >> >> The mlx5 hardware requires the outer UDP checksum is not set when offloading encapsulated packets. >>>

Re: [PATCH net-next] net: ethernet: stmmac: update MDIO support for GMAC4

From: Alexandre TORGUE Date: Thu, 28 Apr 2016 15:56:45 +0200 > On new GMAC4 IP, MAC_MDIO_address register has been updated, and bitmaps > changed. This patch takes into account those changes. > > Signed-off-by: Alexandre TORGUE Applied,

Re: [PATCH net-next] vxlan: fix initialization with custom link parameters

From: Jiri Benc Date: Thu, 28 Apr 2016 16:36:30 +0200 > Commit 0c867c9bf84c ("vxlan: move Ethernet initialization to a separate > function") changed initialization order and as an unintended result, when the > user specifies additional link parameters (such as IFLA_ADDRESS)

Re: [net-next PATCH V4 0/5] samples/bpf: Improve user experience

From: Jesper Dangaard Brouer Date: Thu, 28 Apr 2016 14:20:48 +0200 > It is a steep learning curve getting started with using the eBPF > examples in samples/bpf/. There are several dependencies, and > specific versions of these dependencies. Invoking make in the correct >

Re: [PATCHv3] netem: Segment GSO packets on enqueue

On Fri, 29 Apr 2016 13:35:48 -0400 Neil Horman wrote: > This was recently reported to me, and reproduced on the latest net kernel, > when > attempting to run netperf from a host that had a netem qdisc attached to the > egress interface: > > [ 788.073771] [

Re: [PATCH net] ip_tunnel: fix preempt warning in ip tunnel creation/updating

From: Paolo Abeni Date: Thu, 28 Apr 2016 11:04:51 +0200 > After the commit e09acddf873b ("ip_tunnel: replace dst_cache with generic > implementation"), a preemption debug warning is triggered on ip4 > tunnels updating; the dst cache helper needs to be invoked in unpreemptible

Re: [PATCH] mdio_bus: Fix MDIO bus scanning in __mdiobus_register()

On 04/29/2016 05:46 PM, Sergei Shtylyov wrote: > Hello. Hi! > On 04/29/2016 02:45 PM, Marek Vasut wrote: > >>> First of all, thank you for the patch! >>> You beat me to it (and not only me). :-) >> >> Heh, hacking at night has it's perks :) > >I know, I'm just supposed to work on

[PATCH v2 0/3] drivers: net: xgene: fix: Get channel number from device binding

This patch set adds 'channel' property to get ethernet to CPU channel number, thus decoupling the Linux driver from static resource selection. v2: Address review comments from v1 - removed irq reference from Linux driver - added 'channel' property to get ethernet to CPU channel number v1: -

[PATCH v2 3/3] dtb: xgene: Add channel property

Added 'channel' property, describing ethernet to CPU channel number. Signed-off-by: Iyappan Subramanian --- arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 1 + arch/arm64/boot/dts/apm/apm-storm.dtsi | 1 + 2 files changed, 2 insertions(+) diff --git

[PATCH v2 1/3] drivers: net: xgene: Get channel number from device binding

This patch gets ethernet to CPU channel (prefetch buffer number) from the newly added 'channel' property, thus decoupling Linux driver from resource management. Signed-off-by: Iyappan Subramanian --- drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 15 ++- 1

[PATCH v2 2/3] Documentation: dtb: xgene: Add channel property

Signed-off-by: Iyappan Subramanian --- Documentation/devicetree/bindings/net/apm-xgene-enet.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/net/apm-xgene-enet.txt b/Documentation/devicetree/bindings/net/apm-xgene-enet.txt index

Re: [PATCHv3] netem: Segment GSO packets on enqueue

On Fri, 2016-04-29 at 13:35 -0400, Neil Horman wrote: > This was recently reported to me, and reproduced on the latest net kernel, > when > attempting to run netperf from a host that had a netem qdisc attached to the > egress interface: > > /* > * Insert one skb into qdisc. > * Note:

[PATCH] i40e: fix misleading indentation

Newly added code in i40e_vc_config_promiscuous_mode_msg() is indented in a way that gcc rightly complains about: drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c: In function 'i40e_vc_config_promiscuous_mode_msg': drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:1543:4: error: this 'if'

Re: [PATCH net-next 0/2] cxgb4/cxgb4vf: add support for mbox cmd logging

From: Hariprasad Shenai Date: Thu, 28 Apr 2016 13:23:17 +0530 > This patch series adds support for logging mailbox commands and replies > for debugging purpose for both PF and VF driver. > > This patch series has been created against net-next tree and includes > patches

Re: [PATCH net-next 0/4] net: hns: update DT properties according to Rob's comments

From: Yisen Zhuang Date: Thu, 28 Apr 2016 15:09:00 +0800 > There are some inappropriate properties definition in hns DT. We update the > definition > according to Rob's review comments and fix some typos in binding. > > For more details, please see individual patches.

[PATCH] net: Implement net_dbg_ratelimited() for CONFIG_DYNAMIC_DEBUG case

Prior to commit d92cff89a0c8 ("net_dbg_ratelimited: turn into no-op when !DEBUG") the implementation of net_dbg_ratelimited() was buggy for both the DEBUG and CONFIG_DYNAMIC_DEBUG cases. The bug was that net_ratelimit() was being called and, despite returning true, nothing was being printed to

[PATCHv3] netem: Segment GSO packets on enqueue

This was recently reported to me, and reproduced on the latest net kernel, when attempting to run netperf from a host that had a netem qdisc attached to the egress interface: [ 788.073771] [ cut here ] [ 788.096716] WARNING: at net/core/dev.c:2253

Re: [net-next PATCH 0/8] Fix Tunnel features and enable GSO partial for Mellanox adapters

On Fri, Apr 29, 2016 at 10:31 AM, David Miller wrote: > From: Alexander Duyck > Date: Mon, 25 Apr 2016 11:30:54 -0700 > >> This patch series is meant to allow us to get the best performance possible >> for Mellanox ConnectX-3/4 adapters in terms of VXLAN

Re: [net-next PATCH 0/8] Fix Tunnel features and enable GSO partial for Mellanox adapters

From: Alexander Duyck Date: Mon, 25 Apr 2016 11:30:54 -0700 > This patch series is meant to allow us to get the best performance possible > for Mellanox ConnectX-3/4 adapters in terms of VXLAN tunnels. I'm going to mark this as "deferred" in patchwork, so Alex why don't you

[PATCH] sctp: signal sk_data_ready earlier on data chunks reception

Dave Miller pointed out that fb586f25300f ("sctp: delay calls to sk_data_ready() as much as possible") may insert latency specially if the receiving application is running on another CPU and that it would be better if we signalled as early as possible. This patch thus basically inverts the logic

[PATCH 2/3] fs: poll/select/recvmmsg: use timespec64 for timeout events

struct timespec is not y2038 safe. Even though timespec might be sufficient to represent timeouts, use struct timespec64 here as the plan is to get rid of all timespec reference in the kernel. The patch transitions the common functions: poll_select_set_timeout() and select_estimate_accuracy() to

[PATCH 0/3] Use timespec64 for select like timeouts

The series is part of y2038 changes. This changes a few syscalls that have common functions to use struct timespec64 instead of struct timespec. This does not include changes to system call uapi interfaces. Those will be in a different series. Thanks to Arnd Bergmann for comments on the

Re: [PATCH v3 0/2] sctp: delay calls to sk_data_ready() as much as possible

On Fri, Apr 29, 2016 at 12:10:31PM -0400, Neil Horman wrote: > On Fri, Apr 29, 2016 at 10:47:25AM -0300, marcelo.leit...@gmail.com wrote: > > On Fri, Apr 29, 2016 at 09:36:37AM -0400, Neil Horman wrote: > > > On Thu, Apr 28, 2016 at 05:46:59PM -0300, marcelo.leit...@gmail.com wrote: > > > > On

Re: [PATCH v3 0/2] sctp: delay calls to sk_data_ready() as much as possible

On Fri, Apr 29, 2016 at 10:47:25AM -0300, marcelo.leit...@gmail.com wrote: > On Fri, Apr 29, 2016 at 09:36:37AM -0400, Neil Horman wrote: > > On Thu, Apr 28, 2016 at 05:46:59PM -0300, marcelo.leit...@gmail.com wrote: > > > On Thu, Apr 14, 2016 at 05:19:00PM -0300, marcelo.leit...@gmail.com wrote:

Re: [PATCH] mdio_bus: Fix MDIO bus scanning in __mdiobus_register()

Hello. On 04/29/2016 02:45 PM, Marek Vasut wrote: First of all, thank you for the patch! You beat me to it (and not only me). :-) Heh, hacking at night has it's perks :) I know, I'm just supposed to work on different things. :-) On 4/29/2016 4:09 AM, Marek Vasut wrote: Since

Re: [PATCH nf-next 8/9] netfilter: conntrack: use a single hashtable for all namespaces

Florian Westphal wrote: > We already include netns address in the hash and compare the netns pointers > during lookup, so even if namespaces have overlapping addresses entries > will be spread across the table. > > Assuming 64k bucket size, this change saves 0.5 mbyte per

Re: [PATCH net-next] net: dsa: mv88e6xxx: replace ds with ps where possible

Hi Andrew, Andrew Lunn writes: > On Thu, Apr 28, 2016 at 09:24:06PM -0400, Vivien Didelot wrote: >> From: Andrew Lunn >> >> The dsa_switch structure ds is actually needed in very few places, >> mostly during setup of the switch. The private structure ps is

Re: [PATCH v2 net-next 1/7] tcp: do not assume TCP code is non preemptible

On Fri, Apr 29, 2016 at 10:37 AM, Eric Dumazet wrote: > On Fri, 2016-04-29 at 09:18 -0400, Soheil Hassas Yeganeh wrote: >> On Thu, Apr 28, 2016 at 11:10 PM, Eric Dumazet wrote: > >> > + NET_ADD_STATS(sock_net(sk), >> > +

[PATCH net v2 1/1] tipc: only process unicast on intended node

From: Hamish Martin We have observed complete lock up of broadcast-link transmission due to unacknowledged packets never being removed from the 'transmq' queue. This is traced to nodes having their ack field set beyond the sequence number of packets that have

Re: [PATCH v2 net-next 1/7] tcp: do not assume TCP code is non preemptible

On Fri, 2016-04-29 at 09:18 -0400, Soheil Hassas Yeganeh wrote: > On Thu, Apr 28, 2016 at 11:10 PM, Eric Dumazet wrote: > > + NET_ADD_STATS(sock_net(sk), > > + LINUX_MIB_TCPHYSTARTTRAINCWND, > > +

Re: [PATCH v3 0/2] sctp: delay calls to sk_data_ready() as much as possible

On Fri, Apr 29, 2016 at 09:36:37AM -0400, Neil Horman wrote: > On Thu, Apr 28, 2016 at 05:46:59PM -0300, marcelo.leit...@gmail.com wrote: > > On Thu, Apr 14, 2016 at 05:19:00PM -0300, marcelo.leit...@gmail.com wrote: > > > On Thu, Apr 14, 2016 at 04:03:51PM -0400, Neil Horman wrote: > > > > On

Re: [PATCH v3 0/2] sctp: delay calls to sk_data_ready() as much as possible

On Thu, Apr 28, 2016 at 05:46:59PM -0300, marcelo.leit...@gmail.com wrote: > On Thu, Apr 14, 2016 at 05:19:00PM -0300, marcelo.leit...@gmail.com wrote: > > On Thu, Apr 14, 2016 at 04:03:51PM -0400, Neil Horman wrote: > > > On Thu, Apr 14, 2016 at 02:59:16PM -0400, David Miller wrote: > > > > From:

Re: [PATCH v2 net-next 6/7] net: do not block BH while processing socket backlog

On Thu, Apr 28, 2016 at 11:10 PM, Eric Dumazet wrote: > Socket backlog processing is a major latency source. > > With current TCP socket sk_rcvbuf limits, I have sampled __release_sock() > holding cpu for more than 5 ms, and packets being dropped by the NIC > once ring buffer

Re: [RFC PATCH net] ipv6/ila: fix nlsize calculation for lwtunnel

Le 28/04/2016 18:07, Tom Herbert a écrit : > On Wed, Apr 27, 2016 at 12:20 PM, David Miller wrote: >> From: Nicolas Dichtel >> Date: Fri, 22 Apr 2016 17:58:02 +0200 >> >>> The handler 'ila_fill_encap_info' adds one attribute: ILA_ATTR_LOCATOR. >>>

Re: [PATCH v2 net-next 4/7] udp: prepare for non BH masking at backlog processing

On Thu, Apr 28, 2016 at 11:10 PM, Eric Dumazet wrote: > UDP uses the generic socket backlog code, and this will soon > be changed to not disable BH when protocol is called back. > > We need to use appropriate SNMP accessors. > > Signed-off-by: Eric Dumazet

Re: [PATCH v2 net-next 3/7] dccp: do not assume DCCP code is non preemptible

On Thu, Apr 28, 2016 at 11:10 PM, Eric Dumazet wrote: > DCCP uses the generic backlog code, and this will soon > be changed to not disable BH when protocol is called back. > > Signed-off-by: Eric Dumazet Acked-by: Soheil Hassas Yeganeh

  1   2   >