Re: [PATCH v2 net-next 7/7] tcp: make tcp_sendmsg() aware of socket backlog

On 4/28/16 10:05 PM, Eric Dumazet wrote: On Thu, 2016-04-28 at 21:43 -0700, Alexei Starovoitov wrote: I don't understand the logic completely, but isn't it safer to do 'goto wait_for_memory;' here if we happened to hit this in the middle of the loop? Well, the wait_for_memory pushes data,

Re: [PATCH v2 net-next 7/7] tcp: make tcp_sendmsg() aware of socket backlog

On Thu, 2016-04-28 at 21:43 -0700, Alexei Starovoitov wrote: > > I don't understand the logic completely, but isn't it > safer to do 'goto wait_for_memory;' here if we happened > to hit this in the middle of the loop? Well, the wait_for_memory pushes data, and could early return to user space

Re: [RFC PATCH V2 2/2] vhost: device IOTLB API

On 04/29/2016 09:12 AM, Jason Wang wrote: > On 04/28/2016 10:43 PM, Michael S. Tsirkin wrote: >> > On Thu, Apr 28, 2016 at 02:37:16PM +0800, Jason Wang wrote: >>> >> >>> >> On 04/27/2016 07:45 PM, Michael S. Tsirkin wrote: >>> On Fri, Mar 25, 2016 at 10:34:34AM +0800, Jason Wang wrote:

Re: [PATCH v2 net-next 7/7] tcp: make tcp_sendmsg() aware of socket backlog

On 4/28/16 8:10 PM, Eric Dumazet wrote: Large sendmsg()/write() hold socket lock for the duration of the call, unless sk->sk_sndbuf limit is hit. This is bad because incoming packets are parked into socket backlog for a long time. Critical decisions like fast retransmit might be delayed.

[PATCH v2 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 v2 net-next 7/7] tcp: make tcp_sendmsg() aware of socket backlog

Large sendmsg()/write() hold socket lock for the duration of the call, unless sk->sk_sndbuf limit is hit. This is bad because incoming packets are parked into socket backlog for a long time. Critical decisions like fast retransmit might be delayed. Receivers have to maintain a big out of order

[PATCH v2 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 --- net/ipv4/udp.c | 4 ++-- net/ipv6/udp.c | 4 ++-- 2 files changed, 4

[PATCH v2 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 --- net/dccp/input.c | 2 +- net/dccp/ipv4.c| 4 ++-- net/dccp/ipv6.c| 4 ++-- net/dccp/options.c | 2 +- 4 files changed,

[PATCH v2 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 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

[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 v2 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: [PATCH] mdio_bus: Fix MDIO bus scanning in __mdiobus_register()

ad of NULL if the PHY device ID is >> all ones. >> >> This causes problem with stmmac driver and likely some other drivers >> which call mdiobus_register(). I triggered this bug on SoCFPGA MCVEVK >> board with linux-next 20160427 and 20160428. In case of the stm

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

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. >> >>The Intel documentation said the same thing. That was due to the fact >>that the hardware

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

his causes problem with stmmac driver and likely some other drivers > which call mdiobus_register(). I triggered this bug on SoCFPGA MCVEVK > board with linux-next 20160427 and 20160428. In case of the stmmac, if > there is no PHY node specified in the DT for the stmmac block, the stmmac >

[PATCH] tipc: Only process unicast on intended node

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 actually been transmitted to them. Consider an example

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

>> >> The mlx5 hardware requires the outer UDP checksum is not set when offloading >> encapsulated packets. > >The Intel documentation said the same thing. That was due to the fact >that the hardware didn't computer the outer UDP header checksum. I >suspect the Mellanox hardware has the

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

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 however needed nearly everywhere. Pass ps, not ds internally. [vd: rebased Andrew's patch.] Signed-off-by: Andrew Lunn

Re: [PATCHv2] netem: Segment GSO packets on enqueue.

On Thu, Apr 28, 2016 at 01:58:53PM -0700, Eric Dumazet wrote: > On Thu, 2016-04-28 at 16:09 -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

Re: [RFC PATCH V2 2/2] vhost: device IOTLB API

On 04/28/2016 10:43 PM, Michael S. Tsirkin wrote: > On Thu, Apr 28, 2016 at 02:37:16PM +0800, Jason Wang wrote: >> >> On 04/27/2016 07:45 PM, Michael S. Tsirkin wrote: >>> On Fri, Mar 25, 2016 at 10:34:34AM +0800, Jason Wang wrote: This patch tries to implement an device IOTLB for vhost.

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

mdiobus_register(). I triggered this bug on SoCFPGA MCVEVK board with linux-next 20160427 and 20160428. In case of the stmmac, if there is no PHY node specified in the DT for the stmmac block, the stmmac driver ( drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c function stmmac_mdio_register

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

On Wed, 2016-04-27 at 22:25 -0700, Eric Dumazet wrote: > 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

[PATCH net-next 1/3] qed: add infrastructure for device self tests.

This patch adds the functionality and APIs needed for selftests. It adds the ability to configure the link-mode which is required for the implementation of loopback tests. It adds the APIs for clock test, register test, interrupt test and memory test. Signed-off-by: Sudarsana Reddy Kalluru

[PATCH net-next 2/3] qede: add support for selftests.

This patch adds the qede ethtool support for the following tests: - interrupt test - memory test - register test - clock test Signed-off-by: Sudarsana Reddy Kalluru Signed-off-by: Yuval Mintz ---

[PATCH net-next 3/3] qede: add implementation for internal loopback test.

This patch adds the qede implementation for internal loopback test. Signed-off-by: Sudarsana Reddy Kalluru Signed-off-by: Yuval Mintz Signed-off-by: Manish Chopra --- drivers/net/ethernet/qlogic/qede/qede.h

[PATCH net-next 0/3] qed/qede: ethtool selftests support.

Hi David, This series adds the driver support for following selftests: 1. Register test 2. Memory test 3. Clock test 4. Interrupt test 5. Internal loopback test Patch (1) adds the qed driver infrastructure for selftests. Patches (2) and (3) add qede driver support for ethtool selftests. Please

Re: [PATCH v2] net: macb: do not scan PHYs manually

On Thu, Apr 28, 2016 at 11:23:15PM +0200, Andrew Lunn wrote: > On Thu, Apr 28, 2016 at 04:03:57PM -0500, Josh Cartwright wrote: > > On Thu, Apr 28, 2016 at 08:59:32PM +0200, Andrew Lunn wrote: > > > On Thu, Apr 28, 2016 at 01:55:27PM -0500, Nathan Sullivan wrote: > > > > On Thu, Apr 28, 2016 at

[PATCH net-next 1/1] tipc: set 'active' state correctly for first established link

When we are displaying statistics for the first link established between two peers, it will always be presented as STANDBY although it in reality is ACTIVE. This happens because we forget to set the 'active' flag in the link instance at the moment it is established. Although this is a bug, it

[PATCH net-next] ila: ipv6/ila: fix nlsize calculation for lwtunnel

The handler 'ila_fill_encap_info' adds two attributes: ILA_ATTR_LOCATOR and ILA_ATTR_CSUM_MODE. Also, do nla_put_u8 instead of nla_put_u64 for ILA_ATTR_CSUM_MODE. Fixes: 65d7ab8de582 ("net: Identifier Locator Addressing module") Reported-by: Nicolas Dichtel

Re: pull request [net]: batman-adv-0160426

On Thu, Apr 28, 2016 at 04:43:51PM -0400, David Miller wrote: > > Patch 2 and 3 have no "Fixes:" tag because the offending commits date > > back to when batman-adv was not yet officially in the net tree. > > This is not correct. Instead, in the future, you should provide a > Fixes: tag that

Re: [PATCH v3 net] soreuseport: Fix TCP listener hash collision

On Thu, 2016-04-28 at 19:24 -0400, Craig Gallek wrote: > From: Craig Gallek > > I forgot to include a check for listener port equality when deciding > if two sockets should belong to the same reuseport group. This was > not caught previously because it's only necessary when

Re: [PATCH net-next] ravb: Remove rx buffer ALIGN

Hi Sergei, Hi Kaneko-san, On Tue, Apr 26, 2016 at 10:14:41PM +0300, Sergei Shtylyov wrote: > Hello. > > On 04/24/2016 07:16 PM, Yoshihiro Kaneko wrote: > > >From: Kazuya Mizuguchi > > > >Aligning the reception data size is not required. > >OK, the gen 2/3

[PATCH net-next v2] of: of_mdio: Check if MDIO bus controller is available

Add a check whether the 'struct device_node' pointer passed to of_mdiobus_register() is an available (aka enabled) node in the Device Tree. Rationale for doing this are cases where an Ethernet MAC provides a MDIO bus controller and node, and an additional Ethernet MAC might be connecting its

[PATCH v3 net] soreuseport: Fix TCP listener hash collision

From: Craig Gallek I forgot to include a check for listener port equality when deciding if two sockets should belong to the same reuseport group. This was not caught previously because it's only necessary when two listening sockets for the same user happen to hash to the same

Re: [PATCH net-next] of: of_mdio: Check if MDIO bus controller is available

> Fair enough, I will submit something after re-spining this patch to use > -ENODEV, which I agree is a better return code. Did you want me to > remove that blurb from the commit message? Blurb looks good. More blurb is better than less... Andrew

Re: [PATCH] net: davinci_mdio: Set of_node in the mdio bus

> Is there another way to be able to make the of_mdio_find_bus() call be able to > find the davinci mdio bus? I missed the first post, and i cannot find it in the archive. Can you explain what your problem is please. So long as you call of_mdiobus_register() passing the correct device node, it

Re: [PATCH net] RDMA/nes: don't leak skb if carrier down

On 4/28/2016 2:20 PM, David Miller wrote: > From: Florian Westphal > Date: Sun, 24 Apr 2016 22:18:59 +0200 > >> Alternatively one could free the skb, OTOH I don't think this test is >> useful so just remove it. >> >> Cc: >> Signed-off-by: Florian

Re: [PATCH net-next] of: of_mdio: Check if MDIO bus controller is available

On 28/04/16 15:12, Andrew Lunn wrote: > On Thu, Apr 28, 2016 at 02:55:10PM -0700, Florian Fainelli wrote: >> Add a check whether the 'struct device_node' pointer passed to >> of_mdiobus_register() is an available (aka enabled) node in the Device >> Tree. >> >> Rationale for doing this are cases

[PATCH net-next 03/12] net/mlx5: Introduce modify flow rule destination

From: Maor Gottlieb This API is used for modifying the flow rule destination. This is needed for modifying the pointed flow table by the traffic type classifier rules to point on the aRFS tables. Signed-off-by: Maor Gottlieb Signed-off-by: Saeed Mahameed

[PATCH net-next 02/12] net/mlx5e: Direct TIR per RQ

From: Tariq Toukan Introduce new TIRs for direct access per RQ. Now we have 2 available kinds of TIRs: - indirect TIR per traffic type, each points to one RQT (RSS RQT) same as before. - New direct TIR per RQ, each points to RQT with a size of one

[PATCH net-next 08/12] net/mlx5e: Split the main flow steering table

From: Maor Gottlieb Currently, the main flow table is used for two purposes: One is to do mac filtering and the other is to classify the packet l3-l4 header in order to steer the packet to the right RSS TIR. This design is very complex, for each configured mac address we

[PATCH net-next 11/12] net/mlx5e: Add accelerated RFS support

From: Maor Gottlieb Implement ndo_rx_flow_steer ndo. A new flow steering rule will be composed from the skb 4-tuple and added to the hardware aRFS flow table. Each rule is stored in an internal hash table, if such skb 4-tuple rule already exists we update the corresponding

[PATCH net-next 12/12] net/mlx5e: Enabling aRFS mechanism

From: Maor Gottlieb Accelerated RFS requires that ntuple filtering is enabled via ethtool and driver supports ndo_rx_flow_steer. When the ntuple filtering is enabled, we modify the l3_l4 ttc rules to point on the aRFS flow tables and when the filtering is disabled, we modify

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

Hi Dave, This series adds accelerated RFS support for the mlx5e driver. I have added one patch non-related to aRFS that fixes the rtnl_lock warning mlx5 driver been getting since b7aade15485a ('vxlan: break dependency with netdev drivers') aRFS support in details: A direct TIR per RQ is now

[PATCH net-next 01/12] net/mlx5e: Call vxlan_get_rx_port() with rtnl lock

From: Matthew Finlay Hold the rtnl lock when calling vxlan_get_rx_port(). Fixes: b7aade15485a ("vxlan: break dependency with netdev drivers") Signed-off-by: Matthew Finlay Reported-by: Alexander Duyck Signed-off-by: Saeed

[PATCH net-next 09/12] net/mlx5: Initializing CPU reverse mapping

From: Maor Gottlieb Allocating CPU rmap and add entry for each IRQ. CPU rmap is used in aRFS to get the RX queue number of the RX completion interrupts. Signed-off-by: Maor Gottlieb Signed-off-by: Saeed Mahameed ---

[PATCH net-next 06/12] net/mlx5: Support different attributes for priorities in namespace

From: Maor Gottlieb Currently, namespace could be initialized only with priorities with the same attributes. Add support to initialize namespace with priorities with different attributes(e.g. different number of levels). Signed-off-by: Maor Gottlieb

[PATCH net-next 04/12] net/mlx5: Set number of allowed levels in priority

From: Maor Gottlieb Refactors the flow steering namespace creation, by changing the name num_fts to num_levels. When new flow table is created, the driver assign new level to this flow table therefore the meaning is equivalent. Since downstream patches will introduce the

[PATCH net-next 07/12] net/mlx5e: Refactor mlx5e flow steering structs

From: Maor Gottlieb Slightly refactor and re-order the flow steering structs, tables and data-bases for better self-containment and flexibility to add more future steering phases (tables/rules/data bases) e.g: aRFS. Changes: 1. Move the vlan DB and address DB into their

[PATCH net-next 05/12] net/mlx5: Add user chosen levels when allocating flow tables

From: Maor Gottlieb Currently, consumers of the flow steering infrastructure can't choose their own flow table levels and are limited to one flow table per level. This just waste levels. Instead, we introduce here the possibility to use multiple flow tables in a level. The

[PATCH net-next 10/12] net/mlx5e: Create aRFS flow tables

From: Maor Gottlieb Create the following four flow tables for aRFS usage: 1. IPv4 TCP - filtering 4-tuple of IPv4 TCP packets. 2. IPv6 TCP - filtering 4-tuple of IPv6 TCP packets. 3. IPv4 UDP - filtering 4-tuple of IPv4 UDP packets. 4. IPv6 UDP - filtering 4-tuple of IPv6 UDP

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

On 4/20/16, 11:06 AM, "Alexander Duyck" wrote: >On Wed, Apr 20, 2016 at 10:40 AM, Saeed Mahameed > wrote: >> On Tue, Apr 19, 2016 at 10:06 PM, Alexander Duyck >> wrote: >>> This patch assumes that the mlx5 hardware

[PATCH RFT v2 2/2] macb: kill PHY reset code

With the 'phylib' now being aware of the "reset-gpios" PHY node property, there should be no need to frob the PHY reset in this driver anymore... Signed-off-by: Sergei Shtylyov --- drivers/net/ethernet/cadence/macb.c | 17 -

[PATCH RFT 1/2] phylib: add device reset GPIO support

The PHY devices sometimes do have their reset signal (maybe even power supply?) tied to some GPIO and sometimes it also does happen that a boot loader does not leave it deasserted. So far this issue has been attacked from (as I believe) a wrong angle: by teaching the MAC driver to manipulate the

Re: [PATCH] net: davinci_mdio: Set of_node in the mdio bus

On 04/28/2016 02:44 PM, David Miller wrote: >> --- a/drivers/net/ethernet/ti/davinci_mdio.c >> +++ b/drivers/net/ethernet/ti/davinci_mdio.c >> @@ -343,6 +343,7 @@ static int davinci_mdio_probe(struct platform_device >> *pdev) >> if (davinci_mdio_probe_dt(>pdata, pdev)) >>

Re: [PATCH net-next] of: of_mdio: Check if MDIO bus controller is available

On Thu, Apr 28, 2016 at 02:55:10PM -0700, Florian Fainelli wrote: > Add a check whether the 'struct device_node' pointer passed to > of_mdiobus_register() is an available (aka enabled) node in the Device > Tree. > > Rationale for doing this are cases where an Ethernet MAC provides a MDIO > bus

[PATCH RFT v2 0/2] Teach phylib hard-resetting devices

Hello. Here's the set of 2 patches against DaveM's 'net-next.git' repo. They add to the 'phylib' support for resetting devices via GPIO and do some clean up after doing that... [1/2] phylib: add device reset GPIO support [2/2] macb: kill PHY reset code MBR, Sergei

Re: [PATCH net-next] of: of_mdio: Check if MDIO bus controller is available

On Thu, Apr 28, 2016 at 02:55:10PM -0700, Florian Fainelli wrote: > Add a check whether the 'struct device_node' pointer passed to > of_mdiobus_register() is an available (aka enabled) node in the Device > Tree. > > Rationale for doing this are cases where an Ethernet MAC provides a MDIO > bus

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

On Thu, Apr 28, 2016 at 2:43 PM, Matthew Finlay wrote: > > > > > > On 4/20/16, 11:06 AM, "Alexander Duyck" wrote: > >>On Wed, Apr 20, 2016 at 10:40 AM, Saeed Mahameed >> wrote: >>> On Tue, Apr 19, 2016 at 10:06 PM,

Re: [PATCH v2 net] soreuseport: Fix TCP listener hash collision

On Thu, Apr 28, 2016 at 5:59 PM, Eric Dumazet wrote: > On Thu, 2016-04-28 at 17:07 -0400, Craig Gallek wrote: >> From: Craig Gallek >> >> I forgot to include a check for listener port equality when deciding >> if two sockets should belong to the same

Re: [PATCH net-next] tcp: give prequeue mode some care

On Thu, 2016-04-28 at 17:15 -0400, David Miller wrote: > There was a conflict due to the stats macro renaming, but that was trivial > to resolve so I did it. > > Applied, thanks Eric. Ah great, I was preparing a V2, you were fast David. Thanks

Re: [PATCH v2 net] soreuseport: Fix TCP listener hash collision

On Thu, 2016-04-28 at 17:07 -0400, Craig Gallek wrote: > From: Craig Gallek > > I forgot to include a check for listener port equality when deciding > if two sockets should belong to the same reuseport group. This was > not caught previously because it's only necessary when

[PATCH net-next] of: of_mdio: Check if MDIO bus controller is available

Add a check whether the 'struct device_node' pointer passed to of_mdiobus_register() is an available (aka enabled) node in the Device Tree. Rationale for doing this are cases where an Ethernet MAC provides a MDIO bus controller and node, and an additional Ethernet MAC might be connecting its

Re: [PATCH] net: davinci_mdio: Set of_node in the mdio bus

From: "J.D. Schroeder" Date: Thu, 28 Apr 2016 16:39:36 -0500 > On 04/28/2016 02:44 PM, David Miller wrote: >>> --- a/drivers/net/ethernet/ti/davinci_mdio.c >>> +++ b/drivers/net/ethernet/ti/davinci_mdio.c >>> @@ -343,6 +343,7 @@ static int davinci_mdio_probe(struct

Re: [PATCH net 0/3] bpf: fix several bugs

From: Alexei Starovoitov Date: Wed, 27 Apr 2016 18:56:19 -0700 > First two patches address bugs found by Jann Horn. > Last patch is a minor samples fix spotted during the testing. Series applied and queued up for -stable, thanks.

Re: [PATCH net v3 0/5] drivers: net: cpsw: phy-handle fixes

From: "David Rivshin (Allworx)" Date: Wed, 27 Apr 2016 21:10:03 -0400 > This series fixes a number of related issues around using phy-handle > properties in cpsw emac nodes. Series applied, thanks.

Re: [PATCH next v2] ipvlan: Fix failure path in dev registration during link creation

From: Mahesh Bandewar Date: Wed, 27 Apr 2016 14:59:27 -0700 > From: Mahesh Bandewar > > When newlink creation fails at device-registration, the port->count > is decremented twice. Francesco Ruggeri (frugg...@arista.com) found > this issue in Macvlan and

Re: [PATCH v2] net: macb: do not scan PHYs manually

On Thu, Apr 28, 2016 at 04:03:57PM -0500, Josh Cartwright wrote: > On Thu, Apr 28, 2016 at 08:59:32PM +0200, Andrew Lunn wrote: > > On Thu, Apr 28, 2016 at 01:55:27PM -0500, Nathan Sullivan wrote: > > > On Thu, Apr 28, 2016 at 08:43:03PM +0200, Andrew Lunn wrote: > > > > > I agree that is a valid

Re: [PATCH net-next #2 1/1] pch_gbe: replace private tx ring lock with common netif_tx_lock

From: Francois Romieu Date: Wed, 27 Apr 2016 23:29:44 +0200 > pch_gbe_tx_ring.tx_lock is only used in the hard_xmit handler and > in the transmit completion reaper called from NAPI context. > > Compile-tested only. Potential victims Cced. > > Someone more knowledgeable

Re: [PATCH v3 2/2] net: Add Qualcomm IPC router

From: Bjorn Andersson Date: Wed, 27 Apr 2016 12:13:03 -0700 > From: Courtney Cavin > > Add an implementation of Qualcomm's IPC router protocol, used to > communicate with service providing remote processors. > > Signed-off-by:

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

On Wed, Apr 27, 2016 at 10:25:46PM -0700, Eric Dumazet wrote: > 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

Re: [PATCH net-next] tcp: give prequeue mode some care

From: Eric Dumazet Date: Wed, 27 Apr 2016 10:12:25 -0700 > From: Eric Dumazet > > TCP prequeue goal is to defer processing of incoming packets > to user space thread currently blocked in a recvmsg() system call. > > Intent is to spend less time

Re: [PATCH net-next] net: dsa: Provide CPU port statistics to master netdev

From: Florian Fainelli Date: Wed, 27 Apr 2016 11:45:14 -0700 > This patch overloads the DSA master netdev, aka CPU Ethernet MAC to also > include switch-side statistics, which is useful for debugging purposes, > when the switch is not properly connected to the Ethernet MAC

Re: [PATCH] MAINTAINERS: net: Change maintainer for GRETH 10/100/1G Ethernet MAC device driver

From: Andreas Larsson Date: Wed, 27 Apr 2016 16:46:10 +0200 > Signed-off-by: Andreas Larsson Applied.

Re: [PATCH v2 1/2] net: nps_enet: Sync access to packet sent flag

From: Elad Kanfi Date: Wed, 27 Apr 2016 16:18:29 +0300 > From: Elad Kanfi > > Below is a description of a possible problematic > sequence. CPU-A is sending a frame and CPU-B handles > the interrupt that indicates the frame was sent. CPU-B > reads an

Re: [PATCH net] gre: reject GUE and FOU in collect metadata mode

From: Jiri Benc Date: Wed, 27 Apr 2016 14:08:01 +0200 > The collect metadata mode does not support GUE nor FOU. This might be > implemented later; until then, we should reject such config. > > I think this is okay to be changed. It's unlikely anyone has such > configuration

Re: [PATCH v3 0/2] pegasus: correct buffer & packet sizes

From: Petko Manolov Date: Wed, 27 Apr 2016 14:24:48 +0300 > As noticed by Lincoln Ramsay some old (usb 1.1) Pegasus > based devices may actually return more bytes than the specified in the > datasheet > amount. That would not be a problem if the

[PATCH v2 net] soreuseport: Fix TCP listener hash collision

From: Craig Gallek I forgot to include a check for listener port equality when deciding if two sockets should belong to the same reuseport group. This was not caught previously because it's only necessary when two listening sockets for the same user happen to hash to the same

Re: [PATCH v2] net: macb: do not scan PHYs manually

On Thu, Apr 28, 2016 at 08:59:32PM +0200, Andrew Lunn wrote: > On Thu, Apr 28, 2016 at 01:55:27PM -0500, Nathan Sullivan wrote: > > On Thu, Apr 28, 2016 at 08:43:03PM +0200, Andrew Lunn wrote: > > > > I agree that is a valid fix for AT91, however it won't solve our > > > > problem, since > > > >

Re: [PATCH] fq: split out backlog update logic

From: Michal Kazior Date: Wed, 27 Apr 2016 12:59:13 +0200 > mac80211 (which will be the first user of the > fq.h) recently started to support software A-MSDU > aggregation. It glues skbuffs together into a > single one so the backlog accounting needs to be > more

Re: [PATCH net v3 0/2] gre: fix lwtunnel support

From: Jiri Benc Date: Wed, 27 Apr 2016 11:29:05 +0200 > This patchset fixes a few bugs in ipgre metadata mode implementation. > > As an example, in this setup: > > ip a a 192.168.1.1/24 dev eth0 > ip l a gre1 type gre external > ip l s gre1 up > ip a a 192.168.99.1/24 dev

Re: [PATCH v6 2/6] Documentation: Bindings: Add STM32 DWMAC glue

On Mon, Apr 25, 2016 at 01:53:58PM +0200, Alexandre TORGUE wrote: > Signed-off-by: Alexandre TORGUE Acked-by: Rob Herring

Re: [PATCHv2] netem: Segment GSO packets on enqueue.

On Thu, 2016-04-28 at 16:09 -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: > > - return NET_XMIT_SUCCESS; > +finish_segs: > +

Re: pull-request: mac80211 2016-04-27

From: Johannes Berg Date: Wed, 27 Apr 2016 10:57:26 +0200 > While writing some new code yesterday, I found and fixed a per-CPU memory > leak, this pull request has just a single patch addressing that. > > Let me know if there's any problem. Pulled, thanks a lot.

Re: [patch] tipc: remove an unnecessary NULL check

From: Dan Carpenter Date: Wed, 27 Apr 2016 11:05:28 +0300 > This is never called with a NULL "buf" and anyway, we dereference 's' on > the lines before so it would Oops before we reach the check. > > Signed-off-by: Dan Carpenter Applied to

Re: [PATCH net-next 0/5] stmmac: dwmac-socfpga refactor+cleanup

From: Joachim Eastwood Date: Tue, 26 Apr 2016 23:24:54 +0200 > Couple of heads-up here: > 1. This patch set depend on Marek's "Remove re-registration of > reset controller" patch [1] which is not in net-next yet. > Without that patch this set will not apply! > > 2.

Re: [PATCH net] soreuseport: Fix TCP listener hash collision

On Thu, 2016-04-28 at 16:11 -0400, Craig Gallek wrote: > From: Craig Gallek > > I forgot to include a check for listener port equality when deciding > if two sockets should belong to the same reuseport group. This was > not caught previously because it's only necessary when

Re: [PATCH] net: phy: at803x: only the AT8030 needs a hardware reset on link change

From: Timur Tabi Date: Tue, 26 Apr 2016 12:44:18 -0500 > Commit 13a56b44 ("at803x: Add support for hardware reset") added a > work-around for a hardware bug on the AT8030. However, the work-around > was being called for all 803x PHYs, even those that don't need it. >

Re: [PATCH v2] net/mlx5e: avoid stack overflow in mlx5e_open_channels

From: Arnd Bergmann Date: Tue, 26 Apr 2016 17:52:33 +0200 > struct mlx5e_channel_param is a large structure that is allocated > on the stack of mlx5e_open_channels, and with a recent change > it has grown beyond the warning size for the maximum stack > that a single function

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

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: Marcelo Ricardo Leitner > > > Date: Thu, 14 Apr 2016

Re: pull request [net]: batman-adv-0160426

From: Antonio Quartulli Date: Tue, 26 Apr 2016 11:27:14 +0800 > In this patchset you can find the following fixes: Pulled, even though there were some typos in the commit messages. > Patch 2 and 3 have no "Fixes:" tag because the offending commits date > back to when

Re: [PATCH net-next V2] tuntap: calculate rps hash only when needed

From: Jason Wang Date: Mon, 25 Apr 2016 23:13:42 -0400 > There's no need to calculate rps hash if it was not enabled. So this > patch export rps_needed and check it before trying to get rps > hash. Tests (using pktgen to inject packets to guest) shows this can > improve pps

Re: [PATCH] ps3_gelic: fix memcpy parameter

From: Christophe JAILLET Date: Tue, 26 Apr 2016 04:33:43 +0200 > The size allocated for target->hwinfo and the number of bytes copied in it > should be consistent. > > Signed-off-by: Christophe JAILLET Applied, thanks.

Re: [PATCH 1/2 net] lan78xx: fix statistics counter error

From: Date: Mon, 25 Apr 2016 22:22:32 + > From: Woojung Huh > > Fix rx_bytes, tx_bytes and tx_frames error in netdev.stats. > - rx_bytes counted bytes excluding size of struct ethhdr. > - tx_packets didn't count multiple packets in a

Re: [PATCH 2/2 net] lan78xx: workaround of forced 100 Full/Half duplex mode error

From: Date: Mon, 25 Apr 2016 22:22:36 + > From: Woojung Huh > > At forced 100 Full & Half duplex mode, chip may fail to set mode correctly > when cable is switched between long(~50+m) and short one. > As workaround, set to 10 before

Re: [PATCH] net: dsa: mv88e6xxx: fix uninitialized error return

From: Colin King Date: Mon, 25 Apr 2016 23:11:22 +0100 > From: Colin Ian King > > The error return err is not initialized and there is a possibility > that err is not assigned causing mv88e6xxx_port_bridge_join to > return a garbage error

Re: [PATCH v4 net-next 0/3] tcp: Make use of MSG_EOR in tcp_sendmsg

From: Martin KaFai Lau Date: Mon, 25 Apr 2016 14:44:47 -0700 ... > One potential use case is to use MSG_EOR with > SOF_TIMESTAMPING_TX_ACK to get a more accurate > TCP ack timestamping on application protocol with > multiple outgoing response messages (e.g. HTTP2). > > One of our

[PATCH net] soreuseport: Fix TCP listener hash collision

From: Craig Gallek I forgot to include a check for listener port equality when deciding if two sockets should belong to the same reuseport group. This was not caught previously because it's only necessary when two listening sockets for the same user happen to hash to the same

Re: [PATCH v2] net: macb: do not scan PHYs manually

On Thu, Apr 28, 2016 at 01:03:15PM -0700, Florian Fainelli wrote: > On 28/04/16 11:59, Andrew Lunn wrote: > > On Thu, Apr 28, 2016 at 01:55:27PM -0500, Nathan Sullivan wrote: > >> On Thu, Apr 28, 2016 at 08:43:03PM +0200, Andrew Lunn wrote: > I agree that is a valid fix for AT91, however it

[PATCHv2] 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

  1   2   3   >