Re: 802.3ad bonding aggregator reselection

Veli-Matti Lintu wrote: [...] >> I don't see an issue with the above behavior when ad_select is >> set to the default value of "stable"; bonding does reselect a new >> aggregator when all links fail, and it appears to follow the standard. > >In my testing

[PATCH 1/2] net: thunderx: Fix link status reporting

From: Sunil Goutham Check for SMU RX local/remote faults along with SPU LINK status. Otherwise at times link is UP at our end but DOWN at link partner's side. Also due to an issue in BGX it's rarely seen that initialization doesn't happen properly and SMU RX reports faults

[PATCH 2/2] net: thunderx: Fix TL4 configuration for secondary Qsets

From: Sunil Goutham TL4 calculation for a given SQ of secondary Qsets is incorrect and goes out of bounds and also for some SQ's TL4 chosen will transmit data via a different BGX interface and not same as primary Qset's interface. This patch fixes this issue.

[PATCH 0/2] net: thunderx: Miscellaneous fixes

From: Sunil Goutham This 2 patch series fixes issues w.r.t physical link status reporting and transmit datapath configuration for secondary qsets. Sunil Goutham (2): net: thunderx: Fix link status reporting net: thunderx: Fix TL4 configuration for secondary Qsets

Re: [PATCH net-next 10/19] net: hns: bugfix about pfc pause frame statistics

在 2016/6/22 17:41, Andy Shevchenko 写道: > On Wed, 2016-06-22 at 09:43 +0800, Yisen Zhuang wrote: >> >> 在 2016/6/21 18:32, Andy Shevchenko 写道: >>> On Tue, 2016-06-21 at 11:56 +0800, Yisen Zhuang wrote: From: Daode Huang For SoC hip06, PFC pause handled in

Re: [patch net-next v5 0/4] return offloaded stats as default and expose original sw stats

Wed, Jun 22, 2016 at 09:32:25PM CEST, ro...@cumulusnetworks.com wrote: >On Tue, Jun 21, 2016 at 8:15 AM, Jiri Pirko wrote: >> From: Jiri Pirko >> >> The problem we try to handle is about offloaded forwarded packets >> which are not seen by kernel. Let me try

Re: [PATCH net-next V2] tun: introduce tx skb ring

On 2016年06月23日 02:18, Michael S. Tsirkin wrote: On Fri, Jun 17, 2016 at 03:41:20AM +0300, Michael S. Tsirkin wrote: >Would it help to have ptr_ring_resize that gets an array of >rings and resizes them both to same length? OK, here it is. Untested so far, and no skb wrapper. Pls let me know

[PATCH] i40e: Remove redundant memset

Remove redundant call to memset before a call to memcpy. The Coccinelle semantic patch used to make this change is as follows: @@ expression e1,e2,e3,e4; @@ - memset(e1,e2,e3); memcpy(e1,e4,e3); Signed-off-by: Amitoj Kaur Chawla ---

[PATCH 1/2] Bluetooth: Add LED triggers for HCI frames tx and rx

Two LED triggers are defined: tx_led and rx_led. Upon frames available in HCI core layer, for tx or for rx, the combined LED can blink. Verified on HiKey, 96boards. It uses hi6220 SoC and TI WL1835 combo chip. Signed-off-by: Guodong Xu ---

[PATCH 2/2] arm64: dts: hikey: set bluetooth led trigger

Set bluetooth led trigger to hci0-rx, and so LED blinks on hci frame receiving. Signed-off-by: Guodong Xu --- arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts

[PATCH] tipc: Use kmemdup instead of kmalloc and memcpy

Replace calls to kmalloc followed by a memcpy with a direct call to kmemdup. The Coccinelle semantic patch used to make this change is as follows: @@ expression from,to,size,flag; statement S; @@ - to = \(kmalloc\|kzalloc\)(size,flag); + to = kmemdup(from,size,flag); if (to==NULL || ...) S

Re: esp: Fix ESN generation under UDP encapsulation

This change tests okay in my setup. Thanks very much -Blair On 06/20/2016 10:59 PM, Steffen Klassert wrote: > On Sat, Jun 18, 2016 at 01:03:36PM +0800, Herbert Xu wrote: >> On Fri, Jun 17, 2016 at 12:24:29PM +0200, Steffen Klassert wrote: >>> On Wed, Jun 15, 2016 at 12:44:54AM +, Blair

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

> 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 GRO in `brute force' - > it creates better packed packets and utilizes memory

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

>> Claiming that hardware assist GRO is not possible is a plain mantra. > I have no issue claiming hardware assist GRO is possible.  My problem > is saying that the GRO feature flag can be used to enable it.  I would > argue that any packet aggregation at the device or driver level is LRO >

Re: [PATCH] Maxim/driver: Add driver for maxim ds26522

Hi, [auto build test ERROR on net-next/master] [also build test ERROR on next-20160622] [cannot apply to v4.7-rc4] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Zhao-Qiang/Maxim-driver-Add

RE: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms

Hi Arnd, Could you comment on these? Thanks. Best regards, Yangbo Lu > -Original Message- > From: Scott Wood [mailto:o...@buserror.net] > Sent: Saturday, June 11, 2016 9:51 AM > To: Arnd Bergmann; linuxppc-...@lists.ozlabs.org > Cc: Mark Rutland; Ulf Hansson;

Re: [PATCH net-next v10 2/5] openvswitch: set skb protocol and mac_len when receiving on internal device

On Tue, Jun 21, 2016 at 09:30:17AM -0700, pravin shelar wrote: > On Mon, Jun 20, 2016 at 7:25 PM, Simon Horman > wrote: > > [Cc Jiri Benc] > > > > On Sat, Jun 18, 2016 at 06:38:54PM -0700, pravin shelar wrote: > >> On Thu, Jun 16, 2016 at 10:53 PM, Simon Horman > >>

Re: [PATCH V4 1/1] net: ethernet: Add TSE PCS support to dwmac-socfpga

Hi Peppe, On Wed, 2016-06-22 at 11:00 +0200, Giuseppe CAVALLARO wrote: > Hello Tien Hock > > On 6/21/2016 10:46 AM, th...@altera.com wrote: > > From: Tien Hock Loh > > > > This adds support for TSE PCS that uses SGMII adapter when the phy-mode of > > the dwmac is set to sgmii

[PATCH] Maxim/driver: Add driver for maxim ds26522

Signed-off-by: Zhao Qiang --- drivers/net/wan/Kconfig| 10 ++ drivers/net/wan/Makefile | 1 + drivers/net/wan/slic_ds26522.c | 256 + drivers/net/wan/slic_ds26522.h | 134 + 4 files changed, 401

Re: [PATCH v4 net] ipvs: fix bind to link-local mcast IPv6 address in backup

On Fri, Jun 17, 2016 at 09:42:49AM +0300, Julian Anastasov wrote: > > Hello, > > On Thu, 16 Jun 2016, Quentin Armitage wrote: > > > When using HEAD from > > https://git.kernel.org/cgit/utils/kernel/ipvsadm/ipvsadm.git/, > > the command: > > ipvsadm --start-daemon backup --mcast-interface

[PATCH v2] net/mlx5: use mlx5_buf_alloc_node instead of mlx5_buf_alloc in mlx5_wq_ll_create

Fixes: 311c7c71c9bb ("net/mlx5e: Allocate DMA coherent memory on reader NUMA node") Commit 311c7c71c9bb ("net/mlx5e: Allocate DMA coherent memory on reader NUMA node") introduced mlx5_*_alloc_node() but missed changing some calling and warn messages. This patch introduces 2 changes: * Use

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

On 06/22/2016 04:10 PM, Rick Jones wrote: My systems are presently in the midst of an install but I should be able to demonstrate it in the morning (US Pacific time, modulo the shuttle service of a car repair place) The installs finished sooner than I thought. So, receiver:

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

On Wed, Jun 22, 2016 at 4:52 PM, Rick Jones wrote: > On 06/22/2016 03:56 PM, Alexander Duyck wrote: >> >> On Wed, Jun 22, 2016 at 3:47 PM, Eric Dumazet >> wrote: >>> >>> On Wed, 2016-06-22 at 14:52 -0700, Rick Jones wrote: Had the

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

On Wed, Jun 22, 2016 at 4:31 PM, Eric Dumazet 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". This is the ugly bit >> about all this.

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

On Wed, Jun 22, 2016 at 4:31 PM, Eric Dumazet 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". This is the ugly bit >> about all this.

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

On 06/22/2016 03:56 PM, Alexander Duyck wrote: On Wed, Jun 22, 2016 at 3:47 PM, Eric Dumazet wrote: On Wed, 2016-06-22 at 14:52 -0700, Rick Jones wrote: Had the bnx2x-driven NICs' firmware not had that rather unfortunate assumption about MSSes I probably would never

[no subject]

my name is Mrs. Alice Walton, a business woman an America Citizen and the heiress to the fortune of Walmart stores, born October 7, 1949. I have a proposal for you

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

On Wed, 2016-06-22 at 14:32 -0700, Alexander Duyck wrote: > The idea behind GRO was to make it so that we had a generic way to > handle this in software. For the most part drivers doing LRO in > software were doing the same thing that the GRO was doing. The only > reason it was

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

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". This is the ugly bit > about all this. We are offloading GRO into the firmware of these > devices with no idea how any of

Re: r8169 regression: UDP packets dropped intermittantly

Jonathan Woithe : [...] > to mainline (in which case I'll keep watching out for it)? Or is the > out-of-tree workaround mentioned above considered to be the long term > fix for those who encounter the problem? It's a workaround. Nothing less, nothing more. IIRC the ga311

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

On 06/22/2016 03: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 - bnx2x/qede are already performing the same

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/8] tou: Transports over UDP - part I

On Wed, Jun 22, 2016 at 3:15 PM, Richard Weinberger wrote: > On Thu, Jun 16, 2016 at 7:51 PM, Tom Herbert wrote: >> Transports over UDP is intended to encapsulate TCP and other transport >> protocols directly and securely in UDP. >> >> The goal

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

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 - bnx2x/qede are already performing > > the same for non-encapsulated TCP. > >

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

On 22.06.2016 14:32, Alexander Duyck wrote: > 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

Re: [PATCH] mellanox: mlx5: Use logging functions to reduce text ~10k/5%

On Wed, 2016-06-22 at 14:40 -0600, Jason Gunthorpe wrote: > On Wed, Jun 22, 2016 at 11:23:59AM -0700, Joe Perches wrote: > > The output changes now do not include line #, but do include the > > function offset. > I've been using a technique like this in some code with good results: > > struct

Re: Regarding VRF support in Linux Kernel

On 6/22/16 4:03 PM, Randy Dunlap wrote: On 06/22/16 14:05, Ajith Adapa wrote: Hi, I am following the steps present in (https://www.kernel.org/doc/Documentation/networking/vrf.txt) and trying to create IPv4 VRF in latest Fedora 24 distribution with 4.5 Linux kernel. [root@localhost ip]# uname

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On Thu, Jun 16, 2016 at 7:51 PM, Tom Herbert wrote: > Transports over UDP is intended to encapsulate TCP and other transport > protocols directly and securely in UDP. > > The goal of this work is twofold: > > 1) Allow applications to run their own transport layer stack

RE: [PATCH v6] r8152: Add support for setting pass through MAC address on RTL8153-AD

> -Original Message- > From: Limonciello, Mario > Sent: Tuesday, June 14, 2016 5:27 PM > To: 'David Miller' ; pali.ro...@gmail.com > Cc: gre...@linuxfoundation.org; and...@lunn.ch; > hayesw...@realtek.com; linux-ker...@vger.kernel.org; > netdev@vger.kernel.org;

Re: Regarding VRF support in Linux Kernel

On 06/22/16 14:05, Ajith Adapa wrote: > Hi, > > I am following the steps present in > (https://www.kernel.org/doc/Documentation/networking/vrf.txt) and > trying to create IPv4 VRF in latest Fedora 24 distribution with 4.5 > Linux kernel. > > [root@localhost ip]# uname -a > Linux

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

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 - bnx2x/qede are already performing the same for non-encapsulated TCP. Since you mention bnx2x... I would argue that the NIC firmware on

Re: [RFC nf-next 1/3] netfilter: bridge: add and use br_nf_hook_thresh

Aaron Conole writes: > From: Florian Westphal > > This replaces the last uses of NF_HOOK_THRESH(). > Followup patch will remove it and rename nf_hook_thresh. > > The reason is that inet (non-bridge) netfilter no longer invokes the > hooks from hooks, so we do

[RFC nf-next 3/3] netfilter: replace list_head with single linked list

The netfilter hook list never uses the prev pointer, and so can be trimmed to be a smaller singly-linked list. In addition to having a more light weight structure for hook traversal, struct net becomes 5568 bytes (down from 6400) and struct net_device becomes 2176 bytes (down from 2240).

[RFC nf-next 0/3] Compact netfilter hooks list

This series makes a simple change to shrink the netfilter hook list from a double linked list, to a singly linked list. Since the hooks are always traversed in-order, there is no need to maintain a previous pointer. This series is being submitted for early feedback. This was jointly developed by

[RFC nf-next 1/3] netfilter: bridge: add and use br_nf_hook_thresh

From: Florian Westphal This replaces the last uses of NF_HOOK_THRESH(). Followup patch will remove it and rename nf_hook_thresh. The reason is that inet (non-bridge) netfilter no longer invokes the hooks from hooks, so we do no longer need the thresh value to skip hooks with a

[RFC nf-next 2/3] netfilter: call nf_hook_state_init with rcu_read_lock held

From: Florian Westphal This makes things simpler because we can store the head of the list in the nf_state structure without worrying about concurrent add/delete of hook elements from the list. Signed-off-by: Florian Westphal Signed-off-by: Aaron Conole

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

[PATCH net-next v2 2/4] cgroup: bpf: Add BPF_MAP_TYPE_CGROUP_ARRAY

Add a BPF_MAP_TYPE_CGROUP_ARRAY and its bpf_map_ops's implementations. To update an element, the caller is expected to obtain a cgroup2 backed fd by open(cgroup2_dir) and then update the array with that fd. Signed-off-by: Martin KaFai Lau Cc: Alexei Starovoitov Cc:

[PATCH net-next v2 4/4] cgroup: bpf: Add an example to do cgroup checking in BPF

test_cgrp2_array_pin.c: A userland program that creates a bpf_map (BPF_MAP_TYPE_GROUP_ARRAY), pouplates/updates it with a cgroup2's backed fd and pins it to a bpf-fs's file. The pinned file can be loaded by tc and then used by the bpf prog later. This program can also update an existing pinned

[PATCH net-next v2 3/4] cgroup: bpf: Add bpf_skb_in_cgroup_proto

Adds a bpf helper, bpf_skb_in_cgroup, to decide if a skb->sk belongs to a descendant of a cgroup2. It is similar to the feature added in netfilter: commit c38c4597e4bf ("netfilter: implement xt_cgroup cgroup2 path match") The user is expected to populate a BPF_MAP_TYPE_CGROUP_ARRAY which will be

[PATCH net-next v2 1/4] cgroup: Add cgroup_get_from_fd

Add a helper function to get a cgroup2 from a fd. It will be stored in a bpf array (BPF_MAP_TYPE_CGROUP_ARRAY) which will be introduced in the later patch. Signed-off-by: Martin KaFai Lau Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Tejun Heo

[PATCH net-next v2 0/4] cgroup: bpf: cgroup2 membership test on skb

v2: - Fix two return cases in cgroup_get_from_fd() - Fix compilation errors when CONFIG_CGROUPS is not used: - arraymap.c: avoid registering BPF_MAP_TYPE_CGROUP_ARRAY - filter.c: tc_cls_act_func_proto() returns NULL on BPF_FUNC_skb_in_cgroup - Add comments to BPF_FUNC_skb_in_cgroup and

Regarding VRF support in Linux Kernel

Hi, I am following the steps present in (https://www.kernel.org/doc/Documentation/networking/vrf.txt) and trying to create IPv4 VRF in latest Fedora 24 distribution with 4.5 Linux kernel. [root@localhost ip]# uname -a Linux localhost.localdomain 4.5.5-300.fc24.x86_64 #1 SMP Thu May 19 13:05:32

Re: [PATCH net-next v3] tcp: use RFC6298 compliant TCP RTO calculation

On Wed, Jun 22, 2016 at 4:21 AM, Hagen Paul Pfeifer wrote: > > > On June 22, 2016 at 7:53 AM Yuchung Cheng wrote: > > > > Thanks for the patience. I've collected data from some Google Web > > servers. They serve both a mix of US and SouthAm users using > >

Re: [PATCH net-next 7/9] net/mlx5e: Add 50G missing link mode to ethtool and mlx5 driver

On Wed, Jun 22, 2016 at 7:47 PM, David Decotigny wrote: > maybe split this into 2 separate patches? sure

Re: [PATCH] mellanox: mlx5: Use logging functions to reduce text ~10k/5%

On Wed, Jun 22, 2016 at 11:23:59AM -0700, Joe Perches wrote: > The output changes now do not include line #, but do include the > function offset. I've been using a technique like this in some code with good results: struct source_location { const char *file; const char *func; const

Re: [PATCH net 0/2] mlx4_en fixes for 4.7-rc

From: Tariq Toukan Date: Mon, 20 Jun 2016 17:35:07 +0300 > This small patchset includes two small fixes for mlx4_en driver. > > One allows a clean shutdown even when clients do not release their > netdev reference. > The other adds error return values to the VLAN VID

Re: [PATCH] can: only call can_stat_update with procfs

On 06/20/2016 05:51 PM, Arnd Bergmann wrote: > The change to leave out procfs support in CAN when CONFIG_PROC_FS > is not set was incomplete and leads to a build error: > > net/built-in.o: In function `can_init': > :(.init.text+0x9858): undefined reference to `can_stat_update' > ERROR:

Re: [net-next,v4] openvswitch: Add packet len info to upcall.

From: William Tu Date: Mon, 20 Jun 2016 07:26:17 -0700 > The commit f2a4d086ed4c ("openvswitch: Add packet truncation support.") > introduces packet truncation before sending to userspace upcall receiver. > This patch passes up the skb->len before truncation so that the

Re: [PATCH] kcm: fix /proc memory leak

From: Jiri Slaby Date: Mon, 20 Jun 2016 11:36:28 +0200 > Every open of /proc/net/kcm leaks 16 bytes of memory as is reported by > kmemleak: > unreferenced object 0x88059c0e3458 (size 192): > comm "cat", pid 1401, jiffies 4294935742 (age 310.720s) > hex dump (first 32

Re: [PATCH net 1/1] tipc: unclone unbundled buffers before forwarding

From: Jon Maloy Date: Mon, 20 Jun 2016 09:20:46 -0400 > When extracting an individual message from a received "bundle" buffer, > we just create a clone of the base buffer, and adjust it to point into > the right position of the linearized data area of the latter. This

Re: [PATCH net] team: Fix possible deadlock during team enslave

From: Ido Schimmel Date: Mon, 20 Jun 2016 11:53:20 +0300 > Both dev_uc_sync_multiple() and dev_mc_sync_multiple() require the > source device to be locked by netif_addr_lock_bh(), but this is missing > in team's enslave function, so add it. > > This fixes the following

Re: pull-request: can 2016-06-20

From: Marc Kleine-Budde Date: Mon, 20 Jun 2016 10:00:27 +0200 > this is a pull request of 3 patches for the upcoming linux-4.7 release. > > The first patch is by Thor Thayer for the c_can/d_can driver. It fixes the > registar access on Altera Cyclone devices, which caused

Re: [PATCH 1/2] net: ethernet: sun4i-emac: use phydev from struct net_device

From: Philippe Reynes Date: Sat, 18 Jun 2016 15:15:39 +0200 > The private structure contain a pointer to phydev, but the structure > net_device already contain such pointer. So we can remove the pointer > phydev in the private structure, and update the driver to use the > one

Re: [PATCH 2/2] net: ethernet: sun4i-emac: use phy_ethtool_{get|set}_link_ksettings

From: Philippe Reynes Date: Sat, 18 Jun 2016 15:15:40 +0200 > There are two generics functions phy_ethtool_{get|set}_link_ksettings, > so we can use them instead of defining the same code in the driver. > > Signed-off-by: Philippe Reynes Applied.

Re: [PATCH 1/2] net: ethernet: bgmac: use phydev from struct net_device

From: Philippe Reynes Date: Sun, 19 Jun 2016 22:37:05 +0200 > The private structure contain a pointer to phydev, but the structure > net_device already contain such pointer. So we can remove the pointer > phydev in the private structure, and update the driver to use the > one

Re: [PATCH 2/2] net: ethernet: bgmac: use phy_ethtool_{get|set}_link_ksettings

From: Philippe Reynes Date: Sun, 19 Jun 2016 22:37:06 +0200 > There are two generics functions phy_ethtool_{get|set}_link_ksettings, > so we can use them instead of defining the same code in the driver. > > Signed-off-by: Philippe Reynes Applied.

Re: [PATCH 2/2] net: ethernet: altera_tse: use phy_ethtool_{get|set}_link_ksettings

From: Philippe Reynes Date: Sat, 18 Jun 2016 16:37:21 +0200 > There are two generics functions phy_ethtool_{get|set}_link_ksettings, > so we can use them instead of defining the same code in the driver. > > Signed-off-by: Philippe Reynes Applied.

Re: [PATCH 1/2] net: ethernet: altera_tse: use phydev from struct net_device

From: Philippe Reynes Date: Sat, 18 Jun 2016 16:37:20 +0200 > The private structure contain a pointer to phydev, but the structure > net_device already contain such pointer. So we can remove the pointer > phydev in the private structure, and update the driver to use the > one

Re: [patch 1/3 -next] liquidio: a couple indenting tweaks

Dan, please don't mix bug fixes and cleanups in the same patch series.

Re: [PATCH] net: cavium: liquidio: Use vzalloc instead of vmalloc

From: Amitoj Kaur Chawla Date: Sat, 18 Jun 2016 12:23:20 +0530 > vzalloc combines vmalloc and memset 0. > > The Coccinelle semantic patch used to make this change is as follows: > @@ > type T; > T *d; > expression e; > statement S; > @@ > > d = > -

Re: [PATCH v2 net-next 2/2] tcp: reduce cpu usage when SO_SNDBUF is set

On Wed, 2016-06-22 at 15:20 -0400, Jason Baron wrote: > hmm, I think we need the smp_mb() there. From > tcp_poll() we have: > > 1) set_bit(SOCK_NOSPACE, ...) (write) > 2) smp_mb__after_atomic(); > 3) if (sk_stream_is_writeable(sk)) (read) > > while in tcp_check_space() its: > > 1) the state

Re: [PATCH iproute2 net-next v4 0/5] bridge: json support for fdb and vlan show

Wed, Jun 22, 2016 at 08:10:47PM CEST, step...@networkplumber.org wrote: >On Wed, 22 Jun 2016 16:53:44 +0200 >Jiri Pirko wrote: > >> Wed, Jun 22, 2016 at 03:45:50PM CEST, ro...@cumulusnetworks.com wrote: >> >From: Roopa Prabhu >> > >> >This patch

Re: [patch net-next v5 0/4] return offloaded stats as default and expose original sw stats

On Tue, Jun 21, 2016 at 8:15 AM, Jiri Pirko wrote: > From: Jiri Pirko > > The problem we try to handle is about offloaded forwarded packets > which are not seen by kernel. Let me try to draw it: > > port1 port2 (HW stats are counted

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

From: David Ahern Date: Tue, 21 Jun 2016 22:06:01 -0600 > On 6/21/16 9:42 PM, Jerry Chu wrote: >> Yes TOU may lower the bar for random hacks by Joe Random. But I'd >> argue >> no large organization would serious consider or dare deploy TCP stack >> with random hacks. >

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

From: Jerry Chu Date: Tue, 21 Jun 2016 20:42:19 -0700 > I don't believe TOU will lead to a proliferation of TCP > implementations in the userland - getting a solid TCP implementation > is hard. The fear isn't doing legitimate things. It's making TCP stacks that do evil stuff

Re: [PATCH v2 net-next 2/2] tcp: reduce cpu usage when SO_SNDBUF is set

On 06/22/2016 02:51 PM, Eric Dumazet wrote: On Wed, 2016-06-22 at 11:43 -0700, Eric Dumazet wrote: On Wed, 2016-06-22 at 14:18 -0400, Jason Baron wrote: For 1/2, the getting the correct memory barrier, should I re-submit that as a separate patch? Are you sure a full memory barrier (smp_mb()

Re: [PATCH v2 net-next 2/2] tcp: reduce cpu usage when SO_SNDBUF is set

On Wed, 2016-06-22 at 11:43 -0700, Eric Dumazet wrote: > On Wed, 2016-06-22 at 14:18 -0400, Jason Baron wrote: > > > > > > > For 1/2, the getting the correct memory barrier, should I re-submit > > that as a separate patch? > > Are you sure a full memory barrier (smp_mb() is needed ? > > Maybe

Re: [PATCH net-next 00/18] mlx5 RoCE/RDMA packet sniffer

From: Saeed Mahameed Date: Tue, 21 Jun 2016 16:10:26 +0300 > I would like to drop this series, Don't worry, I dropped it several days before this.

Re: [PATCH v2 net-next 2/2] tcp: reduce cpu usage when SO_SNDBUF is set

On Wed, 2016-06-22 at 14:18 -0400, Jason Baron wrote: > > > For 1/2, the getting the correct memory barrier, should I re-submit > that as a separate patch? Are you sure a full memory barrier (smp_mb() is needed ? Maybe smp_wmb() would be enough ? (And smp_rmb() in tcp_poll() ?)

[RFC] UAPI for 6lowpan

Hi all, I currently want to search nice solution to adding an UAPI for 6LoWPAN. The current 6LoWPAN UAPI is some dev-hacking stuff in debugfs [0]. Marcel told me before I tried to send upstream patches for radvd [1] I definitely should introduce a stable UAPI concept. The question is here, what

Re: [PATCH iproute2 net-next v4 0/5] bridge: json support for fdb and vlan show

On Wed, Jun 22, 2016 at 11:10 AM, Stephen Hemminger wrote: > On Wed, 22 Jun 2016 16:53:44 +0200 > Jiri Pirko wrote: > >> Wed, Jun 22, 2016 at 03:45:50PM CEST, ro...@cumulusnetworks.com wrote: >> >From: Roopa Prabhu >> > >>

[PATCH] mellanox: mlx5: Use logging functions to reduce text ~10k/5%

The logging macros create a bit of duplicated code/text. Use specialized functions to reduce the duplication. (defconfig/x86-64) $ size drivers/net/ethernet/mellanox/mlx5/core/built-in.o*    text    data bss dec hex filename  178634    2059  16  180709   2c1e5

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

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 stack. >>> First off I am pretty sure this isn't GRO.  This is LRO. >> Nopes.

Re: [PATCH v2 net-next 2/2] tcp: reduce cpu usage when SO_SNDBUF is set

On 06/22/2016 01:34 PM, Eric Dumazet wrote: On Wed, 2016-06-22 at 11:32 -0400, Jason Baron wrote: From: Jason Baron When SO_SNDBUF is set and we are under tcp memory pressure, the effective write buffer space can be much lower than what was set using SO_SNDBUF. For

Re: [PATCH net-next V2] tun: introduce tx skb ring

On Fri, Jun 17, 2016 at 03:41:20AM +0300, Michael S. Tsirkin wrote: > Would it help to have ptr_ring_resize that gets an array of > rings and resizes them both to same length? OK, here it is. Untested so far, and no skb wrapper. Pls let me know whether this is what you had in mind. -->

Re: [PATCH RFC] sched: split classification and enqueue

On Wed, 22 Jun 2016 12:03:55 +0200 Florian Westphal wrote: > Currently classification and enqueue is done in a single step. > > core acquires the qdisc lock, then calls the ->enqueue() function > of the qdisc. > > Its the job of the qdisc and its attached classifiers to figure

Re: rstpd implementation

On Wed, 22 Jun 2016 12:44:52 -0500 ebied...@xmission.com (Eric W. Biederman) wrote: > Phil writes: > > > Hi, > > > > When looking for an RSTP daemon I found Stephen Hemminger's > > git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/rstp.git > >

Re: [PATCH iproute2 net-next v4 0/5] bridge: json support for fdb and vlan show

On Wed, 22 Jun 2016 16:53:44 +0200 Jiri Pirko wrote: > Wed, Jun 22, 2016 at 03:45:50PM CEST, ro...@cumulusnetworks.com wrote: > >From: Roopa Prabhu > > > >This patch series adds json support for a few bridge show commands. > >We plan to follow up

Re: rstpd implementation

Phil writes: > Hi, > > When looking for an RSTP daemon I found Stephen Hemminger's > git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/rstp.git > > with it's last commit from October 2011.

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

On Wed, Jun 22, 2016 at 10:16 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 stack.

Re: 802.3ad bonding aggregator reselection

2016-06-22 3:49 GMT+03:00 Jay Vosburgh : > > Veli-Matti Lintu wrote: > [...] The ports are configured in switch settings (HP Procurve 2530-48G) in same trunk group (TrkX) and trunk group type is set as LACP.

Re: [PATCH RFC] sched: split classification and enqueue

Alexei Starovoitov wrote: > On Wed, Jun 22, 2016 at 3:03 AM, Florian Westphal wrote: > > Currently classification and enqueue is done in a single step. > > > > core acquires the qdisc lock, then calls the ->enqueue() function > > of the qdisc. > > >

Re: [PATCH iproute2 net-next v4 0/5] bridge: json support for fdb and vlan show

On Wed, Jun 22, 2016 at 7:53 AM, Jiri Pirko wrote: > Wed, Jun 22, 2016 at 03:45:50PM CEST, ro...@cumulusnetworks.com wrote: >>From: Roopa Prabhu >> >>This patch series adds json support for a few bridge show commands. >>We plan to follow up with json

[PATCH v3] net: smsc911x: Fix bug where PHY interrupts are overwritten by 0

By default, mdiobus_alloc() sets the PHYs to polling mode, but a pointer size memcpy means that a couple IRQs end up being overwritten with a value of 0. This means that PHY_POLL is disabled and results in unpredictable behavior depending on the PHY's location on the MDIO bus. Remove that memcpy

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On Tue, Jun 21, 2016 at 8:42 PM, Jerry Chu wrote: > On Tue, Jun 21, 2016 at 1:29 AM, David Miller wrote: >> From: Tom Herbert >> Date: Mon, 20 Jun 2016 08:13:48 -0700 >> >>> Routing around the problem is already being done. >> >>

[PATCH] ethernet: xircom: fix spelling mistakes on "excessive collisions"

From: Colin Ian King trivial fixes to spelling mistakes of the words "excessive collisions" Signed-off-by: Colin Ian King --- drivers/net/ethernet/xircom/xirc2ps_cs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [PATCH v2 net-next 2/2] tcp: reduce cpu usage when SO_SNDBUF is set

On Wed, 2016-06-22 at 11:32 -0400, Jason Baron wrote: > From: Jason Baron > > When SO_SNDBUF is set and we are under tcp memory pressure, the effective > write buffer space can be much lower than what was set using SO_SNDBUF. For > example, we may have set the buffer to 100kb,

Re: [PATCH RFC] sched: split classification and enqueue

On Wed, Jun 22, 2016 at 3:03 AM, Florian Westphal wrote: > Currently classification and enqueue is done in a single step. > > core acquires the qdisc lock, then calls the ->enqueue() function > of the qdisc. > > Its the job of the qdisc and its attached classifiers to figure out

Re: [PATCH RFC] sched: split classification and enqueue

Cong Wang wrote: > On Wed, Jun 22, 2016 at 3:03 AM, Florian Westphal wrote: > > > > This (unfinished!) hack splits classification and enqueue into > > two steps. > > > > Before enqueueing the packet and *before* acquiring the root qdisc lock, > > the new

  1   2   3   >