Re: [PATCH] cxgb4: fix signed wrap around when decrementing index idx

From: Colin King Date: Tue, 20 Sep 2016 15:48:45 +0100 > From: Colin Ian King > > Change predecrement compare to post decrement compare to avoid an > unsigned integer wrap-around comparison when decrementing idx in > the while loop. > > For

Re: [PATCH net] net/mlx4_core: Fix to clean devlink resources

From: Tariq Toukan Date: Tue, 20 Sep 2016 14:55:31 +0300 > From: Kamal Heib > > This patch cleans devlink resources by calling devlink_port_unregister() > to avoid the following issues: > > - Kernel panic when triggering reset flow. > - Memory leak

Re: [PATCH net-next v3 0/5] cxgb4: add support for offloading TC u32 filters

From: Rahul Lakkireddy Date: Tue, 20 Sep 2016 17:13:05 +0530 > This series of patches add support to offload TC u32 filters onto > Chelsio NICs. > > Patch 1 moves current common filter code to separate files > in order to provide a common api for performing packet

Re: [RFC PATCH v3 2/7] proc: Reduce cache miss in {snmp,netstat}_seq_show

On 9/22/16 2:24 AM, Marcelo wrote: On Thu, Sep 22, 2016 at 12:18:46AM +0800, hejianet wrote: Hi Marcelo sorry for the late, just came back from a vacation. Hi, no problem. Hope your batteries are recharged now :-) On 9/14/16 7:55 PM, Marcelo wrote: Hi Jia, On Wed, Sep 14, 2016 at

Re: [PATCH v3 net-next 1/2] net: skbuff: Remove errornous length validation in skb_vlan_pop()

From: Shmulik Ladkani Date: Tue, 20 Sep 2016 12:48:36 +0300 > In 93515d53b1 > "net: move vlan pop/push functions into common code" > skb_vlan_pop was moved from its private location in openvswitch to > skbuff common code. > > In case skb has non hw-accel

Re: [PATCH v3 net-next 2/2] net: skbuff: Coding: Use eth_type_vlan() instead of open coding it

From: Shmulik Ladkani Date: Tue, 20 Sep 2016 12:48:37 +0300 > Fix 'skb_vlan_pop' to use eth_type_vlan instead of directly comparing > skb->protocol to ETH_P_8021Q or ETH_P_8021AD. > > Signed-off-by: Shmulik Ladkani Applied.

Re: [PATCH v2 0/2] act_vlan: Introduce TCA_VLAN_ACT_MODIFY vlan action

From: Shmulik Ladkani Date: Mon, 19 Sep 2016 19:11:08 +0300 > TCA_VLAN_ACT_MODIFY allows one to change an existing tag. > > It accepts same attributes as TCA_VLAN_ACT_PUSH (protocol, id, > priority). > If packet is vlan tagged, then the tag gets overwritten according

Re: [PATCH] net: explicitly whitelist sysctls for unpriv namespaces

From: Jann Horn Date: Sun, 18 Sep 2016 22:58:20 +0200 > There were two net sysctls that could be written from unprivileged net > namespaces, but weren't actually namespaced. > > To fix the existing issues and prevent stuff this from happening again in > the future, explicitly

Re: [PATCH] net: explicitly whitelist sysctls for unpriv namespaces

From: Jann Horn Date: Sun, 18 Sep 2016 22:58:20 +0200 > There were two net sysctls that could be written from unprivileged net > namespaces, but weren't actually namespaced. > > To fix the existing issues and prevent stuff this from happening again in > the future, explicitly

Re: [PATCH net-next 9/9] rxrpc: Reduce the number of ACK-Requests sent

Hi David, [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/David-Howells/rxrpc-Preparation-for-slow-start-algorithm/20160922-085242 config: arm-omap2plus_defconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705

Re: [PATCH nf v3] netfilter: seqadj: Fix the wrong ack adjust for the RST packet without ack

On Thu, 2016-09-22 at 10:22 +0800, f...@ikuai8.com wrote: > From: Gao Feng > > It is valid that the TCP RST packet which does not set ack flag, and bytes > of ack number are zero. But current seqadj codes would adjust the "0" ack > to invalid ack number. Actually seqadj need to

Re: [patch net-next 2/6] fib: introduce FIB info offload flag helpers

On Wed, Sep 21, 2016 at 01:53:10PM +0200, Jiri Pirko wrote: > From: Jiri Pirko > > These helpers are to be used in case someone offloads the FIB entry. The > result is that if the entry is offloaded to at least one device, the > offload flag is set. > > Signed-off-by: Jiri

Re: [patch net-next 1/6] fib: introduce FIB notification infrastructure

On Wed, Sep 21, 2016 at 01:53:09PM +0200, Jiri Pirko wrote: > From: Jiri Pirko > > This allows to pass information about added/deleted FIB entries/rules to > whoever is interested. This is done in a very similar way as devinet > notifies address additions/removals. > >

Re: [PATCH net-next 3/9] rxrpc: Add per-peer RTT tracker

Hi David, [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/David-Howells/rxrpc-Preparation-for-slow-start-algorithm/20160922-085242 config: i386-randconfig-h0-09220655 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce:

Re: [PATCH net-next 3/9] rxrpc: Add per-peer RTT tracker

Hi David, [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/David-Howells/rxrpc-Preparation-for-slow-start-algorithm/20160922-085242 config: arm-omap2plus_defconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705

[PATCH] net: VRF: Fix receiving multicast traffic

The previous patch to ensure that the original iif was used when checking for forwarding also meant that this same interface was used to determine whether multicast packets should be received or not. This was incorrect, and would cause multicast packets to be dropped. The fix here is to use

Re: [PATCH net-next v2 0/3] add support for RGMII on GMAC0 through TRGMII hardware module

Le 21/09/2016 à 19:33, sean.w...@mediatek.com a écrit : > From: Sean Wang > > By default, GMAC0 is connected to built-in switch called > MT7530 through the proprietary interface called Turbo RGMII > (TRGMII). TRGMII also supports well for RGMII as generic external > PHY

[PATCH net-next v2 3/3] net: ethernet: mediatek: add the dts property to set if TRGMII supported on GMAC0

From: Sean Wang Add the dts property for the capability if TRGMII supported on GAMC0 Signed-off-by: Sean Wang --- Documentation/devicetree/bindings/net/mediatek-net.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

[PATCH net-next v2 1/3] net: ethernet: mediatek: add extension of phy-mode for TRGMII

From: Sean Wang adds PHY-mode "trgmii" as an extension for the operation mode of the PHY interface for PHY_INTERFACE_MODE_TRGMII. and adds a variable trgmii inside mtk_mac as the indication to make the difference between the MAC connected to internal switch or connected

[PATCH net-next v2 2/3] net: ethernet: mediatek: add support for GMAC0 connecting with external PHY through TRGMII

From: Sean Wang Changing dynamically source clock, TX/RX delay and interface mode used by TRGMII hardware module inside PHY capability polling routine for adapting to the various speed of RGMII used by external PHY for GMAC0. Signed-off-by: Sean Wang

[PATCH net-next v2 0/3] add support for RGMII on GMAC0 through TRGMII hardware module

From: Sean Wang By default, GMAC0 is connected to built-in switch called MT7530 through the proprietary interface called Turbo RGMII (TRGMII). TRGMII also supports well for RGMII as generic external PHY uses but requires some slight changes to the setup of TRGMII and

[PATCH nf v3] netfilter: seqadj: Fix the wrong ack adjust for the RST packet without ack

From: Gao Feng It is valid that the TCP RST packet which does not set ack flag, and bytes of ack number are zero. But current seqadj codes would adjust the "0" ack to invalid ack number. Actually seqadj need to check the ack flag before adjust it for these RST packets. The

Re: [PATCH net] tcp: fix under-accounting retransmit SNMP counters

On Wed, 2016-09-21 at 16:16 -0700, Yuchung Cheng wrote: > This patch fixes these under-accounting SNMP rtx stats > LINUX_MIB_TCPFORWARDRETRANS > LINUX_MIB_TCPFASTRETRANS > LINUX_MIB_TCPSLOWSTARTRETRANS > when retransmitting TSO packets > > Fixes: 10d3be569243 ("tcp-tso: do not split TSO packets

Re: [PATCH net-next V2 0/4] mlx4 misc cleanups and improvements

From: Tariq Toukan Date: Tue, 20 Sep 2016 14:39:38 +0300 > This patchset contains some cleanups and improvements from the team > to the mlx4 Eth and core drivers. > > Series generated against net-next commit: > 5a7aa362 'net sched: stylistic cleanups' Series applied,

Re: pull-request: wireless-drivers 2016-09-20

From: Kalle Valo Date: Tue, 20 Sep 2016 13:20:46 +0300 > last pull request for 4.8, unless something really drastic comes up. And > a small one even, just a small fix to iwlwifi to avoid a firmware crash. > > Please let me know if there are any problems. Pulled, thanks.

Re: [PATCH net-next 8/9] rxrpc: Reduce the number of PING ACKs sent

Hi David, [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/David-Howells/rxrpc-Preparation-for-slow-start-algorithm/20160922-085242 config: i386-randconfig-x009-201638 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce:

[PATCH net-next 8/9] rxrpc: Reduce the number of PING ACKs sent

We don't want to send a PING ACK for every new incoming call as that just adds to the network traffic. Instead, we send a PING ACK to the first three that we receive and then once per second thereafter. This could probably be made adjustable in future. Signed-off-by: David Howells

[PATCH net-next 7/9] rxrpc: Obtain RTT data by requesting ACKs on DATA packets

In addition to sending a PING ACK to gain RTT data, we can set the RXRPC_REQUEST_ACK flag on a DATA packet and get a REQUESTED-ACK ACK. The ACK packet contains the serial number of the packet it is in response to, so we can look through the Tx buffer for a matching DATA packet. This requires

[PATCH net-next 6/9] rxrpc: Add ktime_sub_ms()

Add a ktime_sub_ms() to go with ktime_add_ms() and co. for use in AF_RXRPC RTT determination. Signed-off-by: David Howells --- include/linux/ktime.h |5 + 1 file changed, 5 insertions(+) diff --git a/include/linux/ktime.h b/include/linux/ktime.h index

[PATCH net-next 1/9] rxrpc: Don't store the rxrpc header in the Tx queue sk_buffs

Don't store the rxrpc protocol header in sk_buffs on the transmit queue, but rather generate it on the fly and pass it to kernel_sendmsg() as a separate iov. This reduces the amount of storage required. Note that the security header is still stored in the sk_buff as it may get encrypted along

[PATCH net-next 5/9] rxrpc: Expedite ping response transmission

Expedite the transmission of a response to a PING ACK by sending it from sendmsg if one is pending. We're most likely to see a PING ACK during the client call Tx phase as the other side may use it to determine a number of parameters, such as the client's receive window size, the RTT and whether

[PATCH net-next 9/9] rxrpc: Reduce the number of ACK-Requests sent

Reduce the number of ACK-Requests we set on DATA packets that we're sending to reduce network traffic. We set the flag on odd-numbered DATA packets to start off the RTT cache until we have at least three entries in it and then probe once per second thereafter to keep it topped up. This could be

[PATCH net-next 0/9] rxrpc: Preparation for slow-start algorithm

Here are some patches that prepare for improvements in ACK generation and for the implementation of the slow-start part of the protocol: (1) Stop storing the protocol header in the Tx socket buffers, but rather generate it on the fly. This potentially saves a little space and makes

[PATCH net-next 4/9] rxrpc: Send pings to get RTT data

Send a PING ACK packet to the peer when we get a new incoming call from a peer we don't have a record for. The PING RESPONSE ACK packet will tell us the following about the peer: (1) its receive window size (2) its MTU sizes (3) its support for jumbo DATA packets (4) if it supports slow

[PATCH net-next 2/9] rxrpc: Add re-sent Tx annotation

Add a Tx-phase annotation for packet buffers to indicate that a buffer has already been retransmitted. This will be used by future congestion management. Re-retransmissions of a packet don't affect the congestion window managment in the same way as initial retransmissions. Signed-off-by: David

[PATCH net-next 3/9] rxrpc: Add per-peer RTT tracker

Add a function to track the average RTT for a peer. Sources of RTT data will be added in subsequent patches. The RTT data will be useful in the future for determining resend timeouts and for handling the slow-start part of the Rx protocol. Also add a pair of tracepoints, one to log

Re: XDP (eXpress Data Path) documentation

On Tue, Sep 20, 2016 at 2:08 AM, Jesper Dangaard Brouer wrote: > Hi all, > > As promised, I've started documenting the XDP eXpress Data Path): > > [1] > https://prototype-kernel.readthedocs.io/en/latest/networking/XDP/index.html > > IMHO the documentation have reached a stage

Re: [PATCHv7 net-next 00/15] BPF hardware offload (cls_bpf for now)

From: Jakub Kicinski Date: Wed, 21 Sep 2016 11:43:52 +0100 > In the last year a lot of progress have been made on offloading > simpler TC classifiers. There is also growing interest in using > BPF for generic high-speed packet processing in the kernel. > It seems

Re: [PATCH iproute2 net-next] iptnl: add support for collect_md flag in IPv4 and IPv6 tunnels

On Mon, 19 Sep 2016 17:03:14 -0700 Alexei Starovoitov wrote: > Signed-off-by: Alexei Starovoitov Applied, please send update to man page as well.

Re: [PATCH iproute2] ipmonitor: fix ip monitor can't work when NET_NS is not enabled

On Tue, 20 Sep 2016 02:09:02 -0700 Liping Zhang wrote: > From: Liping Zhang > > In ip monitor, netns_map_init will check getnsid is supported or not. > But when /proc/self/ns/net does not exist, we just print out error > messages and exit. So

Re: [PATCH net-next 2/3] udp: implement memory accounting helpers

On Wed, 2016-09-21 at 19:23 +0200, Paolo Abeni wrote: > Avoid usage of common memory accounting functions, since > the logic is pretty much different. > > To account for forward allocation, a couple of new atomic_t > members are added to udp_sock: 'mem_alloced' and 'mem_freed'. > The current

Re: [PATCH iproute2 3/3] ss: output TCP BBR diag information

On Tue, 20 Sep 2016 22:43:44 -0400 Neal Cardwell wrote: > Dump useful TCP BBR state information from a struct tcp_bbr_info that > was grabbed using the inet_diag API. > > We tolerate info that is shorter or longer than expected, in case the > kernel is older or newer than

[PATCH net] tcp: fix under-accounting retransmit SNMP counters

This patch fixes these under-accounting SNMP rtx stats LINUX_MIB_TCPFORWARDRETRANS LINUX_MIB_TCPFASTRETRANS LINUX_MIB_TCPSLOWSTARTRETRANS when retransmitting TSO packets Fixes: 10d3be569243 ("tcp-tso: do not split TSO packets at retransmit time") Signed-off-by: Yuchung Cheng

[PATCH net] tcp: properly account Fast Open SYN-ACK retrans

Since the TFO socket is accepted right off SYN-data, the socket owner can call getsockopt(TCP_INFO) to collect ongoing SYN-ACK retransmission or timeout stats (i.e., tcpi_total_retrans, tcpi_retransmits). Currently those stats are only updated upon handshake completes. This patch fixes it.

[PATCH net-next v2 3/6] net/faraday: Adapt for Aspeed SoCs

The RXDES and TXDES registers bits in the ftgmac100 indicates EDO{R,T}R at bit position 15 for the Faraday Tech IP. However, the version of this IP present in the Aspeed SoCs has these bits at position 30 in the registers. It appers that ast2400 SoCs support both positions, with the 15th bit

[PATCH net-next v2 6/6] net/faraday: Mask out PHYSTS_CHG interrupt

The PHYSTS_CHG (the ftgmac100's PHY IRQ) is telling the system to go look at the PHY registers for a link status change. The interrupt was causing issues on Aspeed SoC where some board designs had an active high configuration, some active low, and in some cases repurposed for other functions.

[PATCH net-next v2 1/6] net/faraday: Separate rx page storage from rxdesc

From: Andrew Jeffery The ftgmac100 hardware revision in e.g. the Aspeed AST2500 no longer reserves all bits in RXDES#2 but instead uses the bottom 16 bits to store MAC frame metadata. Avoid corruption by shifting struct page pointers out to their own member in struct ftgmac100.

Re: [PATCH net-next 0/7] ftgmac100 support for ast2500

Please ignore this one. On Thu, Sep 22, 2016 at 8:33 AM, Joel Stanley wrote: > Hello Dave, > > This series adds support to the ftgmac100 driver for the Aspeed ast2400 and > ast2500 SoCs. In particular, they ensure the driver works correctly on the > ast2500 where the MAC block

[PATCH net-next v2 4/6] net/faraday: Clear stale interrupts

From: Gavin Shan There is stale interrupt (PHYSTS_CHG in ISR, bit#6 in 0x0) from the bootloader (uboot) when enabling the MAC. The stale interrupts aren't part of kernel and should be cleared. This clears the stale interrupts in ISR (0x0) when enabling the MAC.

[PATCH net-next v2 5/6] net/faraday: Configure old MDIO interface on Aspeed SoCs

The Aspeed SoCs have a new MDIO interface as an option in the G4 and G5 SoCs. The old one is still available, so select it in order to remain compatible with the ftgmac100 driver. Signed-off-by: Joel Stanley --- drivers/net/ethernet/faraday/ftgmac100.c | 9 +

[PATCH net-next v2 0/6] ftgmac100 support for ast2500

Hello Dave, This series adds support to the ftgmac100 driver for the Aspeed ast2400 and ast2500 SoCs. In particular, they ensure the driver works correctly on the ast2500 where the MAC block has seen some changes in register layout. They have been tested on ast2400 and ast2500 systems with the

[PATCH net-next v2 2/6] net/faraday: Make EDO{R,T}R bits configurable

From: Andrew Jeffery These bits are #defined at a fixed location. In order to support future hardware that has chosen to move these bits around move the bits into a member of the struct ftgmac100. Signed-off-by: Andrew Jeffery Signed-off-by: Joel Stanley

[PATCH net-next 0/7] ftgmac100 support for ast2500

Hello Dave, This series adds support to the ftgmac100 driver for the Aspeed ast2400 and ast2500 SoCs. In particular, they ensure the driver works correctly on the ast2500 where the MAC block has seen some changes in register layout. They have been tested on ast2400 and ast2500 systems with the

Re: [net-next 01/15] i40e: Introduce VF port representor/control netdevs

On Wed, 2016-09-21 at 22:21 +0300, Or Gerlitz wrote: > On Wed, Sep 21, 2016 at 7:59 PM, Samudrala, Sridhar > wrote: > > On 9/21/2016 12:04 AM, Or Gerlitz wrote: > > > >> so what happens after this patchset is applied and before the future > work is > >> submitted?

[PATCH] L2TP:Adjust intf MTU, add underlay L3, overlay L2

Take into account all of the tunnel encapsulation headers when setting up the MTU on the L2TP logical interface device. Otherwise, packets created by the applications on top of the L2TP layer are larger than they ought to be, relative to the underlay MTU, leading to needless fragmentation once

Re: [PATCH RFC 1/3] xdp: Infrastructure to generalize XDP

On Wed, 21 Sep 2016 08:08:34 -0700 Tom Herbert wrote: > On Wed, Sep 21, 2016 at 7:48 AM, Thomas Graf wrote: > > On 09/21/16 at 07:19am, Tom Herbert wrote: > >> certain design that because of constraints on one kernel interface. As > >> a kernel developer

Re: [RFC v2 07/12] qedr: Add support for memory registeration verbs

+static int qedr_set_page(struct ib_mr *ibmr, u64 addr) +{ + struct qedr_mr *mr = get_qedr_mr(ibmr); + struct qedr_pbl *pbl_table; + struct regpair *pbe; + u32 pbes_in_page; + + if (unlikely(mr->npages == mr->info.pbl_info.num_pbes)) { +

Re: [net-next 01/15] i40e: Introduce VF port representor/control netdevs

On Wed, Sep 21, 2016 at 7:59 PM, Samudrala, Sridhar wrote: > On 9/21/2016 12:04 AM, Or Gerlitz wrote: >> so what happens after this patchset is applied and before the future work is >> submitted? RX/TX slow path through the VFPRs isn't supported and what >> about

Re: [PATCH RFC 1/3] xdp: Infrastructure to generalize XDP

On 09/21/16 at 11:50am, Tom Herbert wrote: > 50 lines in one driver is not a big deal, 50 lines in a hundred > drivers is! I learned this lesson in BQL which was well abstracted out > to be minimally invasive but we still saw many issues because of the > pecularities of different drivers. You

Re: [PATCH RFC 1/3] xdp: Infrastructure to generalize XDP

On Wed, 21 Sep 2016 11:50:06 -0700, Tom Herbert wrote: > On Wed, Sep 21, 2016 at 11:45 AM, Jakub Kicinski wrote: > > On Wed, 21 Sep 2016 10:39:40 -0700, Tom Herbert wrote: > >> On Wed, Sep 21, 2016 at 10:26 AM, Jakub Kicinski wrote: > >> > On Tue, 20 Sep 2016

Re: [PATCH RFC 1/3] xdp: Infrastructure to generalize XDP

On Wed, Sep 21, 2016 at 11:45 AM, Jakub Kicinski wrote: > On Wed, 21 Sep 2016 10:39:40 -0700, Tom Herbert wrote: >> On Wed, Sep 21, 2016 at 10:26 AM, Jakub Kicinski wrote: >> > On Tue, 20 Sep 2016 17:01:39 -0700, Alexei Starovoitov wrote: >> >> > - Reduces the

Re: [PATCH v6 5/6] net: ipv4, ipv6: run cgroup eBPF egress programs

On 09/21/16 at 05:45pm, Pablo Neira Ayuso wrote: > On Tue, Sep 20, 2016 at 06:43:35PM +0200, Daniel Mack wrote: > > The point is that from an application's perspective, restricting the > > ability to bind a port and dropping packets that are being sent is a > > very different thing. Applications

Re: [PATCH RFC 1/3] xdp: Infrastructure to generalize XDP

On Wed, 21 Sep 2016 10:39:40 -0700, Tom Herbert wrote: > On Wed, Sep 21, 2016 at 10:26 AM, Jakub Kicinski wrote: > > On Tue, 20 Sep 2016 17:01:39 -0700, Alexei Starovoitov wrote: > >> > - Reduces the amount of code and complexity needed in drivers to > >> >manage XDP >

[PATCH v2] tcp: fix wrong checksum calculation on MTU probing

With TCP MTU probing enabled and offload TX checksumming disabled, tcp_mtu_probe() calculated the wrong checksum when a fragment being copied into the probe's SKB had an odd length. This was caused by the direct use of skb_copy_and_csum_bits() to calculate the checksum, as it pads the fragment

Re: [RFC PATCH v3 2/7] proc: Reduce cache miss in {snmp,netstat}_seq_show

On Thu, Sep 22, 2016 at 12:18:46AM +0800, hejianet wrote: > Hi Marcelo > > sorry for the late, just came back from a vacation. Hi, no problem. Hope your batteries are recharged now :-) > > On 9/14/16 7:55 PM, Marcelo wrote: > > Hi Jia, > > > > On Wed, Sep 14, 2016 at 01:58:42PM +0800,

Re: [ANNOUNCE] ndiv: line-rate network traffic processing

Hi Tom, On Wed, Sep 21, 2016 at 10:16:45AM -0700, Tom Herbert wrote: > This does seem interesting and indeed the driver datapath looks very > much like XDP. It would be quite interesting if you could rebase and > then maybe look at how this can work with XDP that would be helpful. OK I'll assign

Re: [ANNOUNCE] ndiv: line-rate network traffic processing

Hi Jesper! On Wed, Sep 21, 2016 at 06:26:39PM +0200, Jesper Dangaard Brouer wrote: > I definitely want to study it! Great, at least I've not put this online for nothing :-) > You mention XDP. If you didn't notice, I've created some documentation > on XDP (it is very "live" documentation at

RE: [PATCH] net: fec: set mac address unconditionally

From: Gavin Schenk Sent: Wednesday, September 21, 2016 9:31 PM > To: Andy Duan > Cc: netdev@vger.kernel.org; ker...@pengutronix.de; Gavin Schenk > > Subject: [PATCH] net: fec: set mac address unconditionally > > Fixes:

Re: [PATCH RFC 1/3] xdp: Infrastructure to generalize XDP

On Wed, Sep 21, 2016 at 10:26 AM, Jakub Kicinski wrote: > On Tue, 20 Sep 2016 17:01:39 -0700, Alexei Starovoitov wrote: >> > - Reduces the amount of code and complexity needed in drivers to >> >manage XDP >> >> hmm: >> 534 insertions(+), 144 deletions(-) >> looks like

As-salam o Alaikum

Hello, I am Saidat, I sent you a message yesterday, Please did you receive it? Thank you!

Re: [PATCH RFC 1/3] xdp: Infrastructure to generalize XDP

On Tue, 20 Sep 2016 17:01:39 -0700, Alexei Starovoitov wrote: > > - Reduces the amount of code and complexity needed in drivers to > >manage XDP > > hmm: > 534 insertions(+), 144 deletions(-) > looks like increase in complexity instead. and more to come to tie this with HW offloads.

Re: [PATCH RFC 1/3] xdp: Infrastructure to generalize XDP

On Wed, 21 Sep 2016 13:55:45 +0200, Thomas Graf wrote: > > I am looking at using this for ILA router. The problem I am hitting is > > that not all packets that we need to translate go through the XDP > > path. Some would go through the kernel path, some through XDP path but > > When you say

[PATCH net-next 1/3] net/socket: factor out helpers for memory and queue manipulation

Basic sock operations that udp code can use with its own memory accounting schema. No functional change is introduced in the existing APIs. Acked-by: Hannes Frederic Sowa Signed-off-by: Paolo Abeni --- include/linux/skbuff.h | 2 +-

[PATCH net-next 2/3] udp: implement memory accounting helpers

Avoid usage of common memory accounting functions, since the logic is pretty much different. To account for forward allocation, a couple of new atomic_t members are added to udp_sock: 'mem_alloced' and 'mem_freed'. The current forward allocation is estimated as 'mem_alloced' minus 'mem_freed'

[PATCH net-next 3/3] udp: use it's own memory accounting schema

Completely avoid default sock memory accounting and replace it with udp-specific accounting. Since the new memory accounting model does not require socket locking, remove the lock on enqueue and free and avoid using the backlog on enqueue. Be sure to clean-up rx queue memory on socket

[PATCH net-next 0/3] udp: refactor memory accounting

This patch series refactor the udp memory accounting, replacing the generic implementation with a custom one, in order to remove the needs for locking the socket on the enqueue and dequeue operations. The socket backlog usage is dropped, as well. The first patch factor out core pieces of some

Re: [ANNOUNCE] ndiv: line-rate network traffic processing

On Wed, Sep 21, 2016 at 4:28 AM, Willy Tarreau wrote: > Hi, > > Over the last 3 years I've been working a bit on high traffic processing > for various reasons. It started with the wish to capture line-rate GigE > traffic on very small fanless ARM machines and the framework has

Re: [PATCH net-next V2] net/vxlan: Avoid unaligned access in vxlan_build_skb()

On Wed, Sep 21, 2016 at 09:53:31AM -0700, Eric Dumazet wrote: > On Wed, 2016-09-21 at 09:14 -0700, Alexei Starovoitov wrote: > > > > > I think it's the opposite. Even on x86 compiler will use byte loads. > > Unless you tweaked gcc, it should still use word loads on x86. > checked that on

Re: [RFC PATCH v3 2/7] proc: Reduce cache miss in {snmp,netstat}_seq_show

Hi Marcelo sorry for the late, just came back from a vacation. On 9/14/16 7:55 PM, Marcelo wrote: Hi Jia, On Wed, Sep 14, 2016 at 01:58:42PM +0800, hejianet wrote: Hi Marcelo On 9/13/16 2:57 AM, Marcelo wrote: On Fri, Sep 09, 2016 at 02:33:57PM +0800, Jia He wrote: This is to use the

Re: [PATCH net-next 1/3] net: ethernet: mediatek: add extension of phy-mode for TRGMII

On 09/21/2016 12:33 AM, Sean Wang wrote: > Date: Tue, 20 Sep 2016 14:23:24 -0700, Florian Fainelli > wrote: >> On 09/20/2016 12:59 AM, sean.w...@mediatek.com wrote: >>> From: Sean Wang >>> >>> adds PHY-mode "trgmii" as an extension for the operation

Re: [net-next 01/15] i40e: Introduce VF port representor/control netdevs

On 9/21/2016 12:04 AM, Or Gerlitz wrote: On Wed, Sep 21, 2016 at 8:45 AM, Samudrala, Sridhar wrote: On 9/20/2016 9:22 PM, Or Gerlitz wrote: On Wed, Sep 21, 2016 at 6:43 AM, Jeff Kirsher wrote: From: Sridhar Samudrala

Re: [PATCH net-next] MAINTAINERS: Update b44 maintainer.

On 09/20/2016 08:33 PM, Michael Chan wrote: > Taking over as maintainer since Gary Zambrano is no longer working > for Broadcom. > > Signed-off-by: Michael Chan Acked-by: Florian Fainelli Thanks Michael! -- Florian

Re: [PATCH net-next V2] net/vxlan: Avoid unaligned access in vxlan_build_skb()

On Wed, 2016-09-21 at 09:14 -0700, Alexei Starovoitov wrote: > > I think it's the opposite. Even on x86 compiler will use byte loads. Unless you tweaked gcc, it should still use word loads on x86.

Re: [PATCH net-next V2] net/vxlan: Avoid unaligned access in vxlan_build_skb()

On 21.09.2016 18:14, Alexei Starovoitov wrote: > On Wed, Sep 21, 2016 at 12:10:55PM +0200, Hannes Frederic Sowa wrote: >> On 20.09.2016 20:57, Sowmini Varadhan wrote: >>> The vxlan header may not be aligned to 4 bytes in >>> vxlan_build_skb (e.g., for MLD packets). This patch >>> avoids unaligned

Re: [ANNOUNCE] ndiv: line-rate network traffic processing

On Wed, 21 Sep 2016 13:28:52 +0200 Willy Tarreau wrote: > Over the last 3 years I've been working a bit on high traffic processing > for various reasons. It started with the wish to capture line-rate GigE > traffic on very small fanless ARM machines and the framework has evolved >

[PATCH net] act_ife: Add support for machines with hard_header_len != mac_len

Without that fix, the following could occur: - On encode ingress, the total amount of skb_pushes (in lines 751 and 753) was more than specified in cow. - On machines with hard_header_len > mac_len, the packet format was not according to the ife specifications, as the place reserved at the

Re: [PATCH net-next V2] net/vxlan: Avoid unaligned access in vxlan_build_skb()

On Wed, Sep 21, 2016 at 12:10:55PM +0200, Hannes Frederic Sowa wrote: > On 20.09.2016 20:57, Sowmini Varadhan wrote: > > The vxlan header may not be aligned to 4 bytes in > > vxlan_build_skb (e.g., for MLD packets). This patch > > avoids unaligned access traps from vxlan_build_skb > > (in

[PATCH iproute2] ss: Support displaying and filtering on socket marks.

This allows the user to dump sockets with a given mark (via "fwmark = 0x1234/0x1234" or "fwmark = 12345", etc.) , and to display the socket marks of dumped sockets. The relevant kernel commits are: d545caca827b ("net: inet: diag: expose the socket mark to privileged processes.") and -

Re: [PATCH v6 5/6] net: ipv4, ipv6: run cgroup eBPF egress programs

Hi Daniel, On Tue, Sep 20, 2016 at 06:43:35PM +0200, Daniel Mack wrote: > Hi Pablo, > > On 09/20/2016 04:29 PM, Pablo Neira Ayuso wrote: > > On Mon, Sep 19, 2016 at 10:56:14PM +0200, Daniel Mack wrote: > > [...] > >> Why would we artificially limit the use-cases of this implementation if > >>

Re: [RFC v2 06/12] qedr: Add support for QP verbs

On Wed, Sep 21, 2016 at 02:23:46PM +, Amrani, Ram wrote: > > Ugh, each patch keeps adding to this? > > The logic in the patch series is to have each patch contain only > what is necessary for the specific functionality it adds. This made > it harder on us to prepare but, IMHO, easier for the

Re: [PATCH] netfilter: replace list_head with single linked list

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

Re: [PATCH RFC 1/3] xdp: Infrastructure to generalize XDP

On 9/20/16 11:39 PM, Jesper Dangaard Brouer wrote: We are the early stages of XDP development. Users cannot consider XDP a stable UAPI yet. I added a big fat warning to the docs here[1]. If you already consider this a stable API, then I will suggest that we disable XDP or rip the hole thing

[PATCH] netfilter: replace list_head with single linked list

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

Re: [PATCH net-next 3/3] net: ethernet: mediatek: add the dts property to set if TRGMII supported on GMAC0

Date: Wed, 21 Sep 2016 16:17:20 +0200, Andrew Lunn wrote: >On Wed, Sep 21, 2016 at 02:16:30PM +0800, Sean Wang wrote: >> Date: Tue, 20 Sep 2016 21:37:58 +0200, Andrew Lunn wrote: >> >On Tue, Sep 20, 2016 at 03:59:20PM +0800, sean.w...@mediatek.com wrote: >> >>

Re: [PATCH RFC 1/3] xdp: Infrastructure to generalize XDP

On 9/21/16 7:19 AM, Tom Herbert wrote: #1: Should we allow alternate code to run in XDP other than BPF? separate nft hook - yes generic hook - no since it's one step away from kernel modules abusing this hook. pass/drop/tx of raw buffer at the driver level is a perfect interface to bypass

Re: [PATCH next v3 0/2] Rename WORD_TRUNC/ROUND macros and use them

On Wed, Sep 21, 2016 at 08:45:54AM -0300, Marcelo Ricardo Leitner wrote: > This patchset aims to rename these macros to a non-confusing name, as > reported by David Laight and David Miller, and to update all remaining > places to make use of it, which was 1 last remaining spot. > > v3: > - Name

[PATCH nf-next v3 5/7] nf_register_net_hook: Only allow sane values

This commit adds an upfront check for sane values to be passed when registering a netfilter hook. This will be used in a future patch for a simplified hook list traversal. Signed-off-by: Aaron Conole --- net/netfilter/core.c | 5 + 1 file changed, 5 insertions(+) diff

[PATCH nf-next v3 1/7] netfilter: bridge: add and use br_nf_hook_thresh

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

[PATCH nf-next v3 2/7] netfilter: call nf_hook_state_init with rcu_read_lock held

From: Florian Westphal This makes things simpler because we can store the head of the list in the nf_state structure without worrying about concurrent add/delete of hook elements from the list. A future commit will make use of this to implement a simpler linked-list.

[PATCH nf-next v3 3/7] netfilter: call nf_hook_ingress with rcu_read_lock

This commit ensures that the rcu read-side lock is held while the ingress hook is called. This ensures that a call to nf_hook_slow (and ultimately nf_ingress) will be read protected. Signed-off-by: Aaron Conole --- net/core/dev.c | 7 ++- 1 file changed, 6

  1   2   3   >