Re: [PATCH] sctp: fix panic when sending auth chunks

From: Marcelo Ricardo Leitner Date: Thu, 7 Jul 2016 09:39:29 -0300 > When we introduced GSO support, if using auth the auth chunk was being > left queued on the packet even after the final segment was generated. > Later on sctp_transmit_packet it calls

Re: [patch -next] bnxt: fix a condition

From: Dan Carpenter Date: Thu, 7 Jul 2016 11:23:09 +0300 > This code generates as static checker warning because htons(ETH_P_IPV6) > is always true. From the context it looks like the && was intended to > be !=. > > Fixes: 94758f8de037 ('bnxt_en: Add GRO logic for

Re: [PATCH net-next] bpf: introduce bpf_get_current_task() helper

From: Alexei Starovoitov Date: Wed, 6 Jul 2016 22:38:36 -0700 > over time there were multiple requests to access different data > structures and fields of task_struct current, so finally add > the helper to access 'current' as-is. Tracing bpf programs will do > the rest of walking

Re: [PATCH net-next] net: dsa: initialize the routing table

From: Vivien Didelot Date: Wed, 6 Jul 2016 20:03:54 -0400 > The routing table of every switch in a tree is currently initialized to > all zeros. This is an issue since 0 is a valid port number. > > Add a DSA_RTABLE_NONE=-1 constant to initialize the signed

[PATCH v2 net-next] rtnl: Add GFP flag argument to rtnl_unicast()

This commit extends rtnl_unicast() to specify GFP flags. This commit depends on Eric Dumazet's commits below. ipv4: do not abuse GFP_ATOMIC in inet_netconf_notify_devconf() ipv6: do not abuse GFP_ATOMIC in inet6_netconf_notify_devconf() Signed-off-by: Masashi Honma

Re: [PATCH net-next] tun: Don't assume type tun in tun_device_event

From: Craig Gallek Date: Wed, 6 Jul 2016 18:44:20 -0400 > From: Craig Gallek > > The referenced change added a netlink notifier for processing > device queue size events. These events are fired for all devices > but the registered callback assumed

Re: pull-request: mac80211 2016-07-06

From: Johannes Berg Date: Wed, 6 Jul 2016 14:27:43 +0200 > People found two more bugs, so I have two more fixes. Both are related to > memory - one's a leak, the other is a missing allocation failure check. > > These are both tagged for stable already, and shouldn't

Re: [RFC 0/7] netlink: Add allocation flag to netlink_unicast()

On 2016年07月06日 09:28, Masashi Honma wrote: > Though netlink_broadcast() ... Thanks for reply of David Miller, Eric Dumazet, David Teigrand. On the basis of their comment, only rtnl_unicast() looks need to add gfp flag argument. So I will drop almost of patches except 0005. I will send patch v2

Re: [RFC 0/7] netlink: Add allocation flag to netlink_unicast()

On 2016年07月09日 01:08, David Teigland wrote: On Thu, Jul 07, 2016 at 09:35:45AM +0900, Masashi Honma wrote: At the fs/dlm/netlink.c#dlm_timeout_warn(), prepare_data allocates buffer with GFP_NOFS and send_data() sends the buffer. But send_data() uses GFP_KERNEL or GFP_ATOMIC inside it. Should

Re: [GIT PULL net-next] rxrpc: Improve conn/call lookup and fix call number generation [ver #3]

From: David Howells Date: Wed, 06 Jul 2016 11:48:15 +0100 > Hi Dave, > > Can you pull this into net-next please? I'll pull, but this is not how I want you to operate. If you change stuff, you must repost the entire series. And this is one of many reasons I want people to

Re: [PATCH net] r8152: remove the setting of LAN_WAKE_EN

From: Hayes Wang Date: Wed, 6 Jul 2016 17:03:29 +0800 > The LAN_WAKE_EN is not used to determine if the device could support > WOL. It is used to sigal a GPIO pin when a WOL event occurs. The WOL > still works even though it is disabled. > > Signed-off-by: Hayes Wang

Re: [Patch net] ppp: defer netns reference release for ppp channel

From: Cong Wang Date: Tue, 5 Jul 2016 22:12:36 -0700 > Matt reported that we have a NULL pointer dereference > in ppp_pernet() from ppp_connect_channel(), > i.e. pch->chan_net is NULL. > > This is due to that a parallel ppp_unregister_channel() > could happen while we

Re: [PATCH net] net: mvneta: set real interrupt per packet for tx_done

From: Marcin Wojtas Date: Wed, 6 Jul 2016 04:18:58 +0200 > From: Dmitri Epshtein > > Commit aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay") intended to > set coalescing threshold to a value guaranteeing interrupt generation > per each sent packet, so

Re: [PATCH RESEND net-next] netvsc: Use the new in-place consumption APIs in the rx path

From: k...@exchange.microsoft.com Date: Tue, 5 Jul 2016 16:52:46 -0700 > From: K. Y. Srinivasan > > Use the new APIs for eliminating a copy on the receive path. These new APIs > also > help in minimizing the number of memory barriers we end up issuing (in the > ringbuffer

Re: [PATCH] net: ip_finish_output_gso: If skb_gso_network_seglen exceeds MTU, do segmentation even for non IPSKB_FORWARDED skbs

From: Shmulik Ladkani Date: Tue, 5 Jul 2016 17:05:41 +0300 > On Tue, 5 Jul 2016 15:03:27 +0200, f...@strlen.de wrote: >> (Or did I misunderstand this setup...?) > > tap0 bridged with vxlan0. > route to vxlan0's remote peer is via eth0, configured with small

Re: [PATCH -next] hfsc: reduce hfsc_sched to 14 cachelines

From: Florian Westphal Date: Mon, 4 Jul 2016 16:22:20 +0200 > hfsc_sched is huge (size: 920, cachelines: 15), but we can get it to 14 > cachelines by placing level after filter_cnt (covering 4 byte hole) and > reducing period/nactive/flags to u32 (period is just a counter, >

Re: [PATCH net-next 0/4] net: cleanup for UDP tunnel's GRO

On Fri, Jul 8, 2016 at 4:04 PM, Hannes Frederic Sowa wrote: > On 08.07.2016 18:11, Alexander Duyck wrote: >> On Fri, Jul 8, 2016 at 2:51 PM, Hannes Frederic Sowa >> wrote: >>> On 08.07.2016 17:27, Alexander Duyck wrote: On Fri, Jul 8,

Re: [PATCH net] udp: prevent bugcheck if filter truncates packet too much

On Sat, Jul 09, 2016 at 01:31:40AM +0200, Eric Dumazet wrote: > On Fri, 2016-07-08 at 17:52 +0200, Michal Kubecek wrote: > > If socket filter truncates an udp packet below the length of UDP header > > in udpv6_queue_rcv_skb() or udp_queue_rcv_skb(), it will trigger a > > BUG_ON in

Re: [PATCH net-next 6/9] net: dsa: mv88e6xxx: rework Switch MAC setter

Hi Andrew, On Jul 7, 2016, at 9:52 AM, Andrew Lunn and...@lunn.ch wrote: >> Also, note that this indirect access is a single-register which doesn't >> require to wait for the operation to complete (like Switch MAC, Trunk >> Mapping, etc.), in contrary to multi-registers indirect accesses with >>

Re: [PATCH net] udp: prevent bugcheck if filter truncates packet too much

On Fri, 2016-07-08 at 17:52 +0200, Michal Kubecek wrote: > If socket filter truncates an udp packet below the length of UDP header > in udpv6_queue_rcv_skb() or udp_queue_rcv_skb(), it will trigger a > BUG_ON in skb_pull_rcsum(). This BUG_ON (and therefore a system crash if > kernel is configured

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

Aaron Conole wrote: > --- a/net/netfilter/core.c > +++ b/net/netfilter/core [..] > +#define nf_entry_dereference(e) \ > + rcu_dereference_protected(e, lockdep_is_held(_hook_mutex)) > > -static struct list_head *nf_find_hook_list(struct net *net, > -

Re: [PATCH] net: Fragment large datagrams even when IP_HDRINCL is set.

Hello! I can tell why it has not been done initially. Main problem was in IP options, which can be present in raw packet. They have to be properly fragmented, some options are to be deleted on fragments. Not that it is too complicated, it is just boring and ugly and inconsistent with IP_HDRINCL

Re: [PATCH net-next 0/4] net: cleanup for UDP tunnel's GRO

On 08.07.2016 18:11, Alexander Duyck wrote: > On Fri, Jul 8, 2016 at 2:51 PM, Hannes Frederic Sowa > wrote: >> On 08.07.2016 17:27, Alexander Duyck wrote: >>> On Fri, Jul 8, 2016 at 1:57 PM, Hannes Frederic Sowa >>> wrote: On

Re: [PATCH] Revert "net: ethernet: bcmgenet: use phy_ethtool_{get|set}_link_ksettings"

On 07/08/2016 03:54 PM, Philippe Reynes wrote: > This reverts commit 4386f5662e63 ("net: ethernet: bcmgenet: use > phy_ethtool_{get|set}_link_ksettings") > > This patch is wrong, the function phy_ethtool_{get|set}_link_ksettings > don't check if the device is running, but the driver bcmgenet need

[PATCH] Revert "net: ethernet: bcmgenet: use phy_ethtool_{get|set}_link_ksettings"

This reverts commit 4386f5662e63 ("net: ethernet: bcmgenet: use phy_ethtool_{get|set}_link_ksettings") This patch is wrong, the function phy_ethtool_{get|set}_link_ksettings don't check if the device is running, but the driver bcmgenet need this check. The function {get|set}_settings need to

Re: [PATCH v2 0/6] net: ethernet: bgmac: Add platform device support

From: Jon Mason Date: Fri, 8 Jul 2016 11:52:42 -0400 > Oops. I didn't send out the 7th patch in this series. Sending out > shortly as 7/7. Please don't do things like this. If there is a mistake, always resend the entire series as a completely new set of postings.

Re: [PATCH] net: Fragment large datagrams even when IP_HDRINCL is set.

From: Paul Jakma Date: Fri, 8 Jul 2016 13:55:11 +0100 (BST) > On Wed, 15 Jun 2016, Alan Davey wrote: > >> The only case that would break is that where an application relies on >> the existing (documented as a bug) feature of getting an EMSGSIZE >> return code in the case of an

Re: [PATCH net-next 0/4] net: cleanup for UDP tunnel's GRO

On Fri, Jul 8, 2016 at 2:51 PM, Hannes Frederic Sowa wrote: > On 08.07.2016 17:27, Alexander Duyck wrote: >> On Fri, Jul 8, 2016 at 1:57 PM, Hannes Frederic Sowa >> wrote: >>> On 08.07.2016 16:17, Shmulik Ladkani wrote: On Fri, 8 Jul

Re: [PATCH net-next 0/4] net: cleanup for UDP tunnel's GRO

On 08.07.2016 17:19, Shmulik Ladkani wrote: > On Fri, 8 Jul 2016 16:57:10 -0400 Hannes Frederic Sowa > wrote: >> On 08.07.2016 16:17, Shmulik Ladkani wrote: >>> On Fri, 8 Jul 2016 09:21:40 -0700 Alexander Duyck >>> wrote: I get that

Re: [PATCH net-next 0/4] net: cleanup for UDP tunnel's GRO

On 08.07.2016 17:27, Alexander Duyck wrote: > On Fri, Jul 8, 2016 at 1:57 PM, Hannes Frederic Sowa > wrote: >> On 08.07.2016 16:17, Shmulik Ladkani wrote: >>> On Fri, 8 Jul 2016 09:21:40 -0700 Alexander Duyck >>> wrote: On Thu, Jul 7,

Re: [PATCH net-next 0/4] net: cleanup for UDP tunnel's GRO

On Fri, Jul 8, 2016 at 1:57 PM, Hannes Frederic Sowa wrote: > On 08.07.2016 16:17, Shmulik Ladkani wrote: >> On Fri, 8 Jul 2016 09:21:40 -0700 Alexander Duyck >> wrote: >>> On Thu, Jul 7, 2016 at 8:58 AM, Paolo Abeni

Re: [PATCH net-next 0/4] net: cleanup for UDP tunnel's GRO

On Fri, 8 Jul 2016 16:57:10 -0400 Hannes Frederic Sowa wrote: > On 08.07.2016 16:17, Shmulik Ladkani wrote: > > On Fri, 8 Jul 2016 09:21:40 -0700 Alexander Duyck > > wrote: > >> I get that there is an impression that it is redundant but

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Fri, Jul 8, 2016 at 9:51 AM, Jason Gunthorpe wrote: > So, it appears, the dst and neigh can be used for all performances cases. > > For the non performance dst == null case, can we just burn cycles and > stuff the daddr in front of the packet at hardheader

[PATCH net] tcp_timer.c: Add kernel-doc function descriptions

This adds kernel-doc style descriptions for 6 functions and fixes 1 typo. Signed-off-by: Richard Sailer --- net/ipv4/tcp_timer.c | 66 +--- 1 file changed, 57 insertions(+), 9 deletions(-) diff --git

Re: [PATCH net-next 2/4] udp offload: allow GRO on 0 checksum packets

On Thu, Jul 7, 2016 at 10:58 AM, Paolo Abeni wrote: > currently, UDP packets with zero checksum are not allowed to > use udp offload's GRO. This patch admits such packets to > GRO, if the related socket settings allow it: ipv6 packets > are not admitted if the sockets don't

Re: [PATCH net-next 0/4] net: cleanup for UDP tunnel's GRO

On 08.07.2016 16:17, Shmulik Ladkani wrote: > On Fri, 8 Jul 2016 09:21:40 -0700 Alexander Duyck > wrote: >> On Thu, Jul 7, 2016 at 8:58 AM, Paolo Abeni wrote: >>> With udp tunnel offload in place, the kernel can do GRO for some udp tunnels >>> at

Re: [PATCH net-next 0/2] net: dsa: b53: Add Broadcom NSP switch support

On Fri, Jul 08, 2016 at 11:39:11AM -0700, Florian Fainelli wrote: > Hi all, > > This patch series updates the B53 driver to support Broadcom's Northstar Plus > Soc integrated switch. Reviewed-by: Andrew Lunn Andrew

Re: [PATCH net-next 0/4] net: cleanup for UDP tunnel's GRO

On Fri, 8 Jul 2016 09:21:40 -0700 Alexander Duyck wrote: > On Thu, Jul 7, 2016 at 8:58 AM, Paolo Abeni wrote: > > With udp tunnel offload in place, the kernel can do GRO for some udp tunnels > > at the ingress device level. Currently both the geneve

Re: [PATCH 0/2] ARM: dts: NSP: Add built-in Ethernet switch nodes

On Fri, Jul 08, 2016 at 11:49:27AM -0700, Florian Fainelli wrote: > This patch series is based on Broadcom/stblinux/devicetree/next which > contains proper support for the BCM958625HR board. To get working > Ethernet switch and CPU Ethernet support, the following dependencies > based on David

Re: [PATCH] bnxt_en: initialize rc to zero to avoid returning garbage

On Fri, Jul 8, 2016 at 8:42 AM, Colin King wrote: > From: Colin Ian King > > rc is not initialized so it can contain garbage if it is not > set by the call to bnxt_read_sfp_module_eeprom_info. Ensure > garbage is not returned by initializing rc

Re: [PATCH 0/2] ARM: dts: NSP: Add built-in Ethernet switch nodes

On 07/08/2016 11:48 AM, Florian Fainelli wrote: > This patch series is based on Broadcom/stblinux/devicetree/next which > contains proper support for the BCM958625HR board. To get working > Ethernet switch and CPU Ethernet support, the following dependencies > based on David Miller's net-next tree

[PATCH 2/2] ARM: dts: NSP: Add BCM958625HR switch ports

Add the layout of the switch ports found on the BCM958625HR reference board. The CPU port is hooked up to the AMAC0 Ethernet controlelr adapter, so we also enable it. Signed-off-by: Florian Fainelli --- arch/arm/boot/dts/bcm958625hr.dts | 49

[PATCH 1/2] ARM: dts: NSP: Add Switch Register Access Block node

Add the Switch Register Access Block node, this peripheral is identical to the BCM5301x Northstar SoC, but we utilize the SoC-wide "brcm,nsp-srab" compatible string to illustrate the integration difference here. Signed-off-by: Florian Fainelli ---

[PATCH 1/2] ARM: dts: NSP: Add Switch Register Access Block node

Add the Switch Register Access Block node, this peripheral is identical to the BCM5301x Northstar SoC, but we utilize the SoC-wide "brcm,nsp-srab" compatible string to illustrate the integration difference here. Signed-off-by: Florian Fainelli ---

[PATCH 0/2] ARM: dts: NSP: Add built-in Ethernet switch nodes

This patch series is based on Broadcom/stblinux/devicetree/next which contains proper support for the BCM958625HR board. To get working Ethernet switch and CPU Ethernet support, the following dependencies based on David Miller's net-next tree are required: - Jon Mason's BGMAC/AMAC support:

[PATCH 1/3] ARM: dts: Enable SRAB switch and GMACs on 5301x DTS

Add the Switch Register Access Block which is a special piece of hardware allowing us to perform indirect read/writes towards the integrated BCM5301X Ethernet switch. We also add the 4 Gigabit MAC Device Tree nodes within the brcm,bus-axi bus node to get proper binding between the BCMA

[PATCH 0/2] ARM: dts: NSP: Add built-in Ethernet switch nodes

This patch series is based on Broadcom/stblinux/devicetree/next which contains proper support for the BCM958625HR board. To get working Ethernet switch and CPU Ethernet support, the following dependencies based on David Miller's net-next tree are required: - Jon Mason's BGMAC/AMAC support:

[PATCH 2/3] ARM: dts: BCM5301X: Add SRAB interrupts

Add interrupt mapping for the Switch Register Access Block. Only 12 interrupts are usable at the moment even though up to 32 are dedicated to the SRAB. Signed-off-by: Florian Fainelli --- arch/arm/boot/dts/bcm5301x.dtsi | 15 +++ 1 file changed, 15

[PATCH 2/2] ARM: dts: NSP: Add BCM958625HR switch ports

Add the layout of the switch ports found on the BCM958625HR reference board. The CPU port is hooked up to the AMAC0 Ethernet controlelr adapter, so we also enable it. Signed-off-by: Florian Fainelli --- arch/arm/boot/dts/bcm958625hr.dts | 49

[PATCH net-next 0/2] net: dsa: b53: Add Broadcom NSP switch support

Hi all, This patch series updates the B53 driver to support Broadcom's Northstar Plus Soc integrated switch. Unlike the version of the core present in BCM5301x/Northstar, we cannot read the full chip id of the switch, so we need to get the information about our switch id from Device Tree. Other

[PATCH net-next 2/2] net: dsa: b53: Add support for BCM585xx/586xx/88312 integrated switch

Update the SRAB, core driver and binding document to support the BCM585xx/586xx/88312 integrated switch (Northstar Plus SoCs family). Signed-off-by: Florian Fainelli --- Documentation/devicetree/bindings/net/dsa/b53.txt | 9 + drivers/net/dsa/b53/b53_common.c

[PATCH net-next 1/2] net: dsa: b53: Allow SRAB driver to specify platform data

For Northstart Plus SoCs, we cannot detect the switch because only the revision information is provied in the Management page, instead, rely on Device Tree to tell us the chip id, and pass it down using the b53_platform_data structure. Signed-off-by: Florian Fainelli ---

Re: [PATCH v2 3/6] net: ethernet: bgmac: move BCMA MDIO Phy code into a separate file

On 07/07/2016 04:08 PM, Jon Mason wrote: > Move the BCMA MDIO phy into a separate file, as it is very tightly > coupled with the BCMA bus. This will help with the upcoming BCMA > removal from the bgmac driver. Optimally, this should be moved into > phy drivers, but it is too tightly coupled with

Re: [PATCH v2 5/6] net: ethernet: bgmac: Add platform device support

On 07/07/2016 04:08 PM, Jon Mason wrote: > The bcma portion of the driver has been split off into a bcma specific > driver. This has been mirrored for the platform driver. The last > references to the bcma core struct have been changed into a generic > function call. These function calls are

Re: [PATCH v2 6/6] dt-bindings: net: bgmac: add bindings documentation for bgmac

On 07/07/2016 04:08 PM, Jon Mason wrote: > Signed-off-by: Jon Mason Reviewed-by: Florian Fainelli Tested-by: Florian Fainelli -- Florian

Re: [PATCH v2 4/6] net: ethernet: bgmac: convert to feature flags

On 07/07/2016 04:08 PM, Jon Mason wrote: > The bgmac driver is using the bcma provides device ID and revision, as > well as the SoC ID and package, to determine which features are > necessary to enable, reset, etc in the driver. In anticipation of > removing the bcma requirement for this driver,

Re: [PATCH v2 2/6] net: ethernet: bgmac: add dma_dev pointer

On 07/07/2016 04:08 PM, Jon Mason wrote: > The dma buffer allocation, etc references a dma_dev device pointer from > the bcma core. In anticipation of removing the bcma requirement for > this driver, these must be changed to not reference that struct. Add a > dma_dev device pointer to the bgmac

Re: [PATCH v2 1/6] net: ethernet: bgmac: change bgmac_* prints to dev_* prints

On 07/07/2016 04:08 PM, Jon Mason wrote: > The bgmac_* print wrappers call dev_* prints with the dev pointer from > the bcma core. In anticipation of removing the bcma requirement for > this driver, these must be changed to not reference that struct. So, > simply change all of the bgmac_* prints

Re: [PATCH v2 0/6] net: ethernet: bgmac: Add platform device support

On 07/07/2016 04:08 PM, Jon Mason wrote: > David Miller, Please consider including patches 1-5 in net-next > > Florian Fainelli, Please consider including patches 6 & 7 in > devicetree/next David should pick all 6 patches, including the binding documentation, as this comes with the driver, I

Re: XDP seeking input from NIC hardware vendors

On Fri, 8 Jul 2016 09:45:25 -0700, John Fastabend wrote: > The only distinction between VFs and queue groupings on my side is VFs > provide RSS where as queue groupings have to be selected explicitly. > In a programmable NIC world the distinction might be lost if a "RSS" > program can be loaded

[net-next 5/6] libcxgb: export ppm release and tagmask set api

Export cxgbi_ppm_release() to release ppod manager and cxgbi_tagmask_set() to set tag mask, they are used by cxgb3i, cxgb4i and cxgbit. Signed-off-by: Varun Prakash --- drivers/net/ethernet/chelsio/libcxgb/libcxgb_ppm.c | 2 ++ drivers/scsi/cxgbi/cxgb3i/cxgb3i.c

[net-next 6/6] cxgb3i,cxgb4i: fix symbol not declared sparse warning

Fix following sparse warnings warning: symbol 'cxgb3i_ofld_init' was not declared. Should it be static? warning: symbol 'cxgb4i_cplhandlers' was not declared. Should it be static? warning: symbol 'cxgb4i_ofld_init' was not declared. Should it be static? Signed-off-by: Varun Prakash

[net-next 3/6] cxgb4i,libcxgbi: add iSCSI DDP support

Add iSCSI DDP support in cxgb4i driver using common iSCSI DDP Page Pod Manager. Signed-off-by: Varun Prakash --- drivers/scsi/cxgbi/Makefile| 2 + drivers/scsi/cxgbi/cxgb3i/Kbuild | 1 + drivers/scsi/cxgbi/cxgb3i/Kconfig | 1 +

[net-next 2/6] cxgb3i,cxgb4i,libcxgbi: remove iSCSI DDP support

Remove old ddp code from cxgb3i,cxgb4i,libcxgbi. Next two commits adds DDP support using common iSCSI DDP Page Pod Manager. Signed-off-by: Varun Prakash --- drivers/scsi/cxgbi/cxgb3i/cxgb3i.c | 128 drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 142 -

[net-next 1/6] libcxgb: add library module for Chelsio drivers

Add common library module(libcxgb.ko) for Chelsio drivers to remove duplicate code. Code for iSCSI DDP Page Pod Manager is moved from cxgb4.ko to libcxgb.ko. Earlier only cxgbit.ko was using this code, now cxgb3i and cxgb4i will also use common Page Pod manager code. In future this module will

[net-next 4/6] cxgb3i: add iSCSI DDP support

Add iSCSI DDP support in cxgb3i driver using common iSCSI DDP Page Pod Manager. Signed-off-by: Varun Prakash --- drivers/scsi/cxgbi/cxgb3i/cxgb3i.c | 119 - 1 file changed, 118 insertions(+), 1 deletion(-) diff --git

[net-next 0/6] common library for Chelsio drivers

Hi, This patch series adds common library module(libcxgb.ko) for Chelsio drivers to remove duplicate code. This series moves common iSCSI DDP Page Pod manager code from cxgb4.ko to libcxgb.ko, earlier this code was used by only cxgbit.ko now it is used by three Chelsio iSCSI drivers cxgb3i,

Re: [iproute PATCH 0/2] Netns performance improvements

On 07/08/2016 01:01 AM, Nicolas Dichtel wrote: Those 300 routers will each have at least one namespace along with the dhcp namespaces. Depending on the nature of the routers (Distributed versus Centralized Virtual Routers - DVR vs CVR) and whether the routers are supposed to be "HA" there can

Re: [PATCH net-next 2/4] udp offload: allow GRO on 0 checksum packets

On Fri, Jul 8, 2016 at 9:56 AM, Hannes Frederic Sowa wrote: > On 08.07.2016 12:46, Alexander Duyck wrote: >> On Thu, Jul 7, 2016 at 8:58 AM, Paolo Abeni wrote: >>> currently, UDP packets with zero checksum are not allowed to >>> use udp offload's

Re: [PATCH v2 1/2] libxt_hashlimit: Prepare libxt_hashlimit.c for revision 2

On 07/08/2016 12:54 PM, Vishwanath Pai wrote: > On 07/08/2016 12:37 PM, David Laight wrote: >> If you think some users would still want 32bit limits, then you should >> (probably) use a _64 suffix for the new functions. >> >> David > > I am proposing a new revision for hashlimit that

RE: [Intel-wired-lan] [PATCH] (resend) ixgbe: always initialize setup_fc

>-Original Message- >From: Patrick McLean [mailto:patri...@gaikai.com] >Sent: Friday, July 08, 2016 9:45 AM >To: zhuyj >Cc: Tantilov, Emil S ; Rustad, Mark D >; netdev ; intel-wired-lan

Re: [PATCH net-next 2/4] udp offload: allow GRO on 0 checksum packets

On 08.07.2016 12:46, Alexander Duyck wrote: > On Thu, Jul 7, 2016 at 8:58 AM, Paolo Abeni wrote: >> currently, UDP packets with zero checksum are not allowed to >> use udp offload's GRO. This patch admits such packets to >> GRO, if the related socket settings allow it: ipv6

Re: [PATCH v2 1/2] libxt_hashlimit: Prepare libxt_hashlimit.c for revision 2

On 07/08/2016 12:37 PM, David Laight wrote: > If you think some users would still want 32bit limits, then you should > (probably) use a _64 suffix for the new functions. > > David I am proposing a new revision for hashlimit that supports a higher rate along with a few other changes/fixes

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Fri, Jul 08, 2016 at 07:18:11AM -0700, Roland Dreier wrote: > On Thu, Jul 7, 2016 at 4:14 PM, Jason Gunthorpe > wrote: > > We have neighbour_priv, and ndo_neigh_construct/destruct now .. > > > > A first blush that would seem to be enough to let ipoib store the

Re: [PATCH v6 12/12] net/mlx4_en: add prefetch in xdp rx path

On Fri, Jul 08, 2016 at 08:56:45AM +0200, Eric Dumazet wrote: > On Thu, 2016-07-07 at 21:16 -0700, Alexei Starovoitov wrote: > > > I've tried this style of prefetching in the past for normal stack > > and it didn't help at all. > > This is very nice, but my experience showed opposite numbers. >

Re: XDP seeking input from NIC hardware vendors

On 16-07-08 09:07 AM, Jakub Kicinski wrote: > On Fri, 8 Jul 2016 17:19:43 +0200, Jesper Dangaard Brouer wrote: >> On Fri, 8 Jul 2016 14:44:53 +0100 Jakub Kicinski >> wrote: >>> On Thu, 7 Jul 2016 19:22:12 -0700, Alexei Starovoitov wrote: > If the goal is to just

Re: [PATCH net-next 2/4] udp offload: allow GRO on 0 checksum packets

On Thu, Jul 7, 2016 at 8:58 AM, Paolo Abeni wrote: > currently, UDP packets with zero checksum are not allowed to > use udp offload's GRO. This patch admits such packets to > GRO, if the related socket settings allow it: ipv6 packets > are not admitted if the sockets don't have

Re: [Intel-wired-lan] [PATCH] (resend) ixgbe: always initialize setup_fc

How about just initializing it when the rest of the struct is initialized? This is what is done for every other model. On Fri, Jul 8, 2016 at 2:47 AM, zhuyj wrote: > Sure. setup_fc should not be null. Emil, your patch can fix it well. > > On Fri, Jul 8, 2016 at 8:18 AM,

RE: [PATCH v2 1/2] libxt_hashlimit: Prepare libxt_hashlimit.c for revision 2

From: Vishwanath Pai > Sent: 08 July 2016 00:34 > I am planning to add a revision 2 for the hashlimit xtables module to > support higher packets per second rates. This patch renames all the > functions and variables related to revision 1 by adding _v1 at the end of > the names. Sounds backwards.

[PATCH net] tcp: make challenge acks less predictable

From: Eric Dumazet Yue Cao claims that current host rate limiting of challenge ACKS (RFC 5961) could leak enough information to allow a patient attacker to hijack TCP sessions. He will soon provide details in an academic paper. This patch increases the default limit from

Re: [PATCH net-next 0/4] net: cleanup for UDP tunnel's GRO

On Thu, Jul 7, 2016 at 8:58 AM, Paolo Abeni wrote: > With udp tunnel offload in place, the kernel can do GRO for some udp tunnels > at the ingress device level. Currently both the geneve and the vxlan drivers > implement an additional GRO aggregation point via gro_cells. > The

Re: ipv6 issues after an DDoS for kernel 4.6.3

On 07/08/2016 05:38 PM, Eric Dumazet wrote: > With IPv4, a server can typically absorb 10 Mpps SYN without major > disruption on linux-4.6 Well, this particular server even survived >900 MBit/sec w/o any service disruption at IPv4 ([1]) but yesterday with a much more less attack the IPv6 issue

Re: [PATCH] xen-netback: prefer xenbus_write() over xenbus_printf() where possible

On Fri, Jul 08, 2016 at 05:13:49PM +0100, Wei Liu wrote: > On Thu, Jul 07, 2016 at 01:58:18AM -0600, Jan Beulich wrote: > > ... as being the simpler variant. > > > > Signed-off-by: Jan Beulich > > Acked-by: Wei Liu Please ignore this, I acked v2

Re: [Xen-devel] [PATCH v2 4/4] xen-netback: prefer xenbus_scanf() over xenbus_gather()

On Fri, Jul 08, 2016 at 06:28:58AM -0600, Jan Beulich wrote: > For single items being collected this should be preferred as being more > typesafe (as the compiler can check format string and to-be-written-to > variable match) and more efficient (requiring one less parameter to be > passed). > >

Re: [PATCH net-next 3/4] vxlan: remove gro_cell support

On Fri, 2016-07-08 at 11:55 -0400, Hannes Frederic Sowa wrote: > Exactly, thus we are also only touching UDP tunneling protocols at the > moment. Did you nack the removal of gro_cell support from the udp > protocols or are you fine with it, given that we won't take away the > functionality to

Re: [PATCH 7/7] ARM: dts: NSP: Add bgmac entries

Hi Jon, In Subject line, you mean add amac entries. On 16-07-08 08:56 AM, Jon Mason wrote: Add device tree entries for the ethernet devices present on the Broadcom Northstar Plus SoCs Signed-off-by: Jon Mason --- arch/arm/boot/dts/bcm-nsp.dtsi | 18

Re: [PATCH] xen-netback: prefer xenbus_write() over xenbus_printf() where possible

On Thu, Jul 07, 2016 at 01:58:18AM -0600, Jan Beulich wrote: > ... as being the simpler variant. > > Signed-off-by: Jan Beulich Acked-by: Wei Liu

Re: XDP seeking input from NIC hardware vendors

On Fri, 8 Jul 2016 17:19:43 +0200, Jesper Dangaard Brouer wrote: > On Fri, 8 Jul 2016 14:44:53 +0100 Jakub Kicinski > wrote: > > On Thu, 7 Jul 2016 19:22:12 -0700, Alexei Starovoitov wrote: > > > > If the goal is to just separate XDP traffic from non-XDP traffic > >

[PATCH net] udp: prevent bugcheck if filter truncates packet too much

If socket filter truncates an udp packet below the length of UDP header in udpv6_queue_rcv_skb() or udp_queue_rcv_skb(), it will trigger a BUG_ON in skb_pull_rcsum(). This BUG_ON (and therefore a system crash if kernel is configured that way) can be easily enforced by an unprivileged user which

[net-next PATCH RFC] mlx4: RX prefetch loop

This patch is about prefetching without being opportunistic. The idea is only to start prefetching on packets that are marked as ready/completed in the RX ring. This is acheived by splitting the napi_poll call mlx4_en_process_rx_cq() loop into two. The first loop extract completed CQEs and start

Re: [PATCH v2 0/6] net: ethernet: bgmac: Add platform device support

On Thu, Jul 7, 2016 at 7:08 PM, Jon Mason wrote: > David Miller, Please consider including patches 1-5 in net-next > > Florian Fainelli, Please consider including patches 6 & 7 in > devicetree/next Oops. I didn't send out the 7th patch in this series. Sending out

[PATCH 7/7] ARM: dts: NSP: Add bgmac entries

Add device tree entries for the ethernet devices present on the Broadcom Northstar Plus SoCs Signed-off-by: Jon Mason --- arch/arm/boot/dts/bcm-nsp.dtsi | 18 ++ arch/arm/boot/dts/bcm958625k.dts | 8 2 files changed, 26 insertions(+) diff

Re: [PATCH net-next 3/4] vxlan: remove gro_cell support

On 08.07.2016 11:33, Eric Dumazet wrote: > On Fri, 2016-07-08 at 11:12 -0400, Hannes Frederic Sowa wrote: >> Hi Eric, >> >> On 07.07.2016 12:13, Eric Dumazet wrote: >>> On Thu, 2016-07-07 at 17:58 +0200, Paolo Abeni wrote: GRO is now handled entirely by the udp_offload layer and there is no

Re: ipv6 issues after an DDoS for kernel 4.6.3

On Fri, 2016-07-08 at 11:43 -0400, Hannes Frederic Sowa wrote: > Exactly, I can very well imagine that the stack becomes unresponsive > during DDoS, but after the DDoS I don't see a reason why services should > come up like in IPv4. If the service uses different listeners, one for IPV4, one (or

Re: ipv6 issues after an DDoS for kernel 4.6.3

On 08.07.2016 11:38, Eric Dumazet wrote: > On Fri, 2016-07-08 at 11:28 -0400, Hannes Frederic Sowa wrote: >> On 08.07.2016 10:14, Eric Dumazet wrote: >>> On Fri, 2016-07-08 at 15:51 +0200, Toralf Förster wrote: I do run a 4.6.3 hardened Gentoo kernel at a commodity i7 server. A DDoS with

[PATCH] bnxt_en: initialize rc to zero to avoid returning garbage

From: Colin Ian King rc is not initialized so it can contain garbage if it is not set by the call to bnxt_read_sfp_module_eeprom_info. Ensure garbage is not returned by initializing rc to 0. Signed-off-by: Colin Ian King ---

Re: ipv6 issues after an DDoS for kernel 4.6.3

On Fri, 2016-07-08 at 16:34 +0200, Toralf Förster wrote: > On 07/08/2016 04:14 PM, Eric Dumazet wrote: > > Are you sure conntrack is needed at all ? > > Erm, I didn't mention conntrack - but yes, I do have in the firewall rules. > > It is my understanding that conntrack is best practise, right ?

Re: ipv6 issues after an DDoS for kernel 4.6.3

On Fri, 2016-07-08 at 11:28 -0400, Hannes Frederic Sowa wrote: > On 08.07.2016 10:14, Eric Dumazet wrote: > > On Fri, 2016-07-08 at 15:51 +0200, Toralf Förster wrote: > >> I do run a 4.6.3 hardened Gentoo kernel at a commodity i7 server. A > >> DDoS with about 300 MBit/sec over 5 mins resulted an

Re: ipv6 issues after an DDoS for kernel 4.6.3

On 08.07.2016 10:14, Eric Dumazet wrote: > On Fri, 2016-07-08 at 15:51 +0200, Toralf Förster wrote: >> I do run a 4.6.3 hardened Gentoo kernel at a commodity i7 server. A >> DDoS with about 300 MBit/sec over 5 mins resulted an issue for ipv6 at >> that system. >> >> The IPv6 monitoring from my ISP

Re: [PATCH net-next 3/4] vxlan: remove gro_cell support

On Fri, 2016-07-08 at 11:12 -0400, Hannes Frederic Sowa wrote: > Hi Eric, > > On 07.07.2016 12:13, Eric Dumazet wrote: > > On Thu, 2016-07-07 at 17:58 +0200, Paolo Abeni wrote: > >> GRO is now handled entirely by the udp_offload layer and there is no need > >> for trying it again at the device

  1   2   >