Re: [net] tcp: do tcp_mstamp_refresh before retransmits on TSQ handler

From: Koichiro Den Date: Sun, 22 Oct 2017 13:13:16 +0900 > When retransmission on TSQ handler was introduced in the commit > f9616c35a0d7 ("tcp: implement TSQ for retransmits"), the retransmitted > skbs' timestamps were updated on the actual transmission. In the later >

Re: [PATCH net] tcp/dccp: fix lockdep splat in inet_csk_route_req()

From: Eric Dumazet Date: Sun, 22 Oct 2017 12:33:57 -0700 > From: Eric Dumazet > > This patch fixes the following lockdep splat in inet_csk_route_req() > > lockdep_rcu_suspicious > inet_csk_route_req > tcp_v4_send_synack > tcp_rtx_synack >

Re: [net-next] tcp: do tcp_mstamp_refresh before retransmits on TSQ handler

On Sun, 2017-10-22 at 21:31 -0700, Eric Dumazet wrote: > On Mon, 2017-10-23 at 13:28 +0900, Koichiro Den wrote: > > > Indeed, meaning that tcp_clean_rtx_queue implementation never takes. > > But for me it seems that there is some possibility RACK algorithm will take > > it. > > As long as

Re: [PATCH] net: core: rtnetlink: use BUG_ON instead of if condition followed by BUG

From: "Gustavo A. R. Silva" Date: Fri, 20 Oct 2017 19:43:11 -0500 > Use BUG_ON instead of if condition followed by BUG in do_setlink. > > This issue was detected with the help of Coccinelle. > > Signed-off-by: Gustavo A. R. Silva Applied.

Re: [net-next] tcp: do tcp_mstamp_refresh before retransmits on TSQ handler

On Mon, 2017-10-23 at 13:28 +0900, Koichiro Den wrote: > Indeed, meaning that tcp_clean_rtx_queue implementation never takes. > But for me it seems that there is some possibility RACK algorithm will take > it. As long as tp->tcp_mstamp is monotonically increasing (and it is ;) ), RACK will

Re: [PATCH net-next] net: systemport: Guard against unmapped TX ring

From: Florian Fainelli Date: Fri, 20 Oct 2017 15:59:30 -0700 > Because SYSTEMPORT is a (semi) normal network device, the stack may attempt to > queue packets on it oustide of the DSA slave transmit path. When that > happens, > the DSA layer has not had a chance to tag

Re: [net-next] tcp: do tcp_mstamp_refresh before retransmits on TSQ handler

On Sun, 2017-10-22 at 20:40 -0700, Eric Dumazet wrote: > On Mon, 2017-10-23 at 12:26 +0900, Koichiro Den wrote: > > > Now I wonder this is more of a theoretical one rather than a patch to fix > > one > > specific bug. > > > Note that I said that your patch was fine and I added a 'Reviewed-by:'

Re: [patch net-next 0/8] mlxsw: Add support for non-equal-cost multi-path

From: Jiri Pirko Date: Sun, 22 Oct 2017 23:11:42 +0200 > From: Jiri Pirko > > Ido says: > > In the device, nexthops are stored as adjacency entries in an array > called the KVD linear (KVDL). When a multi-path route is hit the > packet's headers are hashed

Re: [PATCH net-next 0/6] add a set of tracepoints to tcp stack

From: Song Liu Date: Fri, 20 Oct 2017 14:20:40 -0700 > These patches add the following tracepoints to tcp stack. > > tcp_send_reset > tcp_receive_reset > tcp_destroy_sock > tcp_set_state Please fix this build error, it probably happens when IPV6 is built modular: ERROR:

Re: [net-next] tcp: do tcp_mstamp_refresh before retransmits on TSQ handler

On Mon, 2017-10-23 at 12:26 +0900, Koichiro Den wrote: > Now I wonder this is more of a theoretical one rather than a patch to fix one > specific bug. Note that I said that your patch was fine and I added a 'Reviewed-by:' tag. What I meant is that it has no direct effect on correctness of TCP

Re: [net-next] tcp: do tcp_mstamp_refresh before retransmits on TSQ handler

On Sun, 2017-10-22 at 10:11 -0700, Eric Dumazet wrote: > On Sun, 2017-10-22 at 09:49 -0700, Eric Dumazet wrote: > > > Here is the test I cooked. > > > > Note that it actually passes just fine, do I am wondering if your patch > > is needed after all.. > > > > Oh this is because

RE: [patch net v2 1/4] net/sched: Change tc_action refcnt and bindcnt to atomic

> -Original Message- > From: Cong Wang [mailto:xiyou.wangc...@gmail.com] > Sent: Friday, October 20, 2017 11:00 AM > To: Jamal Hadi Salim > Cc: Chris Mi ; Linux Kernel Network Developers > ; Lucas Bates ;

Re: Regression in throughput between kvm guests over virtual bridge

On Mon, Oct 23, 2017 at 10:06:36AM +0800, Jason Wang wrote: > > > On 2017年10月19日 04:17, Matthew Rosato wrote: > > > 2. It might be useful to short the traffic path as a reference, What I am > > > running > > > is briefly like: > > > pktgen(host kernel) -> tap(x) -> guest(DPDK testpmd) > >

Re: [PATCH] isdn/gigaset: Provide cardstate context for bas timer callbacks

From: Kees Cook Date: Fri, 20 Oct 2017 13:47:08 -0700 > While the work callback uses the urb to find cardstate from bas_cardstate, > this may not be valid for timer callbacks. Instead, introduce a direct > pointer back to the cardstate from bas_cardstate for use in timer >

Re: [PATCH net-next v2 0/7] net: dsa: bcm_sf2: Add support for IPv6 CFP rules

From: Florian Fainelli Date: Fri, 20 Oct 2017 14:39:42 -0700 > This patch series adds support for matching IPv6 addresses to the existing CFP > support code. Because IPv6 addresses are four times bigger than IPv4, we can > fit them anymore in a single slice, so we need to

Re: Regression in throughput between kvm guests over virtual bridge

On 2017年10月19日 04:17, Matthew Rosato wrote: 2. It might be useful to short the traffic path as a reference, What I am running is briefly like: pktgen(host kernel) -> tap(x) -> guest(DPDK testpmd) The bridge driver(br_forward(), etc) might impact performance due to my personal

Re: [PATCH v2 2/2] net: netrom: refactor code in nr_add_node

Quoting David Miller : From: "Gustavo A. R. Silva" Date: Sun, 22 Oct 2017 20:08:40 -0500 Code refactoring in order to make it easier to read and maintain. Signed-off-by: Gustavo A. R. Silva Gustavo, always when

Re: [PATCH v2 2/2] net: netrom: refactor code in nr_add_node

From: "Gustavo A. R. Silva" Date: Sun, 22 Oct 2017 20:08:40 -0500 > Code refactoring in order to make it easier to read and maintain. > > Signed-off-by: Gustavo A. R. Silva Gustavo, always when reposting a new version of a patch that is part

[PATCH v2 2/2] net: netrom: refactor code in nr_add_node

Code refactoring in order to make it easier to read and maintain. Signed-off-by: Gustavo A. R. Silva --- This code was tested by compilation only. Changes in v2: Make use of the swap macro and remove inline keyword. net/netrom/nr_route.c | 59

Re: [PATCH 2/2] net: netrom: refactor code in nr_add_node

Quoting walter harms : Am 20.10.2017 18:06, schrieb Gustavo A. R. Silva: Hi Walter, Quoting walter harms : Am 19.10.2017 19:27, schrieb Gustavo A. R. Silva: Code refactoring in order to make the code easier to read and maintain. Signed-off-by: Gustavo A. R.

Re: [MERGE README] net --> net-next

From: Daniel Borkmann Date: Sun, 22 Oct 2017 21:41:33 +0200 > On 10/22/2017 03:09 PM, Daniel Borkmann wrote: >> On 10/22/2017 02:57 PM, David Miller wrote: >>> >>> There were quite a few BPF conflicts during the merge I just did of >>> 'net' into 'net-next'. >>> >>> In

Re: [PATCH v2 net-next] selftests/bpf: fix broken build of test_maps

From: Alexei Starovoitov Date: Sun, 22 Oct 2017 10:29:06 -0700 > fix multiple build errors and warnings > > 1. > test_maps.c: In function ‘test_map_rdonly’: > test_maps.c:1051:30: error: ‘BPF_F_RDONLY’ undeclared (first use in this > function) > MAP_SIZE, map_flags |

Re: [jkirsher/net-queue PATCH] i40e: Add programming descriptors to cleaned_count

Yes can confirm that after adding patch: [jkirsher/net-queue PATCH] i40e: Add programming descriptors to cleaned_count There is no memleak. W dniu 2017-10-22 o 20:01, Anders K. Pedersen | Cohaesio pisze: On lør, 2017-10-21 at 18:12 -0700, Alexander Duyck wrote: From: Alexander Duyck

Re: [PATCH] net: ethernet: fsl: don't en/disable refclk on open/close

On 10/23/2017 12:48 AM, Florian Fainelli wrote> On 10/22/2017 03:30 PM, Richard Leitner wrote: On 10/22/2017 08:31 PM, Florian Fainelli wrote: On 10/22/2017 06:11 AM, Richard Leitner wrote: ... Andrew Lunn suggested to make the PHY driver a clock driver and let it export the refclk... But

Re: [PATCH] net: ethernet: fsl: don't en/disable refclk on open/close

On 10/22/2017 08:31 PM, Florian Fainelli wrote: On 10/22/2017 06:11 AM, Richard Leitner wrote: From: Richard Leitner From: Richard Leitner Some PHYs (for example the LAN8710) doesn't allow turning the ethernet ref clocks off and on

Re: [PATCH] net: ethernet: fsl: don't en/disable refclk on open/close

On 10/22/2017 03:30 PM, Richard Leitner wrote: > > On 10/22/2017 08:31 PM, Florian Fainelli wrote: >> >> On 10/22/2017 06:11 AM, Richard Leitner wrote: >>> From: Richard Leitner >>> >>> From: Richard Leitner >>> >>> Some PHYs (for

[PATCH v2 32/37] xfrm: Replace hrtimer tasklet with softirq hrtimer

From: Thomas Gleixner Switch the timer to HRTIMER_MODE_SOFT, which executed the timer callback in softirq context and remove the hrtimer_tasklet. Signed-off-by: Thomas Gleixner Signed-off-by: Anna-Maria Gleixner Cc: Steffen

[PATCH v2 37/37] net/mvpp2: Replace tasklet with softirq hrtimer

From: Thomas Gleixner The tx_done_tasklet tasklet is used in invoke the hrtimer (mvpp2_hr_timer_cb) in softirq context. This can be also achieved without the tasklet but with HRTIMER_MODE_SOFT as hrtimer mode. Signed-off-by: Thomas Gleixner

[patch net-next 4/8] mlxsw: spectrum_router: Store weight in nexthop struct

From: Ido Schimmel As the first step towards non-equal-cost multi-path support, store each nexthop's weight. For IPv6 nexthops always set the weight to 1, as it only supports ECMP. Signed-off-by: Ido Schimmel Signed-off-by: Jiri Pirko

[patch net-next 2/8] mlxsw: spectrum: Better represent KVDL partitions

From: Ido Schimmel The KVD linear (KVDL) allocator currently consists of a very large bitmap that reflects the KVDL's usage. The boundaries of each partition as well as their allocation size are represented using defines. This representation requires us to patch all the

[patch net-next 1/8] mlxsw: spectrum_dpipe: Add adjacency group size

From: Ido Schimmel The adjacency group size is part of the match on the adjacency group and should therefore be exposed using dpipe. When non-equal-cost multi-path support will be introduced, the group's size will help users understand the exact number of adjacency entries

[patch net-next 5/8] mlxsw: spectrum_router: Prepare for large adjacency groups

From: Ido Schimmel The device has certain restrictions regarding the size of an adjacency group. Have the router determine the size of the adjacency group according to available KVDL allocation sizes and these restrictions. This was not needed until now since only

[patch net-next 6/8] mlxsw: spectrum_router: Populate adjacency entries according to weights

From: Ido Schimmel Up until now the driver assumed all the nexthops have an equal weight and wrote each to a single adjacency entry. This patch takes the `weight` parameter into account and populates the adjacency group according to the relative weight of each nexthop.

[patch net-next 8/8] mlxsw: spectrum: Add another partition to KVD linear

From: Ido Schimmel The KVD linear is currently partitioned into two partitions. One for single entries and another for groups of 32 entries. Add another partition consisting of groups of 512 entries which will allow us to more accurately represent the nexthop weights in

[patch net-next 3/8] mlxsw: spectrum: Add ability to query KVDL allocation size

From: Ido Schimmel The current KVDL allocation API allows the user to specify the requested number of entries, but the user has no way of knowing how many entries were actually allocated. This works because existing users (e.g., router) request the exact number they end up

[patch net-next 7/8] mlxsw: spectrum: Increase number of linear entries

From: Ido Schimmel The memory region where adjacency entries (nexthops) are stored is called the KVD linear and is configured during initialization with a size of 64K. Extend this area with 32K more entries, that will be partitioned into 64 groups of 0.5K entries, thereby

[patch net-next 0/8] mlxsw: Add support for non-equal-cost multi-path

From: Jiri Pirko Ido says: In the device, nexthops are stored as adjacency entries in an array called the KVD linear (KVDL). When a multi-path route is hit the packet's headers are hashed and then converted to an index into KVDL based on the adjacency group's size and base

RE: [PATCH net-next 00/10] korina cleanups/optimizations

On 2017-10-16 15:59, David Laight wrote: From: Roman Yeryomin Sent: 15 October 2017 17:22 TX optimizations have led to ~15% performance increase (35->40Mbps) in local tx usecase (tested with iperf v3.2). Indicate which patches give the improvement. IIRC some just changed the source without

Re: [PATCH net-next 00/10] korina cleanups/optimizations

On 2017-10-16 00:05, David Miller wrote: From: Roman Yeryomin Date: Sun, 15 Oct 2017 19:46:02 +0300 On 2017-10-15 19:38, Florian Fainelli wrote: On October 15, 2017 9:22:26 AM PDT, Roman Yeryomin wrote: TX optimizations have led to ~15% performance increase

Re: [QUESTION] poor TX performance on new GbE driver

On 22 October 2017 at 20:38, Eric Dumazet wrote: > On Sun, 2017-10-22 at 20:14 +0100, Ard Biesheuvel wrote: >> Hello all, >> >> I am working on upstreaming a network driver for a Socionext SoC, and >> I am having some trouble figuring out why my TX performance is >>

Re: [MERGE README] net --> net-next

On 10/22/2017 03:09 PM, Daniel Borkmann wrote: On 10/22/2017 02:57 PM, David Miller wrote: There were quite a few BPF conflicts during the merge I just did of 'net' into 'net-next'. In particular, all of the packet pointer branch tests in the verifier had to be resolved wrt. three different

Re: [QUESTION] poor TX performance on new GbE driver

On Sun, 2017-10-22 at 20:14 +0100, Ard Biesheuvel wrote: > Hello all, > > I am working on upstreaming a network driver for a Socionext SoC, and > I am having some trouble figuring out why my TX performance is > horrible when booting a Debian Stretch rootfs, while booting a Ubuntu > 17.04 rootfs

Re: [QUESTION] poor TX performance on new GbE driver

On 22 October 2017 at 20:27, Florian Fainelli wrote: > On 10/22/2017 12:14 PM, Ard Biesheuvel wrote: >> Hello all, >> >> I am working on upstreaming a network driver for a Socionext SoC, and >> I am having some trouble figuring out why my TX performance is >> horrible when

[PATCH net] tcp/dccp: fix lockdep splat in inet_csk_route_req()

From: Eric Dumazet This patch fixes the following lockdep splat in inet_csk_route_req() lockdep_rcu_suspicious inet_csk_route_req tcp_v4_send_synack tcp_rtx_synack inet_rtx_syn_ack tcp_fastopen_synack_time tcp_retransmit_timer tcp_write_timer_handler

Re: [QUESTION] poor TX performance on new GbE driver

On 10/22/2017 12:14 PM, Ard Biesheuvel wrote: > Hello all, > > I am working on upstreaming a network driver for a Socionext SoC, and > I am having some trouble figuring out why my TX performance is > horrible when booting a Debian Stretch rootfs, while booting a Ubuntu > 17.04 rootfs works

[QUESTION] poor TX performance on new GbE driver

Hello all, I am working on upstreaming a network driver for a Socionext SoC, and I am having some trouble figuring out why my TX performance is horrible when booting a Debian Stretch rootfs, while booting a Ubuntu 17.04 rootfs works absolutely fine. Note that this is using the exact same kernel

Re: [PATCH] net: ethernet: fsl: don't en/disable refclk on open/close

On 10/22/2017 06:11 AM, Richard Leitner wrote: > From: Richard Leitner > > From: Richard Leitner > > Some PHYs (for example the LAN8710) doesn't allow turning the ethernet > ref clocks off and on again without reset (according to

Re: [jkirsher/net-queue PATCH] i40e: Add programming descriptors to cleaned_count

On lør, 2017-10-21 at 18:12 -0700, Alexander Duyck wrote: > From: Alexander Duyck > > This patch updates the i40e driver to include programming descriptors > in > the cleaned_count. Without this change it becomes possible for us to > leak > memory as we don't trigger

[PATCH v2 net-next] selftests/bpf: fix broken build of test_maps

fix multiple build errors and warnings 1. test_maps.c: In function ‘test_map_rdonly’: test_maps.c:1051:30: error: ‘BPF_F_RDONLY’ undeclared (first use in this function) MAP_SIZE, map_flags | BPF_F_RDONLY); 2. test_maps.c:1048:6: warning: unused variable ‘i’ [-Wunused-variable] int i,

Re: [net-next] tcp: do tcp_mstamp_refresh before retransmits on TSQ handler

On Sun, 2017-10-22 at 09:49 -0700, Eric Dumazet wrote: > Here is the test I cooked. > > Note that it actually passes just fine, do I am wondering if your patch > is needed after all.. > Oh this is because tcp_mstamp_refresh() is called from tcp_write_xmit() and tcp_write_xmit() is directly

Re: [net-next] tcp: do tcp_mstamp_refresh before retransmits on TSQ handler

On Sun, 2017-10-22 at 21:59 +0900, Koichiro Den wrote: > On Sat, 2017-10-21 at 22:21 -0700, Eric Dumazet wrote: > > On Sun, 2017-10-22 at 13:10 +0900, Koichiro Den wrote: > > > On Sat, 2017-10-21 at 20:52 -0700, Eric Dumazet wrote: > > > > On Sun, 2017-10-22 at 12:38 +0900, Koichiro Den wrote: > >

Fwd: bug report: iproute2 policer parsing broken

forgot to cc netdev... cheers, jamal Forwarded Message Subject: bug report: iproute2 policer parsing broken Date: Sun, 22 Oct 2017 10:59:07 -0400 From: Jamal Hadi Salim To: Phil Sutter , Stephen Hemminger , Jiri

[PATCH iproute2 1/1] tc/actions: introduce support for jump action

From: Jamal Hadi Salim Seems like my old patches didnt make it into the tree - so here goes Sample use case: ... add ingress qdisc sudo $TC qdisc add dev $ETH ingress ... if we exceed rate of 1kbps (burst of 90K), do an absolute jump of 2 actions sudo $TC actions add

Re: Linux 4.12+ memory leak on router with i40e NICs

On tor, 2017-10-19 at 08:40 -0700, Alexander Duyck wrote: > On Thu, Oct 19, 2017 at 5:19 AM, Anders K. Pedersen | Cohaesio > wrote: > > Hi Alex, > > > > On ons, 2017-10-18 at 16:37 -0700, Alexander Duyck wrote: > > > When we last talked I had asked if you could do a git bisect

[PATCH] net: ethernet: fsl: don't en/disable refclk on open/close

From: Richard Leitner From: Richard Leitner Some PHYs (for example the LAN8710) doesn't allow turning the ethernet ref clocks off and on again without reset (according to their datasheet). Exactly this behaviour was introduced for power

Re: [MERGE README] net --> net-next

On 10/22/2017 02:57 PM, David Miller wrote: There were quite a few BPF conflicts during the merge I just did of 'net' into 'net-next'. In particular, all of the packet pointer branch tests in the verifier had to be resolved wrt. three different sets of changes. The off-by-one stuff. The

Re: [net-next] tcp: do tcp_mstamp_refresh before retransmits on TSQ handler

On Sat, 2017-10-21 at 22:21 -0700, Eric Dumazet wrote: > On Sun, 2017-10-22 at 13:10 +0900, Koichiro Den wrote: > > On Sat, 2017-10-21 at 20:52 -0700, Eric Dumazet wrote: > > > On Sun, 2017-10-22 at 12:38 +0900, Koichiro Den wrote: > > > > When retransmission on TSQ handler was introduced in the

[MERGE README] net --> net-next

There were quite a few BPF conflicts during the merge I just did of 'net' into 'net-next'. In particular, all of the packet pointer branch tests in the verifier had to be resolved wrt. three different sets of changes. The off-by-one stuff. The allowance of the 'data_end > ptr + x' form of

Re: [PATCH RFC] Add Microchip KSZ8895 DSA driver

Hi! > diff --git a/drivers/net/dsa/microchip/Kconfig > b/drivers/net/dsa/microchip/Kconfig > index cb95d3d..b854c4b 100644 > --- a/drivers/net/dsa/microchip/Kconfig > +++ b/drivers/net/dsa/microchip/Kconfig > @@ -27,3 +27,20 @@ config MICROCHIP_KSZ8795_SPI_DRIVER > > It is required to

Re: [PATCH 1/2] slab, slub, slob: add slab_flags_t

On 21/10/2017 13.02, Alexey Dobriyan wrote: Add sparse-checked slab_flags_t for struct kmem_cache::flags (SLAB_POISON, etc). SLAB is bloated temporarily by switching to "unsigned long", but only temporarily. Signed-off-by: Alexey Dobriyan Acked-by: Pekka Enberg

Re: [PATCH 2/2] slab, slub, slob: convert slab_flags_t to 32-bit

On 21/10/2017 13.06, Alexey Dobriyan wrote: struct kmem_cache::flags is "unsigned long" which is unnecessary on 64-bit as no flags are defined in the higher bits. Switch the field to 32-bit and save some space on x86_64 until such flags appear: add/remove: 0/0 grow/shrink: 0/107