Re: [PATCH] RDS: sync congestion map updating

On 4/1/16 6:14 PM, Leon Romanovsky wrote: On Fri, Apr 01, 2016 at 12:47:24PM -0700, santosh shilimkar wrote: (cc-ing netdev) On 3/30/2016 7:59 PM, Wengang Wang wrote: 在 2016年03月31日 09:51, Wengang Wang 写道: 在 2016年03月31日 01:16, santosh shilimkar 写道: Hi Wengang, On 3/30/2016 9:19 AM,

Re: [RFC PATCH 4/5] mlx4: add support for fast rx drop bpf program

On Fri, Apr 01, 2016 at 07:08:31PM -0700, Eric Dumazet wrote: > On Fri, 2016-04-01 at 18:21 -0700, Brenden Blanco wrote: > > Add support for the BPF_PROG_TYPE_PHYS_DEV hook in mlx4 driver. Since > > bpf programs require a skb context to navigate the packet, build a > > percpu fake skb with the

Re: [net PATCH 2/2] ipv4/GRO: Make GRO conform to RFC 6864

On Sat, 2016-04-02 at 10:19 +0800, Herbert Xu wrote: > On Fri, Apr 01, 2016 at 07:15:33PM -0700, Eric Dumazet wrote: > > On Sat, 2016-04-02 at 09:57 +0800, Herbert Xu wrote: > > > > > > We could easily fix that by adding a feature bit to control this, > > > something like SKB_GSO_TCP_FIXEDID. > >

Re: [PATCH v2 net-next] net/core: generic support for disabling netdev features down stack

Hi, Sorry for digging up an old patch, but... ;-) dev_disable_lro() is a leftover from ancient times. If you read commit 27660515a, there is a hint where it should go. Please, read on if you'd like to fix this properly. 2015-11-03 3:55 GMT+01:00 Jarod Wilson : > There are some

Re: [net PATCH 2/2] ipv4/GRO: Make GRO conform to RFC 6864

On Fri, 2016-04-01 at 22:16 -0400, David Miller wrote: > From: Alexander Duyck > Date: Fri, 1 Apr 2016 12:58:41 -0700 > > > RFC 6864 is pretty explicit about this, IPv4 ID used only for > > fragmentation. https://tools.ietf.org/html/rfc6864#section-4.1 > > > > The

Re: [net PATCH 2/2] ipv4/GRO: Make GRO conform to RFC 6864

On Fri, Apr 01, 2016 at 07:15:33PM -0700, Eric Dumazet wrote: > On Sat, 2016-04-02 at 09:57 +0800, Herbert Xu wrote: > > > > We could easily fix that by adding a feature bit to control this, > > something like SKB_GSO_TCP_FIXEDID. > > I understood the patch allowed to aggregate 4 segments having

Re: [net PATCH 2/2] ipv4/GRO: Make GRO conform to RFC 6864

From: Alexander Duyck Date: Fri, 1 Apr 2016 12:58:41 -0700 > RFC 6864 is pretty explicit about this, IPv4 ID used only for > fragmentation. https://tools.ietf.org/html/rfc6864#section-4.1 > > The goal with this change is to try and keep most of the existing >

Re: [net PATCH 2/2] ipv4/GRO: Make GRO conform to RFC 6864

On Sat, 2016-04-02 at 09:57 +0800, Herbert Xu wrote: > Eric Dumazet wrote: > > > > I do not particularly care, but it is worth mentioning that GRO+TSO > > would not be idempotent anymore. > > We could easily fix that by adding a feature bit to control this, > something

Re: [RFC PATCH 4/5] mlx4: add support for fast rx drop bpf program

On Fri, 2016-04-01 at 18:21 -0700, Brenden Blanco wrote: > Add support for the BPF_PROG_TYPE_PHYS_DEV hook in mlx4 driver. Since > bpf programs require a skb context to navigate the packet, build a > percpu fake skb with the minimal fields. This avoids the costly > allocation for packets that end

Re: [RESEND PATCH V4 2/3] IB/hns: Add HiSilicon RoCE driver support

On Fri, Apr 01, 2016 at 05:21:31PM +0800, Lijun Ou wrote: > The driver for HiSilicon RoCE is a platform driver. > The driver will support multiple versions of hardware. Currently only "v1" > for hip06 SoC is supported. > The driver includes two parts: common driver and hardware-specific >

Re: [net PATCH 2/2] ipv4/GRO: Make GRO conform to RFC 6864

Eric Dumazet wrote: > > I do not particularly care, but it is worth mentioning that GRO+TSO > would not be idempotent anymore. We could easily fix that by adding a feature bit to control this, something like SKB_GSO_TCP_FIXEDID. Cheers, -- Email: Herbert Xu

Re: Question on rhashtable in worst-case scenario.

On Fri, Apr 01, 2016 at 11:34:10PM +0200, Johannes Berg wrote: > > I was thinking about that one - it's not obvious to me from the code > how this "explicitly checking for dups" would be done or let's say how > rhashtable differentiates. But since it seems to work for Ben until > hitting a certain

[RFC PATCH 2/5] net: add ndo to set bpf prog in adapter rx

Add a new netdev op for drivers implementing the BPF_PROG_TYPE_PHYS_DEV filter to get configuration. Since the fd is only used by the driver to fetch the prog, the netdev should just keep a bit to indicate the program is valid. Signed-off-by: Brenden Blanco ---

[RFC PATCH 3/5] rtnl: add option for setting link bpf prog

Sets the bpf program represented by fd as an early filter in the rx path of the netdev. The fd must have been created as BPF_PROG_TYPE_PHYS_DEV. Providing a negative value as fd clears the program. Getting the fd back via rtnl is not possible, therefore reading of this value merely provides a bool

[RFC PATCH 4/5] mlx4: add support for fast rx drop bpf program

Add support for the BPF_PROG_TYPE_PHYS_DEV hook in mlx4 driver. Since bpf programs require a skb context to navigate the packet, build a percpu fake skb with the minimal fields. This avoids the costly allocation for packets that end up being dropped. Since mlx4 is so far the only user of this

[RFC PATCH 0/5] Add driver bpf hook for early packet drop

This patch set introduces new infrastructure for programmatically processing packets in the earliest stages of rx, as part of an effort others are calling Express Data Path (XDP) [1]. Start this effort by introducing a new bpf program type for early packet filtering, before even an skb has been

[RFC PATCH 5/5] Add sample for adding simple drop program to link

Add a sample program that only drops packets at the BPF_PROG_TYPE_PHYS_DEV hook of a link. With the drop-only program, observed single core rate is ~14.6Mpps. Other tests were run, for instance without the dropcnt increment or without reading from the packet header, the packet rate was mostly

[RFC PATCH 1/5] bpf: add PHYS_DEV prog type for early driver filter

Add a new bpf prog type that is intended to run in early stages of the packet rx path. Only minimal packet metadata will be available, hence a new context type, struct xdp_metadata, is exposed to userspace. So far only expose the readable packet length, and only in read mode. The PHYS_DEV name is

Re: [PATCH] RDS: sync congestion map updating

On Fri, Apr 01, 2016 at 12:47:24PM -0700, santosh shilimkar wrote: > (cc-ing netdev) > On 3/30/2016 7:59 PM, Wengang Wang wrote: > > > > > >在 2016年03月31日 09:51, Wengang Wang 写道: > >> > >> > >>在 2016年03月31日 01:16, santosh shilimkar 写道: > >>>Hi Wengang, > >>> > >>>On 3/30/2016 9:19 AM, Leon

[GIT] Networking

1) Missing device reference in IPSEC input path results in crashes during device unregistration. From Subash Abhinov Kasiviswanathan. 2) Per-queue ISR register writes not being done properly in macb driver, from Cyrille Pitchen. 3) Stats accounting bugs in bcmgenet, from Patri Gynther.

Re: [PATCH net] vlan: pull on __vlan_insert_tag error path and fix csum correction

On 04/01/2016 11:28 PM, Daniel Borkmann wrote: On 04/01/2016 09:00 PM, David Miller wrote: From: Daniel Borkmann Date: Fri, 1 Apr 2016 11:41:03 +0200 Moreover, I noticed that when in the non-error path the __skb_pull() is done and the original offset to mac header was

Re: [RFC PATCH net 3/4] ipv6: datagram: Update dst cache of a connected datagram sk during pmtu update

On Fri, Apr 1, 2016 at 4:13 PM, Cong Wang wrote: > On Fri, Apr 1, 2016 at 3:56 PM, Martin KaFai Lau wrote: >> + bh_lock_sock(sk); >> + if (!sock_owned_by_user(sk)) >> + ip6_datagram_dst_update(sk, false); >> +

Re: [RFC PATCH net 3/4] ipv6: datagram: Update dst cache of a connected datagram sk during pmtu update

On Fri, Apr 1, 2016 at 3:56 PM, Martin KaFai Lau wrote: > + bh_lock_sock(sk); > + if (!sock_owned_by_user(sk)) > + ip6_datagram_dst_update(sk, false); > + bh_unlock_sock(sk); My discussion with Eric shows that we probably don't need to hold this

[RFC PATCH net 2/4] ipv6: datagram: Refactor dst lookup and update codes to a new function

This patch moves the route lookup and update codes for connected datagram sk to a newly created function ip6_datagram_dst_update() It will be reused during the pmtu update in the later patch. Signed-off-by: Martin KaFai Lau Cc: Cong Wang Cc: Eric Dumazet

[RFC PATCH net 4/4] ipv6: udp: Do a route lookup and update during release_cb

This patch adds a release_cb for UDPv6. It does a route lookup and updates sk->sk_dst_cache if it is needed. It picks up the left-over job from ip6_sk_update_pmtu() if the sk is owned by user during the pmtu update. Signed-off-by: Martin KaFai Lau Reported-by: Wei Wang

[RFC PATCH net 1/4] ipv6: datagram: Refactor flowi6 init codes to a new function

Move flowi6 init codes for connected datagram sk to a newly created function ip6_datagram_flow_key_init(). It will be reused during pmtu update in the later patch. Signed-off-by: Martin KaFai Lau Cc: Cong Wang Cc: Eric Dumazet Cc:

[RFC PATCH net 3/4] ipv6: datagram: Update dst cache of a connected datagram sk during pmtu update

There is a case in connected UDP socket such that getsockopt(IPV6_MTU) will return a stale MTU value. The reproducible sequence could be the following: 1. Create a connected UDP socket 2. Send some datagrams out 3. Receive a ICMPV6_PKT_TOOBIG 4. No new outgoing datagrams to trigger the

[RFC PATCH net 0/4] ip6: datagram: Update dst cache of a connected datagram sk during pmtu update

There is a case in connected UDP socket such that getsockopt(IPV6_MTU) will return a stale MTU value. The reproducible sequence could be the following: 1. Create a connected UDP socket 2. Send some datagrams out 3. Receive a ICMPV6_PKT_TOOBIG 4. No new outgoing datagrams to trigger the

Re: [v7, 0/5] Fix eSDHC host version register bug

On Fri, 2016-04-01 at 11:07 +0800, Yangbo Lu wrote: > This patchset is used to fix a host version register bug in the T4240-R1.0 > -R2.0 > eSDHC controller. To get the SoC version and revision, it's needed to add > the > GUTS driver to access the global utilities registers. > > So, the first

[net-next PATCH 2/2 v4] ibmvnic: enable RX checksum offload

Enable RX Checksum offload feature in the ibmvnic driver. Signed-off-by: Thomas Falcon Cc: John Allen --- v4: this patch included since it is enabled by the previous patch --- drivers/net/ethernet/ibm/ibmvnic.c | 4 1 file changed, 4

[net-next PATCH 1/2 v4] ibmvnic: map L2/L3/L4 header descriptors to firmware

Allow the VNIC driver to provide descriptors containing L2/L3/L4 headers to firmware. This feature is needed for greater hardware compatibility and enablement of checksum and TCP offloading features. A new function is included for the hypervisor call, H_SEND_SUBCRQ_INDIRECT, allowing a

Re: [Odd commit author id merge via netdev]

On 4/1/2016 1:01 PM, Johannes Berg wrote: On Fri, 2016-04-01 at 10:51 -0700, santosh shilimkar wrote: Hi Dave, I noticed something odd while checking the recent commits of mine in kernel.org tree made it via netdev. Don't know if its patchwork tool doing this. Usual author line in my git

Re: Question on rhashtable in worst-case scenario.

On Fri, 2016-04-01 at 08:46 +0800, Herbert Xu wrote: > On Thu, Mar 31, 2016 at 05:29:59PM +0200, Johannes Berg wrote: > > > > > > Does removing this completely disable the "-EEXIST" error? I can't > > say > > I fully understand the elasticity stuff in > > __rhashtable_insert_fast(). > What

Re: [PATCH net] vlan: pull on __vlan_insert_tag error path and fix csum correction

On 04/01/2016 09:00 PM, David Miller wrote: From: Daniel Borkmann Date: Fri, 1 Apr 2016 11:41:03 +0200 Moreover, I noticed that when in the non-error path the __skb_pull() is done and the original offset to mac header was non-zero, we fixup from a wrong skb->data offset

[PATCH v4 net-next 11/15] nfp: sync ring state during FW reconfiguration

FW reconfiguration in .ndo_open()/.ndo_stop() should reset/ restore queue state. Since we need IRQs to be disabled when filling rings on RX path we have to move disable_irq() from .ndo_open() all the way up to IRQ allocation. nfp_net_start_vec() becomes trivial now so it's inlined.

[PATCH v4 net-next 08/15] nfp: preallocate RX buffers early in .ndo_open

We want the .ndo_open() to have following structure: - allocate resources; - configure HW/FW; - enable the device from stack perspective. Therefore filling RX rings needs to be moved to the beginning of .ndo_open(). Signed-off-by: Jakub Kicinski ---

RE: [net PATCH 2/2] ipv4/GRO: Make GRO conform to RFC 6864

| For transmit we can leave the IP ID code as is. For receive we should not be | snooping into the IP ID for any frames that have the DF bit set as devices | that have adopted RFC 6864 on their transmit path will end up causing issues. Currently, GRO does not coalesce TCP packets originating

[PATCH v4 net-next 05/15] nfp: allocate ring SW structs dynamically

To be able to switch rings more easly on config changes allocate them dynamically, separately from nfp_net structure. Signed-off-by: Jakub Kicinski --- drivers/net/ethernet/netronome/nfp/nfp_net.h | 6 ++--- .../net/ethernet/netronome/nfp/nfp_net_common.c

[PATCH v4 net-next 12/15] nfp: propagate list buffer size in struct rx_ring

Free list buffer size needs to be propagated to few functions as a parameter and added to struct nfp_net_rx_ring since soon some of the functions will be reused to manage rings with buffers of size different than nn->fl_bufsz. Signed-off-by: Jakub Kicinski ---

[PATCH v4 net-next 13/15] nfp: convert .ndo_change_mtu() to prepare/commit paradigm

When changing MTU on running device first allocate new rings and buffers and once it succeeds proceed with changing MTU. Allocation of new rings is not really necessary for this operation - it's done to keep the code simple and because size of the extra ring memory is quite small compared to the

[PATCH v4 net-next 02/15] nfp: move link state interrupt request/free calls

We need to be able to disable the link state interrupt when the device is brought down. We used to just free the IRQ at the beginning of .ndo_stop(). As we now move towards more ordered .ndo_open()/.ndo_stop() paths LSC allocation should be placed in the "allocate resource" section. Since the

[PATCH v4 net-next 03/15] nfp: break up nfp_net_{alloc|free}_rings

nfp_net_{alloc|free}_rings contained strange mix of allocations and vector initialization. Remove it, declare vector init as a separate function and handle allocations explicitly. Signed-off-by: Jakub Kicinski --- .../net/ethernet/netronome/nfp/nfp_net_common.c

[PATCH v4 net-next 09/15] nfp: move filling ring information to FW config

nfp_net_[rt]x_ring_{alloc,free} should only allocate or free ring resources without touching the device. Move setting parameters in the BAR to separate functions. This will make it possible to reuse alloc/free functions to allocate new rings while the device is running. Signed-off-by: Jakub

[PATCH v4 net-next 15/15] nfp: allow ring size reconfiguration at runtime

Since much of the required changes have already been made for changing MTU at runtime let's use it for ring size changes as well. Signed-off-by: Jakub Kicinski --- drivers/net/ethernet/netronome/nfp/nfp_net.h | 1 +

[PATCH v4 net-next 07/15] nfp: reorganize initial filling of RX rings

Separate allocation of buffers from giving them to FW, thanks to this it will be possible to move allocation earlier on .ndo_open() path and reuse buffers during runtime reconfiguration. Similar to TX side clean up the spill of functionality from flush to freeing the ring. Unlike on TX side, RX

[PATCH v4 net-next 00/15] MTU/buffer reconfig changes

Hi! Sorry it takes me so long to iterate this. Previous series included some not entirely related patches, this one is cut down. Main issue I'm trying to solve here is that .ndo_change_mtu() in nfpvf driver is doing full close/open to reallocate buffers - which if open fails can result in

[PATCH v4 net-next 04/15] nfp: make *x_ring_init do all the init

nfp_net_[rt]x_ring_init functions used to be called from probe path only and some of their functionality was spilled to the call site. In order to reuse them for ring reconfiguration we need them to do all the init. Signed-off-by: Jakub Kicinski ---

[PATCH v4 net-next 10/15] nfp: slice .ndo_open() and .ndo_stop() up

Divide .ndo_open() and .ndo_stop() into logical, callable chunks. No functional changes. Signed-off-by: Jakub Kicinski --- .../net/ethernet/netronome/nfp/nfp_net_common.c| 218 + 1 file changed, 136 insertions(+), 82 deletions(-) diff

[PATCH v4 net-next 06/15] nfp: cleanup tx ring flush and rename to reset

Since we never used flush without freeing the ring later the functionality of the two operations is mixed. Rename flush to ring reset and move there all the things which have to be done after FW ring state is cleared. While at it do some clean-ups. Signed-off-by: Jakub Kicinski

[PATCH v4 net-next 14/15] nfp: pass ring count as function parameter

Soon ring resize will call this functions with values different than the current configuration we need to explicitly pass the ring count as parameter. Signed-off-by: Jakub Kicinski --- .../net/ethernet/netronome/nfp/nfp_net_common.c| 23 +-

[PATCH v4 net-next 01/15] nfp: correct RX buffer length calculation

When calculating the RX buffer length we need to account for up to 2 VLAN tags and up to 8 MPLS labels. Rounding up to 1k is an relic of a distant past and can be removed. While at it also remove trivial print statement. Signed-off-by: Jakub Kicinski ---

Re: [PATCH v2 -next] net/core/dev: Warn on a too-short GRO frame

On Fri, 2016-04-01 at 15:58 -0400, Aaron Conole wrote: > From: Aaron Conole > > When signaling that a GRO frame is ready to be processed, the network stack > correctly checks length and aborts processing when a frame is less than 14 > bytes. However, such a condition is

[PATCH] ip6_tunnel: set rtnl_link_ops before calling register_netdevice

When creating an ip6tnl tunnel with ip tunnel, rtnl_link_ops is not set before ip6_tnl_create2 is called. When register_netdevice is called, there is no linkinfo attribute in the NEWLINK message because of that. Setting rtnl_link_ops before calling register_netdevice fixes that. Signed-off-by:

Re: [Odd commit author id merge via netdev]

On Fri, 2016-04-01 at 10:51 -0700, santosh shilimkar wrote: > Hi Dave, > > I noticed something odd while checking the recent > commits of mine in kernel.org tree made it via netdev. > > Don't know if its patchwork tool doing this. > Usual author line in my git objects : > Author: Santosh

[PATCH v2 -next] net/core/dev: Warn on a too-short GRO frame

From: Aaron Conole When signaling that a GRO frame is ready to be processed, the network stack correctly checks length and aborts processing when a frame is less than 14 bytes. However, such a condition is really indicative of a broken driver, and should be loudly signaled,

Re: [net PATCH 2/2] ipv4/GRO: Make GRO conform to RFC 6864

On Fri, Apr 1, 2016 at 12:24 PM, David Miller wrote: > From: Eric Dumazet > Date: Fri, 01 Apr 2016 11:49:03 -0700 > >> For example, TCP stack tracks per socket ID generation, even if it >> sends DF=1 frames. Damn useful for tcpdump analysis and drop

Re: [PATCH v3 net-next] net: ipv4: Consider failed nexthops in multipath routes

Hello, On Fri, 1 Apr 2016, David Ahern wrote: > v3 > - Julian comments: changed use of dead in documentation to failed, > init state to NUD_REACHABLE which simplifies fib_good_nh, use of > nh_dev for neighbor lookup, fallback to first entry which is what > current logic does > >

Re: [PATCH] RDS: sync congestion map updating

(cc-ing netdev) On 3/30/2016 7:59 PM, Wengang Wang wrote: 在 2016年03月31日 09:51, Wengang Wang 写道: 在 2016年03月31日 01:16, santosh shilimkar 写道: Hi Wengang, On 3/30/2016 9:19 AM, Leon Romanovsky wrote: On Wed, Mar 30, 2016 at 05:08:22PM +0800, Wengang Wang wrote: Problem is found that some

[RFC v3 -next 0/2] virtio-net: Advised MTU feature

The following series adds the ability for a hypervisor to set an MTU on the guest during feature negotiation phase. This is useful for VM orchestration when, for instance, tunneling is involved and the MTU of the various systems should be homogenous. The first patch adds the feature bit as

[RFC v3 -next 2/2] virtio_net: Read the advised MTU

This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it exists, read the advised MTU and use it. No proper error handling is provided for the case where a user changes the negotiated MTU. A future commit will add proper error handling. Instead, a warning is emitted if the guest

[RFC v3 -net 1/2] virtio: Start feature MTU support

This commit adds the feature bit and associated mtu device entry for the virtio network device. Future commits will make use of these bits to support negotiated MTU. Signed-off-by: Aaron Conole --- v2,v3: * No change include/uapi/linux/virtio_net.h | 3 +++ 1 file changed,

Re: [net PATCH 2/2] ipv4/GRO: Make GRO conform to RFC 6864

From: Eric Dumazet Date: Fri, 01 Apr 2016 11:49:03 -0700 > For example, TCP stack tracks per socket ID generation, even if it > sends DF=1 frames. Damn useful for tcpdump analysis and drop > inference. Thanks for mentioning this, I never considered this use case. > With

Re: [PATCH] net: mvneta: fix changing MTU when using per-cpu processing

From: Marcin Wojtas Date: Fri, 1 Apr 2016 15:21:18 +0200 > After enabling per-cpu processing it appeared that under heavy load > changing MTU can result in blocking all port's interrupts and transmitting > data is not possible after the change. > > This commit fixes above

Re: [v7, 4/5] powerpc/fsl: move mpc85xx.h to include/linux/fsl

On 03/31/2016 08:07 PM, Yangbo Lu wrote: > drivers/clk/clk-qoriq.c | 3 +-- > For clk part: Acked-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

Re: [PATCH net] vlan: pull on __vlan_insert_tag error path and fix csum correction

From: Daniel Borkmann Date: Fri, 1 Apr 2016 11:41:03 +0200 > Moreover, I noticed that when in the non-error path the __skb_pull() > is done and the original offset to mac header was non-zero, we fixup > from a wrong skb->data offset in the checksum complete processing. >

Re: [net PATCH 2/2] ipv4/GRO: Make GRO conform to RFC 6864

On Fri, 2016-04-01 at 11:05 -0700, Alexander Duyck wrote: > RFC 6864 states that the IPv4 ID field MUST NOT be used for purposes other > than fragmentation and reassembly. Currently we are looking at this field > as a way of identifying what frames can be aggregated and which cannot for > GRO.

Re: [PATCH] net: mvpp2: use cache_line_size() to get cacheline size

From: Jisheng Zhang Date: Fri, 1 Apr 2016 17:11:05 +0800 > L1_CACHE_BYTES may not be the real cacheline size, use cache_line_size > to determine the cacheline size in runtime. > > Signed-off-by: Jisheng Zhang > Suggested-by: Marcin Wojtas

Re: [PATCH 1/2] ipv6: rework the lock in addrconf_permanent_addr

From: roy.qing...@gmail.com Date: Fri, 1 Apr 2016 17:26:58 +0800 > From: Li RongQing > > 1. nothing of idev is changed, so read lock is enough > 2. ifp is changed, so used ifp->lock or cmpxchg to protect it > > Signed-off-by: Li RongQing You

Re: [PATCH] net: mvneta: use cache_line_size() to get cacheline size

From: Jisheng Zhang Date: Fri, 1 Apr 2016 17:12:49 +0800 > L1_CACHE_BYTES may not be the real cacheline size, use cache_line_size > to determine the cacheline size in runtime. > > Signed-off-by: Jisheng Zhang > Suggested-by: Marcin Wojtas

Re: [PATCH] bridge: remove br_dev_set_multicast_list

From: roy.qing...@gmail.com Date: Fri, 1 Apr 2016 16:16:10 +0800 > From: Li RongQing > > remove br_dev_set_multicast_list which does nothing > > Signed-off-by: Li RongQing This will break SIOCADDMULTI et al. on the bridge, see net/core/dev.c

Re: [PATCH (net.git) 0/3] stmmac MDIO and normal descr fixes

From: Giuseppe Cavallaro Date: Fri, 1 Apr 2016 09:07:13 +0200 > This patch series is to fix the problems below and recently debugged > in this mailing list: > > o to fix a problem for the HW where the normal descriptor > o to fix the mdio registration according to the

Re: [PATCH] net: mvpp2: fix maybe-uninitialized warning

From: Jisheng Zhang Date: Thu, 31 Mar 2016 17:01:23 +0800 > This is to fix the following maybe-uninitialized warning: > > drivers/net/ethernet/marvell/mvpp2.c:6007:18: warning: 'err' may be > used uninitialized in this function [-Wmaybe-uninitialized] > > Signed-off-by:

Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get

On 04/01/2016 08:33 PM, David Miller wrote: From: Daniel Borkmann Date: Fri, 01 Apr 2016 10:10:11 +0200 Dave, do you need me to resubmit this one w/o changes: http://patchwork.ozlabs.org/patch/603903/ ? I'll apply this and queue it up for -stable, thanks. Ok, thanks!

Re: [RFC PATCH 6/6] ppc: ebpf/jit: Implement JIT compiler for extended BPF

On 04/01/2016 08:10 PM, Alexei Starovoitov wrote: On 4/1/16 2:58 AM, Naveen N. Rao wrote: PPC64 eBPF JIT compiler. Works for both ABIv1 and ABIv2. Enable with: echo 1 > /proc/sys/net/core/bpf_jit_enable or echo 2 > /proc/sys/net/core/bpf_jit_enable ... to see the generated JIT code. This can

Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get

From: Daniel Borkmann Date: Fri, 01 Apr 2016 10:10:11 +0200 > Dave, do you need me to resubmit this one w/o changes: > http://patchwork.ozlabs.org/patch/603903/ ? I'll apply this and queue it up for -stable, thanks.

[PATCH] Marvell phy: add fiber status check for some components

>From a5a7a9828511ff6a522cf742109768207ff89929 Mon Sep 17 00:00:00 2001 From: Charles-Antoine Couret Date: Fri, 1 Apr 2016 16:16:35 +0200 Subject: [PATCH] Marvell phy: add fiber status check for some components This patch is not tested with all Marvell's phy.

Re: Question on rhashtable in worst-case scenario.

On 03/31/2016 05:46 PM, Herbert Xu wrote: On Thu, Mar 31, 2016 at 05:29:59PM +0200, Johannes Berg wrote: Does removing this completely disable the "-EEXIST" error? I can't say I fully understand the elasticity stuff in __rhashtable_insert_fast(). What EEXIST error are you talking about? The

Re: [RFC PATCH 6/6] ppc: ebpf/jit: Implement JIT compiler for extended BPF

On 4/1/16 2:58 AM, Naveen N. Rao wrote: PPC64 eBPF JIT compiler. Works for both ABIv1 and ABIv2. Enable with: echo 1 > /proc/sys/net/core/bpf_jit_enable or echo 2 > /proc/sys/net/core/bpf_jit_enable ... to see the generated JIT code. This can further be processed with tools/net/bpf_jit_disasm.

[net PATCH 2/2] ipv4/GRO: Make GRO conform to RFC 6864

RFC 6864 states that the IPv4 ID field MUST NOT be used for purposes other than fragmentation and reassembly. Currently we are looking at this field as a way of identifying what frames can be aggregated and which cannot for GRO. While this is valid for frames that do not have DF set, it is

[net PATCH 1/2] GRE: Disable segmentation offloads w/ CSUM and we are encapsulated via FOU

This patch fixes an issue I found in which we were dropping frames if we had enabled checksums on GRE headers that were encapsulated by either FOU or GUE. Without this patch I was barely able to get 1 Gb/s of throughput. With this patch applied I am now at least getting around 6 Gb/s. The issue

[net PATCH 0/2] Fixes for GRO and GRE tunnels

This pair of patches addresses a few issues I have discovered over the last week or so concerning GRO and GRE tunnels. The first patch addresses an item I called out as an issue with FOU/GUE encapsulating GRE, and I finally had a chance to test it and verify that the code concerning it was broken

Re: [PATCH 4/4] samples/bpf: Enable powerpc support

On 4/1/16 7:41 AM, Naveen N. Rao wrote: On 2016/03/31 10:52AM, Alexei Starovoitov wrote: On 3/31/16 4:25 AM, Naveen N. Rao wrote: ... + +#ifdef __powerpc__ +#define BPF_KPROBE_READ_RET_IP(ip, ctx){ (ip) = (ctx)->link; } +#define BPF_KRETPROBE_READ_RET_IP(ip, ctx)

Re: [PATCH 2/4] samples/bpf: Use llc in PATH, rather than a hardcoded value

On 4/1/16 7:37 AM, Naveen N. Rao wrote: On 2016/03/31 08:19PM, Daniel Borkmann wrote: On 03/31/2016 07:46 PM, Alexei Starovoitov wrote: On 3/31/16 4:25 AM, Naveen N. Rao wrote: clang $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS) \ -D__KERNEL__ -D__ASM_SYSREG_H

[Odd commit author id merge via netdev]

Hi Dave, I noticed something odd while checking the recent commits of mine in kernel.org tree made it via netdev. Don't know if its patchwork tool doing this. Usual author line in my git objects : Author: Santosh Shilimkar But the commits going via your tree seems to be like

[PATCH v2] sctp: use list_* in sctp_list_dequeue

Use list_* helpers in sctp_list_dequeue, more readable. Signed-off-by: Marcelo Ricardo Leitner --- v2: patch rechecked include/net/sctp/sctp.h | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h

Re: qdisc spin lock

2016-03-31 19:19 GMT-07:00 David Miller : > From: Michael Ma > Date: Thu, 31 Mar 2016 16:48:43 -0700 > >> I didn't really know that multiple qdiscs can be isolated using MQ so > ... > > Please stop top-posting. Sorry that I wasn't aware of this...

Re: [PATCH] Marvell phy: add fiber status check for some components

On Fri, Apr 01, 2016 at 06:33:48PM +0200, Charles-Antoine Couret wrote: > >From a5a7a9828511ff6a522cf742109768207ff89929 Mon Sep 17 00:00:00 2001 > From: Charles-Antoine Couret > Date: Fri, 1 Apr 2016 16:16:35 +0200 > Subject: [PATCH] Marvell phy: add fiber

[PATCH v2] sctp: flush if we can't fit another DATA chunk

There is no point on delaying the packet if we can't fit a single byte of data on it anymore. So lets just reduce the threshold by the amount that a data chunk with 4 bytes (rounding) would use. v2: based on the right tree Signed-off-by: Marcelo Ricardo Leitner ---

Re: [PATCH 3/4] net: w5100: enable to support sleepable register access interface

2016-04-01 4:30 GMT+09:00 David Miller : > From: Akinobu Mita > Date: Thu, 31 Mar 2016 01:38:39 +0900 > >> + struct sk_buff_head tx_queue; > > The way the queueing works in this driver is that it is only possible > to have one SKB being transmitted

[PATCH] Marvell phy: add fiber status check for some components

>From a5a7a9828511ff6a522cf742109768207ff89929 Mon Sep 17 00:00:00 2001 From: Charles-Antoine Couret Date: Fri, 1 Apr 2016 16:16:35 +0200 Subject: [PATCH] Marvell phy: add fiber status check for some components This patch is not tested with all Marvell's phy.

Re: [PATCH v2 net-next 11/11] tcp: rate limit ACK sent by SYN_RECV request sockets

On Fri, Apr 1, 2016 at 11:52 AM, Eric Dumazet wrote: > Attackers like to use SYNFLOOD targeting one 5-tuple, as they > hit a single RX queue (and cpu) on the victim. > > If they use random sequence numbers in their SYN, we detect > they do not match the expected window and

[PATCH v2 net-next 03/11] tcp/dccp: remove BH disable/enable in lookup

Since linux 2.6.29, lookups only use rcu locking. Signed-off-by: Eric Dumazet --- include/net/inet_hashtables.h | 7 +-- net/ipv6/inet6_hashtables.c | 2 -- 2 files changed, 1 insertion(+), 8 deletions(-) diff --git a/include/net/inet_hashtables.h

[PATCH v2 net-next 01/11] net: add SOCK_RCU_FREE socket flag

We want a generic way to insert an RCU grace period before socket freeing for cases where RCU_SLAB_DESTROY_BY_RCU is adding too much overhead. SLAB_DESTROY_BY_RCU strict rules force us to take a reference on the socket sk_refcnt, and it is a performance problem for UDP encapsulation, or TCP

[PATCH v2 net-next 10/11] ipv4: tcp: set SOCK_USE_WRITE_QUEUE for ip_send_unicast_reply()

TCP uses per cpu 'sockets' to send some packets : - RST packets ( tcp_v4_send_reset()) ) - ACK packets for SYN_RECV and TIMEWAIT sockets By setting SOCK_USE_WRITE_QUEUE flag, we tell sock_wfree() to not call sk_write_space() since these internal sockets do not care. This gives a small

[PATCH v2 net-next 00/11] net: various udp/tcp changes

First round of patches for linux-4.7 Add a generic facility for sockets to be freed after an RCU grace period, if they need to. Then UDP stack is changed to no longer use SLAB_DESTROY_BY_RCU, in order to speedup rx processing for traffic encapsulated in UDP. It gives a 17 % speedup for normal

[PATCH v2 net-next 05/11] inet: reqsk_alloc() needs to take care of dead listeners

We'll soon no longer take a refcount on listeners, so reqsk_alloc() can not assume a listener refcount is not zero. We need to use atomic_inc_not_zero() Signed-off-by: Eric Dumazet --- include/net/request_sock.h | 31 +++ 1 file changed, 15

[PATCH v2 net-next 06/11] tcp/dccp: do not touch listener sk_refcnt under synflood

When a SYNFLOOD targets a non SO_REUSEPORT listener, multiple cpus contend on sk->sk_refcnt and sk->sk_wmem_alloc changes. By letting listeners use SOCK_RCU_FREE infrastructure, we can relax TCP_LISTEN lookup rules and avoid touching sk_refcnt Note that we still use SLAB_DESTROY_BY_RCU rules for

[PATCH v2 net-next 02/11] udp: no longer use SLAB_DESTROY_BY_RCU

Tom Herbert would like not touching UDP socket refcnt for encapsulated traffic. For this to happen, we need to use normal RCU rules, with a grace period before freeing a socket. UDP sockets are not short lived in the high usage case, so the added cost of call_rcu() should not be a concern. This

[PATCH v2 net-next 09/11] tcp: increment sk_drops for listeners

Goal: packets dropped by a listener are accounted for. This adds tcp_listendrop() helper, and clears sk_drops in sk_clone_lock() so that children do not inherit their parent drop count. Note that we no longer increment LINUX_MIB_LISTENDROPS counter when sending a SYNCOOKIE, since the SYN packet

[PATCH v2 net-next 08/11] tcp: increment sk_drops for dropped rx packets

Now ss can report sk_drops, we can instruct TCP to increment this per socket counter when it drops an incoming frame, to refine monitoring and debugging. Following patch takes care of listeners drops. Signed-off-by: Eric Dumazet --- include/net/sock.h | 7 +++

  1   2   >