Re: [RESEND PATCH net 07/10] net: ethernet: mediatek: fix issue of driver removal with interface is up

Date: Thu, 25 Aug 2016 15:35:34 +0200, John Crispin wrote: >On 25/08/2016 12:44, Sean Wang wrote: >> 1) mtk_stop() must be called to stop for freeing DMA resources >> acquired and restoring state changed by mtk_open() when module >> removal. >> >> 2) group clock disabled related function into

[PATCH 1/1] net: add killer E2500 device id

>From 5a40989933c7dcd904bebd3c64eaf84445fad1fd Mon Sep 17 00:00:00 2001 From: Owen Lin Date: Fri, 26 Aug 2016 13:49:09 +0800 Subject: [PATCH] Add Killer E2500 device ID in alx driver. --- drivers/net/ethernet/atheros/alx/main.c | 2 ++

Re: [RESEND PATCH net 02/10] net: ethernet: mediatek: fix incorrect

On Date: Thu, 25 Aug 2016 15:49:10 +0200, John Crispin wrote: >On 25/08/2016 12:44, Sean Wang wrote: >> If the return value of devm_clk_get is EPROBE_DEFER, we should >> defer probing the driver. The change is verified and works based >> on 4.8-rc1 staying with the latest clk-next code for MT7623.

Re: [PATCH] net: phy: micrel: remove suspend/resume

Le 24/08/2016 à 07:14, Christophe Leroy a écrit : > > > Le 23/08/2016 à 21:03, Florian Fainelli a écrit : >> +others, >> >> On 08/23/2016 04:13 AM, Christophe Leroy wrote: >>> In ERRATA DS8700A dated 05 May 2016, Microship recommends to >>> not use software power down mode on KSZ8041 family.

Re: [RESEND PATCH net 06/10] net: ethernet: mediatek: fix the loss

On Thu, 25 Aug 2016 15:30:34 +0200, Andrew Lunn wrote: >On Thu, Aug 25, 2016 at 06:44:57PM +0800, Sean Wang wrote: >> ommited the setting about pin-mux which results in incorrect signals >> being routed on GMAC2. > >Hi Sean > >Please could you explain this some more. I don't know too much about

Re: [RFC 1/3] tcp: randomize tcp timestamp offsets for each connection

On Fri, 2016-08-26 at 01:46 +0200, Florian Westphal wrote: > Wrt. making randomization optional: > > Would you go for another sysctl or should I just change > secure_tcpvX_sequence_number to check for tcp_timestamps == 2 mode? > > *tsoff = sysctl_tcp_timestamps == 2 ? hash[1] : 0; I've

Re: [RFC v2 09/10] landlock: Handle cgroups

On Thu, Aug 25, 2016 at 12:32:44PM +0200, Mickaël Salaün wrote: > Add an eBPF function bpf_landlock_cmp_cgroup_beneath(opt, map, map_op) > to compare the current process cgroup with a cgroup handle, The handle > can match the current cgroup if it is the same or a child. This allows > to make

Re: [PATCH net-next] drivers/net: Use priority level to printk() calls

On Fri, 2016-08-26 at 00:22 +0200, citestra wrote: > Add priority level 'KERN_ERR' to a printk() call [] > diff --git a/drivers/net/ethernet/amd/am79c961a.c > b/drivers/net/ethernet/amd/am79c961a.c [] > @@ -182,7 +182,7 @@ am79c961_ramtest(struct net_device *dev, unsigned int val) >  

Re: [PATCH] net: hns: dereference ppe_cb->ppe_common_cb if it is non-null

在 2016/8/25 14:51, Colin King 写道: > From: Colin Ian King > > ppe_cb->ppe_common_cb is being dereferenced before a null check is > being made on it. If ppe_cb->ppe_common_cb is null then we end up > with a null pointer dereference when assigning dsaf_dev. Fix this >

Re: [ovs-dev] [PATCH net-next v11 5/6] openvswitch: add layer 3 flow/port support

On 25 August 2016 at 03:08, Simon Horman wrote: > Please find my working patch below. > > From: Simon Horman > Subject: [PATCH] system-traffic: Exercise GSO > > Exercise GSO for: unencapsulated; MPLS; GRE; and MPLS in GRE. > > There is scope to

Re: [PATCH v1 1/1 net-next] 8139cp: Fix one possible deadloop in cp_rx_poll

From: f...@ikuai8.com Date: Thu, 25 Aug 2016 09:45:39 +0800 > From: Gao Feng > > When cp_rx_poll does not get enough packet, it will check the rx > interrupt status again. If so, it will jumpt to rx_status_loop again. > But the goto jump resets the rx variable as zero too. > >

Re: [PATCH v2] net: macb: Increase DMA TX buffer size

From: Xander Huff Date: Wed, 24 Aug 2016 17:25:39 -0500 > From: Nathan Sullivan > > In recent testing with the RT patchset, we have seen cases where the > transmit ring can fill even with up to 200 txbds in the ring. Increase the > size of the DMA TX

Re: [PATCH v2] Revert "phy: IRQ cannot be shared"

From: Xander Huff Date: Wed, 24 Aug 2016 16:47:53 -0500 > This reverts: > commit 33c133cc7598 ("phy: IRQ cannot be shared") > > On hardware with multiple PHY devices hooked up to the same IRQ line, allow > them to share it. > > Sergei Shtylyov says: > "I'm not sure now

Re: [net] i40e: Change some init flow for the client

From: Jeff Kirsher Date: Wed, 24 Aug 2016 17:51:53 -0700 > From: Anjali Singhai Jain > > This change makes a common flow for Client instance open during init > and reset path. The Client subtask can handle both the cases instead of >

Re: [PATCH] net: systemport: Fix ordering in intrl2_*_mask_clear macro

From: Florian Fainelli Date: Wed, 24 Aug 2016 14:21:41 -0700 > Since we keep shadow copies of which interrupt sources are enabled > through the intrl2_*_mask_{set,clear} macros, make sure that the > ordering in which we do these two operations: update the copy, then >

Re: [PATCH net] net: dsa: bcm_sf2: Fix race condition while unmasking interrupts

From: Florian Fainelli Date: Wed, 24 Aug 2016 11:01:20 -0700 > We kept shadow copies of which interrupt sources we have enabled and > disabled, but due to an order bug in how intrl2_mask_clear was defined, > we could run into the following scenario: > > CPU0

Re: [PATCH -next] ibmvnic: convert to use simple_open()

From: Wei Yongjun Date: Wed, 24 Aug 2016 13:50:03 + > From: Wei Yongjun > > Remove an open coded simple_open() function and replace file > operations references to the function with simple_open() > instead. > > Generated by:

Re: [PATCH -next] ibmvnic: fix error return code in ibmvnic_probe()

From: Wei Yongjun Date: Wed, 24 Aug 2016 13:47:58 + > From: Wei Yongjun > > Fix to return error code -ENOMEM from the dma_map_single error > handling case instead of 0, as done elsewhere in this function. > > Fixes: 032c5e82847a ("Driver for IBM

Re: [PATCH] [v8] net: emac: emac gigabit ethernet controller driver

Florian Fainelli wrote: >>Since you have a check on CONFIG_QCOM_EMAC in emac/Makefile, you could >>always recurse into that directory while building (use obj-y). > >Obviously, having "obj-$(CONFIG_QCOM_EMAC)" in both Makefiles is >redundant, but wouldn't it make more sense to change

Re: [PATCH net-next 1/2] cxgb4/cxgb4vf: Add support for ndo_set_vf_vlan

From: Hariprasad Shenai Date: Wed, 24 Aug 2016 12:20:33 +0530 > + dev_info(pi->adapter->pdev_dev, > + "Setting Vlan %u to VF [%d]\n", vlan, vf); > + dev_info(pi->adapter->pdev_dev, > + "The VF [%d] interface needs to brought down and up,

Re: [PATCH net-next] net: minor optimization in qdisc_qstats_cpu_drop()

From: Eric Dumazet Date: Wed, 24 Aug 2016 10:23:34 -0700 > From: Eric Dumazet > > per_cpu_inc() is faster (at least on x86) than per_cpu_ptr(xxx)++; > > Signed-off-by: Eric Dumazet Applied.

Re: [PATCH net] qdisc: fix a module refcount leak in qdisc_create_dflt()

From: Eric Dumazet Date: Wed, 24 Aug 2016 09:39:02 -0700 > From: Eric Dumazet > > Should qdisc_alloc() fail, we must release the module refcount > we got right before. > > Fixes: 6da7c8fcbcbd ("qdisc: allow setting default queuing discipline") >

Re: [RFC 1/3] tcp: randomize tcp timestamp offsets for each connection

Eric Dumazet wrote: > On Thu, 2016-08-18 at 14:48 +0200, Florian Westphal wrote: > > commit ceaa1fef65a7c2e ("tcp: adding a per-socket timestamp offset") > > added the main infrastructure that is needed for per-connection > > randomization, in particular writing/reading

Re: [PATCH -next] tipc: fix the error handling in tipc_udp_enable()

From: Wei Yongjun Date: Wed, 24 Aug 2016 13:32:19 + > From: Wei Yongjun > > Fix to return a negative error code in enable_mcast() error handling > case, and release udp socket when necessary. > > Fixes: d0f91938bede ("tipc: add ip/udp media

Re: [PATCH v2] vmxnet3: fix non static symbol warning

From: Wei Yongjun Date: Wed, 24 Aug 2016 15:07:26 + > From: Wei Yongjun > > Fixes the following sparse warning: > > drivers/net/vmxnet3/vmxnet3_drv.c:1645:1: warning: > symbol 'vmxnet3_rq_destroy_all_rxdataring' was not declared. Should it be

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

On Thu, Aug 25, 2016 at 3:55 PM, Rick Jones wrote: > From: Rick Jones > > Since XPS was first introduced two things have happened. Some drivers > have started enabling XPS on their own initiative, and it has been > found that when a VM is sending data

Re: [PATCH net-next] tcp: md5: increment sk_drops on syn_recv state

From: Eric Dumazet Date: Wed, 24 Aug 2016 08:50:24 -0700 > From: Eric Dumazet > > TCP MD5 mismatches do increment sk_drops counter in all states but > SYN_RECV. > > This is very unlikely to happen in the real world, but worth adding > to help

Re: [PATCH net-next] tcp: md5: add LINUX_MIB_TCPMD5FAILURE counter

From: Eric Dumazet Date: Wed, 24 Aug 2016 09:01:23 -0700 > From: Eric Dumazet > > Adds SNMP counter for drops caused by MD5 mismatches. > > The current syslog might help, but a counter is more precise and helps > monitoring. > > Signed-off-by:

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

From: Rick Jones Since XPS was first introduced two things have happened. Some drivers have started enabling XPS on their own initiative, and it has been found that when a VM is sending data through a host interface with XPS enabled, that traffic can end-up seriously out of

Re: [PATCH 1/2] smc91x: always use 8-bit access if necessary

On Thu, Aug 25, 2016 at 04:46:20PM +0200, Arnd Bergmann wrote: > +#define SMC_out16(x, ioaddr, reg) \ > +do { \ > + if (SMC_CAN_USE_8BIT && !SMC_16BIT(lp)) {

Re: Improving OCTEON II 10G Ethernet performance

On 08/25/2016 02:18 PM, Aaro Koskinen wrote: Hi, On Thu, Aug 25, 2016 at 01:11:45PM -0700, David Daney wrote: On 08/25/2016 11:22 AM, Aaro Koskinen wrote: On Thu, Aug 25, 2016 at 09:50:15AM -0700, David Daney wrote: Ideally we would configure the packet classifiers on the RX side to create

Re: [PATCH] smc91x: remove ARM hack for unaligned 16-bit writes

On Thu, Aug 25, 2016 at 08:02:35PM +0200, Robert Jarzmik wrote: > Arnd Bergmann writes: > > > On Thursday, August 25, 2016 4:43:04 PM CEST Arnd Bergmann wrote: > >> drivers/net/ethernet/smsc/smc91x.h | 50 > >> +++--- > >> 1 file changed, 30

[PATCH net-next] drivers/net: Use priority level to printk() calls

Add priority level 'KERN_ERR' to a printk() call Signed-off-by: Oussama Markad Signed-off-by: citestra --- drivers/net/ethernet/amd/am79c961a.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH] net: dsa: bcm_sf2: Utilize mask clear/set helpers in bcm_sf2_intr_disable

On 08/25/2016 03:20 PM, Florian Fainelli wrote: > From: Florian Fainelli > > And while at it, remove the unecessary writing of zeroes to the CPU_MASK_CLEAR > register since it has no functional use. > > refs #SWLINUX-4144 > > Signed-off-by: Florian Fainelli

[PATCH net-next] net: dsa: bcm_sf2: Utilize mask clear/set helpers in bcm_sf2_intr_disable

And while at it, remove the unecessary writing of zeroes to the CPU_MASK_CLEAR register since it has no functional use. Signed-off-by: Florian Fainelli --- drivers/net/dsa/bcm_sf2.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git

[PATCH] net: dsa: bcm_sf2: Utilize mask clear/set helpers in bcm_sf2_intr_disable

From: Florian Fainelli And while at it, remove the unecessary writing of zeroes to the CPU_MASK_CLEAR register since it has no functional use. refs #SWLINUX-4144 Signed-off-by: Florian Fainelli --- drivers/net/dsa/bcm_sf2.c | 6

Re: possible memory leak in ipc

On Thu, Aug 25, 2016 at 1:17 PM, CAI Qian wrote: > I am unsure if it is really a memleak (could be a security issue due to > eventually OOM and DoS) or just a soft lockup with in kmemlock code with > false alarm. Hmm. The reported leaks look like unreferenced object

Re: [RFC 1/3] tcp: randomize tcp timestamp offsets for each connection

On Thu, 2016-08-18 at 14:48 +0200, Florian Westphal wrote: > commit ceaa1fef65a7c2e ("tcp: adding a per-socket timestamp offset") > added the main infrastructure that is needed for per-connection > randomization, in particular writing/reading the on-wire tcp header > format takes the offset into

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

On Thu, Aug 25, 2016 at 2:33 PM, Rick Jones wrote: > From: Rick Jones > > Since XPS was first introduced two things have happened. Some drivers > have started enabling XPS on their own initiative, and it has been > found that when a VM is sending data

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

On Thu, Aug 25, 2016 at 12:49 PM, Eric Dumazet wrote: > On Thu, 2016-08-25 at 12:23 -0700, Alexander Duyck wrote: >> I have been seeing a number of issues where XPS leads to issues with >> packets being reordered in the transmit queues of the device drivers. The >> main

[PATCH] [v9] net: emac: emac gigabit ethernet controller driver

Add support for the Qualcomm Technologies, Inc. EMAC gigabit Ethernet controller. This driver supports the following features: 1) Checksum offload. 2) Interrupt coalescing support. 3) SGMII phy. 4) phylib interface for external phy Based on original work by Niranjana Vishwanathapura

Re: [PATCH 0/5] Networking cgroup controller

On Thu, Aug 25, 2016 at 11:56:27AM -0700, Mahesh Bandewar (महेश बंडेवार) wrote: > On Thu, Aug 25, 2016 at 11:04 AM, Alexei Starovoitov > wrote: > > On Thu, Aug 25, 2016 at 08:54:19AM -0700, Mahesh Bandewar (महेश बंडेवार) > > wrote: > >> On Wed, Aug 24, 2016 at 2:03

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

From: Rick Jones Since XPS was first introduced two things have happened. Some drivers have started enabling XPS on their own initiative, and it has been found that when a VM is sending data through a host interface with XPS enabled, that traffic can end-up seriously out of

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

On 08/25/2016 02:08 PM, Eric Dumazet wrote: When XPS was submitted, it was _not_ enabled by default and 'magic' Some NIC vendors decided it was a good thing, you should complain to them ;) I kindasorta am with the emails I've been sending to netdev :) And also hopefully precluding others

Re: Improving OCTEON II 10G Ethernet performance

On 08/24/2016 06:29 PM, Ed Swierk wrote: I'm trying to migrate from the Octeon SDK to a vanilla Linux 4.4 kernel for a Cavium OCTEON II (CN6880) board running in 64-bit little-endian mode. So far I've gotten most of the hardware features I need working, including XAUI/RXAUI, USB, boot bus and

Re: Improving OCTEON II 10G Ethernet performance

Hi, On Thu, Aug 25, 2016 at 01:11:45PM -0700, David Daney wrote: > On 08/25/2016 11:22 AM, Aaro Koskinen wrote: > >On Thu, Aug 25, 2016 at 09:50:15AM -0700, David Daney wrote: > >>Ideally we would configure the packet classifiers on the RX side to create > >>multiple RX queues based on a hash of

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

On Thu, Aug 25, 2016 at 1:32 PM, Rick Jones wrote: > On 08/25/2016 12:49 PM, Eric Dumazet wrote: >> >> On Thu, 2016-08-25 at 12:23 -0700, Alexander Duyck wrote: >>> >>> A simpler approach is provided with this patch. With it we disable XPS >>> any >>> time a socket is not

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

On Thu, 2016-08-25 at 13:32 -0700, Rick Jones wrote: > On 08/25/2016 12:49 PM, Eric Dumazet wrote: > > On Thu, 2016-08-25 at 12:23 -0700, Alexander Duyck wrote: > >> A simpler approach is provided with this patch. With it we disable XPS any > >> time a socket is not present for a given flow. By

Re: [RFC 1/3] tcp: randomize tcp timestamp offsets for each connection

On Thu, 2016-08-25 at 22:31 +0200, Florian Westphal wrote: > Eric Dumazet wrote: > > On Thu, 2016-08-18 at 14:48 +0200, Florian Westphal wrote: > > It seems tcp_v4_reqsk_send_ack() and tcp_v6_reqsk_send_ack() were not > > taken into account. > > > > See commit

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

On Thu, Aug 25, 2016 at 12:19 PM, Alexander Duyck wrote: > On Wed, Aug 24, 2016 at 4:46 PM, Rick Jones wrote: >> Also, while it doesn't seem to have the same massive effect on throughput, I >> can also see out of order behaviour happening when the

Re: Improving OCTEON II 10G Ethernet performance

On 08/25/2016 11:22 AM, Aaro Koskinen wrote: Hi, On Thu, Aug 25, 2016 at 09:50:15AM -0700, David Daney wrote: Ideally we would configure the packet classifiers on the RX side to create multiple RX queues based on a hash of the TCP 5-tuple, and handle each queue with a single NAPI instance.

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

On Thu, Aug 25, 2016 at 1:18 PM, Rick Jones wrote: > On 08/25/2016 12:19 PM, Alexander Duyck wrote: >> >> The problem is that there is no socket associated with the guest from >> the host's perspective. This is resulting in the traffic bouncing >> between queues because

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

On 08/25/2016 12:49 PM, Eric Dumazet wrote: On Thu, 2016-08-25 at 12:23 -0700, Alexander Duyck wrote: A simpler approach is provided with this patch. With it we disable XPS any time a socket is not present for a given flow. By doing this we can avoid using XPS for any routing or bridging

Re: [RFC 1/3] tcp: randomize tcp timestamp offsets for each connection

Eric Dumazet wrote: > On Thu, 2016-08-18 at 14:48 +0200, Florian Westphal wrote: > It seems tcp_v4_reqsk_send_ack() and tcp_v6_reqsk_send_ack() were not > taken into account. > > See commit 20a2b49fc5385 changelog > packetdrill test showing the possible issue if the TS

Re: [PATCH iproute] iptuntap: show processes using tuntap interface

On 25.08.2016 17:44, Stephen Hemminger wrote: > On Wed, 24 Aug 2016 20:08:25 +0200 > Hannes Frederic Sowa wrote: > >> Show which processes are using which tun/tap devices, e.g.: >> >> $ ip -d tuntap >> tun0: tun >> Attached to processes: vpnc(9531) >> vnet0: tap

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

On 08/25/2016 12:19 PM, Alexander Duyck wrote: The problem is that there is no socket associated with the guest from the host's perspective. This is resulting in the traffic bouncing between queues because there is no saved socket to lock the interface onto. I was looking into this recently

Re: [RFC PATCH 4/5] net: filter: run cgroup eBPF programs

Hello, Sargun. On Sun, Aug 21, 2016 at 01:14:22PM -0700, Sargun Dhillon wrote: > So, casually looking at this patch, it looks like you're relying on > sock_cgroup_data, which only points to the default hierarchy. If someone uses > net_prio or net_classid, cgroup_sk_alloc_disable is called, and

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

On Thu, 2016-08-25 at 12:23 -0700, Alexander Duyck wrote: > I have been seeing a number of issues where XPS leads to issues with > packets being reordered in the transmit queues of the device drivers. The > main situation where this seems to occur is when a VM us using a tap > interface to send

Re: [RFC 1/3] tcp: randomize tcp timestamp offsets for each connection

On Thu, 2016-08-18 at 14:48 +0200, Florian Westphal wrote: > commit ceaa1fef65a7c2e ("tcp: adding a per-socket timestamp offset") > added the main infrastructure that is needed for per-connection > randomization, in particular writing/reading the on-wire tcp header > format takes the offset into

Re: [patch net] team: loadbalance: push lacpdus to exact delivery

On Thu, Aug 25, 2016 at 9:23 AM, Jiri Pirko wrote: > From: Jiri Pirko > > When team is in bridge and LACP is utilized, LACPDU packets are pushed > to userspace using raw socket and there they are processed. However, > since 8626c56c8279b, LACPDU skbs are

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

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

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

I have been seeing a number of issues where XPS leads to issues with packets being reordered in the transmit queues of the device drivers. The main situation where this seems to occur is when a VM us using a tap interface to send packets to the network via a NIC that has XPS enabled. A bit of

pull request: bluetooth 2016-08-25

Hi Dave, Here are a couple of important Bluetooth fixes for the 4.8 kernel: - Memory leak fix for HCI requests - Fix sk_filter handling with L2CAP - Fix sock_recvmsg behavior when MSG_TRUNC is not set Please let me know if there are any issues pulling. Thanks. Johan --- The following

RE: [PATCH -next] igb: fix non static symbol warning

> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Wei Yongjun > Sent: Tuesday, August 23, 2016 8:08 AM > To: Kirsher, Jeffrey T > Cc: Wei Yongjun ; intel-wired- > l...@lists.osuosl.org;

[PATCH V2 net-next] alx: add tso support

Add tso/tso6 support to the alx driver. Based on information from the downstream driver at github.com/qca/alx Signed-off-by: Tobias Regnery --- Changes in V2: - don't inline alx_tpd_req drivers/net/ethernet/atheros/alx/main.c | 75

Re: [PATCH 0/5] Networking cgroup controller

On Thu, Aug 25, 2016 at 11:04 AM, Alexei Starovoitov wrote: > On Thu, Aug 25, 2016 at 08:54:19AM -0700, Mahesh Bandewar (महेश बंडेवार) > wrote: >> On Wed, Aug 24, 2016 at 2:03 PM, Tejun Heo wrote: >> > Hello, Anoop. >> > >> > On Wed, Aug 10, 2016

Re: [PATCH 0/5] Networking cgroup controller

On Thu, Aug 25, 2016 at 9:09 AM, Tejun Heo wrote: > Hello, Mahesh. > > On Thu, Aug 25, 2016 at 08:54:19AM -0700, Mahesh Bandewar (महेश बंडेवार) > wrote: >> In short most of the associated problems are handled by the >> cgroup-infra / APIs while all that need separate solution in

Re: Improving OCTEON II 10G Ethernet performance

Hi, On Thu, Aug 25, 2016 at 09:50:15AM -0700, David Daney wrote: > Ideally we would configure the packet classifiers on the RX side to create > multiple RX queues based on a hash of the TCP 5-tuple, and handle each queue > with a single NAPI instance. That should result in better performance

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

On Wed, Aug 24, 2016 at 10:06 PM, Yuval Mintz wrote: >> >> This patch assumes that the bnx2x 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

Re: [PATCH 2/2] smc91x: remove ARM hack for unaligned 16-bit writes

On Thu, 25 Aug 2016, Arnd Bergmann wrote: > The ARM specific I/O operations are almost the same as the generic > ones, with the exception of the SMC_outw macro that works around > a problem of some platforms that cannot write to 16-bit registers > at an address that is not 32-bit aligned. > > By

Re: [PATCH 0/5] Networking cgroup controller

On Thu, Aug 25, 2016 at 08:54:19AM -0700, Mahesh Bandewar (महेश बंडेवार) wrote: > On Wed, Aug 24, 2016 at 2:03 PM, Tejun Heo wrote: > > Hello, Anoop. > > > > On Wed, Aug 10, 2016 at 05:53:13PM -0700, Anoop Naravaram wrote: > >> This patchset introduces a cgroup controller for the

Re: [PATCH v2 1/2] smc91x: always use 8-bit access if necessary

On Thu, 25 Aug 2016, Arnd Bergmann wrote: > As Russell King found out the hard way, a change I did to fix multiplatform > builds with this driver broke the old Assabet/Neponset platform: It turns > out that while the driver is runtime configurable in principle, the > runtime configuration does

Re: [PATCH] smc91x: remove ARM hack for unaligned 16-bit writes

Arnd Bergmann writes: > On Thursday, August 25, 2016 4:43:04 PM CEST Arnd Bergmann wrote: >> drivers/net/ethernet/smsc/smc91x.h | 50 >> +++--- >> 1 file changed, 30 insertions(+), 20 deletions(-) >> >> While this patch fixes one bug on Neponset,

Re: Improving OCTEON II 10G Ethernet performance

Hi, On Wed, Aug 24, 2016 at 06:29:49PM -0700, Ed Swierk wrote: > I'm trying to migrate from the Octeon SDK to a vanilla Linux 4.4 > kernel for a Cavium OCTEON II (CN6880) board running in 64-bit > little-endian mode. So far I've gotten most of the hardware features I > need working, including

Re: [PATCH net-next V3 4/4] net/sched: Introduce act_tunnel_key

On Thu, 2016-08-25 at 19:13 +0300, Hadar Hen Zion wrote: > From: Amir Vadai > > This action could be used before redirecting packets to a shared tunnel > device, or when redirecting packets arriving from a such a device. > > The action will release the metadata created by the

Re: [patch net] team: loadbalance: push lacpdus to exact delivery

On Thu, Aug 25, 2016 at 9:46 AM, Jiri Pirko wrote: > Thu, Aug 25, 2016 at 06:37:35PM CEST, mahe...@google.com wrote: >>On Thu, Aug 25, 2016 at 9:23 AM, Jiri Pirko wrote: >>> From: Jiri Pirko >>> >>> When team is in bridge and LACP is

[patch net v2] team: loadbalance: push lacpdus to exact delivery

From: Jiri Pirko When team is in bridge and LACP is utilized, LACPDU packets are pushed to userspace using raw socket and there they are processed. However, since 8626c56c8279b, LACPDU skbs are dropped by bridge rx_handler so they never reach packet handlers in rx path. Fix

Re: [PATCH 0/5] Networking cgroup controller

On Thu, Aug 25, 2016 at 12:09:20PM -0400, Tejun Heo wrote: > ebpf approach does have its shortcomings for sure but mending them > seems a lot more manageable and future-proof than going with fixed but > constantly expanding set of operations. e.g. We can add per-cgroup > bpf programs which are

[PATCH net-next v4 1/2] net: ethernet: mediatek: modify to use the PDMA instead of the QDMA for Ethernet RX

Because the PDMA has richer features than the QDMA for Ethernet RX (such as multiple RX rings, HW LRO, etc.), the patch modifies to use the PDMA to handle Ethernet RX. Acked-by: John Crispin Signed-off-by: Nelson Chang ---

[PATCH net-next v4 2/2] net: ethernet: mediatek: modify GDM to send packets to the PDMA for RX

Because we change to use the PDMA as the Ethernet RX DMA engine, the patch modifies to set GDM to send packets to PDMA for RX. Acked-by: John Crispin Signed-off-by: Nelson Chang --- drivers/net/ethernet/mediatek/mtk_eth_soc.c | 3 +-- 1 file

[PATCH net-next v4 0/2] net: ethernet: mediatek: modify to use the PDMA for Ethernet RX

This series have some modifications and refines to support Ethernet RX by the PDMA. changes since v4: - Remove the redundant OR operation in mtk_hw_init() changes since v3: - Add GDM hardware settings to send packets to PDMA for RX changes since v2: - Fix the bugs of PDMA cpu index and

Re: [patch net] team: loadbalance: push lacpdus to exact delivery

Hi Jiri, [auto build test ERROR on net/master] url: https://github.com/0day-ci/linux/commits/Jiri-Pirko/team-loadbalance-push-lacpdus-to-exact-delivery/20160826-004635 config: sparc64-allyesconfig (attached as .config) compiler: sparc64-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609

Re: [patch net] team: loadbalance: push lacpdus to exact delivery

Thu, Aug 25, 2016 at 06:37:35PM CEST, mahe...@google.com wrote: >On Thu, Aug 25, 2016 at 9:23 AM, Jiri Pirko wrote: >> From: Jiri Pirko >> >> When team is in bridge and LACP is utilized, LACPDU packets are pushed >> to userspace using raw socket and there

Re: [PATCH net-next V3 4/4] net/sched: Introduce act_tunnel_key

Hi, On Thu, 25 Aug 2016 19:13:47 +0300 Hadar Hen Zion wrote: > +static int tunnel_key_act(struct sk_buff *skb, const struct tc_action *a, > + struct tcf_result *res) > +{ > + struct tcf_tunnel_key *t = to_tunnel_key(a); > + int action; > + > +

Re: [PATCH 1/2] smc91x: always use 8-bit access if necessary

Hi Arnd, [auto build test WARNING on net-next/master] [also build test WARNING on v4.8-rc3 next-20160825] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for convenie

[patch net-next 2/5] bridge: switchdev: Add forward mark support for stacked devices

From: Ido Schimmel switchdev_port_fwd_mark_set() is used to set the 'offload_fwd_mark' of port netdevs so that packets being flooded by the device won't be flooded twice. It works by assigning a unique identifier (the ifindex of the first bridge port) to bridge ports

[patch net-next 5/5] mlxsw: spectrum: Mirror certain packets to CPU

From: Ido Schimmel Instead of trapping certain packets to the CPU and then relying on it to flood them we can instead make the device mirror them. The following packet types are mirrored: * DHCP: Broadcast packets that should be flooded by the device, but also trapped in

[patch net-next 1/5] switchdev: Support parent ID comparison for stacked devices

From: Ido Schimmel switchdev_port_same_parent_id() currently expects port netdevs, but we need it to support stacked devices in the next patch, so drop the NO_RECURSE flag. Signed-off-by: Ido Schimmel Signed-off-by: Jiri Pirko ---

[patch net-next 4/5] mlxsw: spectrum: Allow different traps to have different actions

From: Ido Schimmel Up until now we only trapped packets to CPU, but we are going to allow some packets to be mirrored (trap & forward) to CPU. Extend the Rx listener with 'action' member. Signed-off-by: Ido Schimmel Signed-off-by: Jiri Pirko

[patch net-next 3/5] mlxsw: spectrum: Simplify traps definition

From: Ido Schimmel Instead of copying & pasting the same struct initialization for every Rx listener, just use a macro. Signed-off-by: Ido Schimmel Signed-off-by: Jiri Pirko --- drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 146

[patch net-next 0/5] mlxsw: Introduce support for offload forward mark

From: Jiri Pirko Ido says: This patchset enables the forwarding of certain control packets by the device instead of relying on the CPU to do the forwarding. The first two patches simplify the current switchdev offload forward infrastructure and make it usable for stacked

[PATCH net] sunrpc: fix UDP memory accounting

The commit f9b2ee714c5c ("SUNRPC: Move UDP receive data path into a workqueue context"), as a side effect, moved the skb_free_datagram() call outside the scope of the related socket lock, but UDP sockets require such lock to be held for proper memory accounting. Fix it by replacing

Re: [PATCH net-next V3 2/4] net/dst: Utility functions to build dst_metadata without supplying an skb

Hi, On Thu, 25 Aug 2016 19:13:45 +0300 Hadar Hen Zion wrote: > From: Amir Vadai > > Extract _ip_tun_rx_dst() and _ipv6_tun_rx_dst() out of ip_tun_rx_dst() > and ipv6_tun_rx_dst(), to be used without supplying an skb. Per this v3, the newly introduced

Re: [RFC 1/3] tcp: randomize tcp timestamp offsets for each connection

On Thu, 2016-08-25 at 16:49 +0200, Florian Westphal wrote: > Eric Dumazet wrote: > > Here at Google we have been using usec resolution in TCP timestamps for > > a while for all our DC traffic, and we have to upstream this at some > > point. > > > > It would be nice if the

Re: [patch net] team: loadbalance: push lacpdus to exact delivery

Thu, Aug 25, 2016 at 06:23:34PM CEST, j...@resnulli.us wrote: >From: Jiri Pirko > >When team is in bridge and LACP is utilized, LACPDU packets are pushed >to userspace using raw socket and there they are processed. However, >since 8626c56c8279b, LACPDU skbs are dropped by

Re: [PATCH net-next] net: flush the softnet backlog in process context

On Thu, 2016-08-25 at 16:58 +0200, Paolo Abeni wrote: > On Thu, 2016-08-25 at 07:47 -0700, Eric Dumazet wrote: > > On Thu, 2016-08-25 at 07:32 -0700, Eric Dumazet wrote: > > > > > In a future patch, we could change this so that we kick > > > flush_all_backlogs() once for all devices, instead of

[PATCH net-next 1/6] net: dsa: b53: Initialize ds->drv in b53_switch_alloc

In order to alloc drivers to override specific dsa_switch_driver callbacks, initialize ds->drv to b53_switch_ops earlier, which avoids having to expose this structure to glue drivers. Signed-off-by: Florian Fainelli --- drivers/net/dsa/b53/b53_common.c | 3 +-- 1 file

[PATCH net-next-v2 1/6] net: dsa: b53: Initialize ds->ops in b53_switch_alloc

In order to allow drivers to override specific dsa_switch_driver callbacks, initialize ds->ops to b53_switch_ops earlier, which avoids having to expose this structure to glue drivers. Signed-off-by: Florian Fainelli --- drivers/net/dsa/b53/b53_common.c | 3 +-- 1 file

[PATCH net-next-v2 4/6] net: dsa: b53: Add JOIN_ALL_VLAN support

In order to migrate the bcm_sf2 driver over to the b53 driver for most VLAN/FDB/bridge operations, we need to add support for the "join all VLANs" register and behavior which allows us to make a given port join all VLANs and avoid setting specific VLAN entries when it is leaving the bridge.

Re: [PATCH net 00/10] net: ethernet: mediatek: a couple of fixes

From: Sean Wang Date: Thu, 25 Aug 2016 18:22:27 +0800 You really need to fix whatever you used to send this patch set out, all of the email header fields were messed up.

  1   2   3   >