bond: take rcu lock in netpoll_send_skb_on_dev

layer up in netpoll_send_skb_on_dev before we call down into netpoll_poll_dev, so just take the lock there. Suggested-by: Cong Wang Signed-off-by: Dave Jones diff --git a/net/core/netpoll.c b/net/core/netpoll.c index 3219a2932463..692367d7c280 100644 --- a/net/core/netpoll.c +++ b/net/core/netpoll.c @@ -330

Re: bond: take rcu lock in bond_poll_controller

On Fri, Sep 28, 2018 at 12:03:22PM -0700, Cong Wang wrote: > On Fri, Sep 28, 2018 at 12:02 PM Cong Wang wrote: > > > > On Fri, Sep 28, 2018 at 11:26 AM Dave Jones > > wrote: > > > diff --git a/net/core/netpoll.c b/net/core/netpoll.c > > >

bond: take rcu lock in bond_poll_controller

1fc/0x310 bond_mii_monitor+0x709/0x9b0 process_one_work+0x221/0x5e0 worker_thread+0x4f/0x3b0 kthread+0x100/0x140 ? process_one_work+0x5e0/0x5e0 ? kthread_delayed_work_timer_fn+0x90/0x90 ret_from_fork+0x24/0x30 Suggested-by: Cong Wang Signed-off-by: Dave Jones -- v3: Do this in netpoll_send_skb_on_de

Re: bond: take rcu lock in bond_poll_controller

On Fri, Sep 28, 2018 at 10:31:39AM -0700, Cong Wang wrote: > On Fri, Sep 28, 2018 at 10:25 AM Dave Jones wrote: > > > > On Fri, Sep 28, 2018 at 09:55:52AM -0700, Cong Wang wrote: > > > On Fri, Sep 28, 2018 at 9:18 AM Dave Jones > > wrot

Re: bond: take rcu lock in bond_poll_controller

On Fri, Sep 28, 2018 at 09:55:52AM -0700, Cong Wang wrote: > On Fri, Sep 28, 2018 at 9:18 AM Dave Jones wrote: > > > > Callers of bond_for_each_slave_rcu are expected to hold the rcu lock, > > otherwise a trace like below is shown > > So

bond: take rcu lock in bond_poll_controller

1fc/0x310 bond_mii_monitor+0x709/0x9b0 process_one_work+0x221/0x5e0 worker_thread+0x4f/0x3b0 kthread+0x100/0x140 ? process_one_work+0x5e0/0x5e0 ? kthread_delayed_work_timer_fn+0x90/0x90 ret_from_fork+0x24/0x30 Signed-off-by: Dave Jones diff --git a/drivers/net/bonding/bond_main.c b/drivers/ne

bond: take rcu lock in bond_poll_controller

1fc/0x310 bond_mii_monitor+0x709/0x9b0 process_one_work+0x221/0x5e0 worker_thread+0x4f/0x3b0 kthread+0x100/0x140 ? process_one_work+0x5e0/0x5e0 ? kthread_delayed_work_timer_fn+0x90/0x90 ret_from_fork+0x24/0x30 Signed-off-by: Dave Jones diff --git a/drivers/net/bonding/bond_main.c b/drivers/ne

ipset: suspicious RCU usage

= WARNING: suspicious RCU usage 4.16.0-rc3-firewall+ #1 Not tainted - net/netfilter/ipset/ip_set_core.c:1354 suspicious rcu_dereference_protected() usage! \x0aother info that might help us debug this:\x0a \x0arcu_scheduler_active = 2,

[no subject]

This is in regards to an inheritance on your surname, reply back using your email address, stating your full name for more details. Reply to email for info. Email me here ( ger...@dr.com )

Re: [4.15-rc9] fs_reclaim lockdep trace

+0900 > Subject: [PATCH] lockdep: Fix fs_reclaim warning. Seems to suppress the warning for me. Tested-by: Dave Jones <da...@codemonkey.org.uk>

Re: [4.15-rc9] fs_reclaim lockdep trace

On Tue, Jan 23, 2018 at 08:36:51PM -0500, Dave Jones wrote: > Just triggered this on a server I was rsync'ing to. Actually, I can trigger this really easily, even with an rsync from one disk to another. Though that also smells a little like networking in the traces. Maybe netdev has id

ipset related DEBUG_VIRTUAL crash.

I have a script that hourly replaces an ipset list. This has been in place for a year or so, but last night it triggered this on 4.14-rc7 [455951.731181] kernel BUG at arch/x86/mm/physaddr.c:26! [455951.737016] invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN [455951.742525] CPU: 0

Re: [4.14rc6] __tcp_select_window divide by zero.

On Tue, Oct 24, 2017 at 09:00:30AM -0400, Dave Jones wrote: > divide error: [#1] SMP KASAN > CPU: 0 PID: 31140 Comm: trinity-c12 Not tainted 4.14.0-rc6-think+ #1 > RIP: 0010:__tcp_select_window+0x21f/0x400 > Call Trace: > tcp_cleanup_rbuf+0x27d/0x2a0 > tcp_re

[net-next] tcp_delack_timer circular locking dependancy

[ 105.316650] == [ 105.316818] WARNING: possible circular locking dependency detected [ 105.316986] 4.14.0-rc7-think+ #1 Not tainted [ 105.317108] -- [ 105.317273] swapper/2/0 is trying to

[4.14rc6] __tcp_select_window divide by zero.

divide error: [#1] SMP KASAN CPU: 0 PID: 31140 Comm: trinity-c12 Not tainted 4.14.0-rc6-think+ #1 task: 8803c0d08040 task.stack: 8803df548000 RIP: 0010:__tcp_select_window+0x21f/0x400 RSP: 0018:8803df54f418 EFLAGS: 00010246 RAX: RBX: 880458fd3140 RCX:

Stuck TX Using Iperf

no longer able to reproduce the stuck TX queue until reboot. I receive no kernel driver messages of any sort during my iperf test, it just stalls until I kill it. Any help would be appreciated. Regards, Robert Jones - Software Engineer Gateworks Corporation

BUG_ON(sg->sg_magic != SG_MAGIC) on tls socket.

kernel BUG at ./include/linux/scatterlist.h:189! invalid opcode: [#1] SMP KASAN CPU: 3 PID: 20890 Comm: trinity-c51 Not tainted 4.13.0-rc4-think+ #5 task: 88036e3d1cc0 task.stack: 88033e9d8000 RIP: 0010:tls_push_record+0x675/0x680 RSP: 0018:88033e9df630 EFLAGS: 00010287 RAX:

KASAN: slab-out-of-bounds from net_namespace.c:ops_init

== BUG: KASAN: slab-out-of-bounds in ops_init+0x201/0x330 Write of size 8 at addr 88045744c448 by task trinity-c4/1499 CPU: 2 PID: 1499 Comm: trinity-c4 Not tainted 4.13.0-rc4-think+ #5 Call Trace: dump_stack+0xc5/0x151 ?

Re: sctp refcount bug.

On Thu, Jul 13, 2017 at 11:38:34AM -0300, Marcelo Ricardo Leitner wrote: > On Thu, Jul 13, 2017 at 10:36:39AM -0400, Dave Jones wrote: > > Hit this on Linus' current tree. > > > > > > refcount_t: underflow; use-after-free. > > Any tips on how to reproduc

sctp refcount bug.

Hit this on Linus' current tree. refcount_t: underflow; use-after-free. [ cut here ] WARNING: CPU: 2 PID: 14455 at lib/refcount.c:186 refcount_sub_and_test+0x45/0x50 CPU: 2 PID: 14455 Comm: trinity-c46 Tainted: G D 4.12.0-think+ #11 task: 8804fc71b8c0

netconsole refcount warning

The new refcount debugging code spews this twice during boot on my router.. refcount_t: increment on 0; use-after-free. [ cut here ] WARNING: CPU: 1 PID: 17 at lib/refcount.c:152 refcount_inc+0x2b/0x30 CPU: 1 PID: 17 Comm: ksoftirqd/1 Not tainted 4.12.0-firewall+ #8

Your first payment of $5000 ,

Attn Beneficiary, We have deposited the check of your fund ($2.5m USD) through western union money transfer department after our finally meeting today regarding your fund, Now all you will do is to contact western union director Mis Rose Kelly ,And She will give you the direction on how you

Re: [PATCH v2 1/3] mfd: max8998: Remove CONFIG_OF around max8998_dt_match

le available. > > Signed-off-by: Florian Fainelli <f.faine...@gmail.com> > --- > drivers/mfd/max8998.c | 2 -- > 1 file changed, 2 deletions(-) If it works, great! For my own reference: Acked-for-MFD-by: Lee Jones <lee.jo...@linaro.org> > diff --git a/drivers/mfd

Re: af_packet: use after free in prb_retire_rx_blk_timer_expired

On Mon, Apr 10, 2017 at 07:03:30PM +, alexander.le...@verizon.com wrote: > Hi all, > > I seem to be hitting this use-after-free on a -next kernel using trinity: > > [ 531.036054] BUG: KASAN: use-after-free in prb_retire_rx_blk_timer_expired > (net/packet/af_packet.c:688)

Re: [PATCH V8 1/3] irq: Add flags to request_percpu_irq function

On Thu, Mar 23, 2017 at 06:42:01PM +0100, Daniel Lezcano wrote: > diff --git a/drivers/clocksource/timer-nps.c b/drivers/clocksource/timer-nps.c > index da1f798..dbdb622 100644 > --- a/drivers/clocksource/timer-nps.c > +++ b/drivers/clocksource/timer-nps.c > @@ -256,7 +256,7 @@ static int __init

Re: run_timer_softirq gpf. [smc]

On Tue, Mar 21, 2017 at 08:25:39PM +0100, Thomas Gleixner wrote: > > I just hit this while fuzzing.. > > > > general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC > > CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.11.0-rc2-think+ #1 > > task: 88017f0ed440 task.stack:

Re: [4.10+] sctp lockdep trace

On Tue, Mar 14, 2017 at 11:35:33AM +0800, Xin Long wrote: > >> > [ 245.416594] ( > >> > [ 245.424928] sk_lock-AF_INET > >> > [ 245.433279] ){+.+.+.} > >> > [ 245.441889] , at: [] sctp_sendmsg+0x330/0xfe0 > >> > [sctp] > >> > [ 245.450167] > >> >stack backtrace: > >>

[4.10+] sctp lockdep trace

[ 244.251557] === [ 244.263321] [ ERR: suspicious RCU usage. ] [ 244.274982] 4.10.0-think+ #7 Not tainted [ 244.286511] --- [ 244.298008] ./include/linux/rhashtable.h:602 suspicious rcu_dereference_check() usage! [ 244.309665]

Re: [PATCH v2 net-next] liquidio: improve UDP TX performance

+0.1 | +++++-+ Some good looking numbers there. As one approaches the wire limit for bitrate, the likes of a netperf service demand can be used to demonstrate the performance change - though there isn't an easy way to do that for parallel flows. happy benchmarking, rick jones

Re: [PATCH net-next] liquidio: improve UDP TX performance

cation per ring By how much was UDP TX performance improved? happy benchmarking, rick jones

Re: [PATCH net-next] virtio: Fix affinity for >32 VCPUs

defaults. For example, the issues we've seen with VMs sending traffic getting reordered when the driver took it upon itself to enable xps. rick jones

Re: [PATCH net-next] virtio: Fix affinity for >32 VCPUs

On 02/03/2017 10:22 AM, Benjamin Serebrin wrote: Thanks, Michael, I'll put this text in the commit log: XPS settings aren't write-able from userspace, so the only way I know to fix XPS is in the driver. ?? root@np-cp1-c0-m1-mgmt:/home/stack# cat

prb_retire_rx_blk_timer_expired use-after-free

RSI looks kinda like slab poison here, so re-using a free'd ptr ? general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.0-rc4-think+ #2 task: 81e16500 task.stack: 81e0 RIP:

Re: [PATCH net-next] tcp: accept RST for rcv_nxt - 1 after receiving a FIN

On 01/17/2017 11:13 AM, Eric Dumazet wrote: On Tue, Jan 17, 2017 at 11:04 AM, Rick Jones <rick.jon...@hpe.com> wrote: Drifting a bit, and it doesn't change the value of dealing with it, but out of curiosity, when you say mostly in CLOSE_WAIT, why aren't the server-side applications re

Re: [PATCH net-next] tcp: accept RST for rcv_nxt - 1 after receiving a FIN

mostly in CLOSE_WAIT, why aren't the server-side applications reacting to the read return of zero triggered by the arrival of the FIN? happy benchmarking, rick jones

Re: [pull request][for-next] Mellanox mlx5 Reorganize core driver directory layout

. Straight-up defaults with netperf, or do you use specific -s/S or -m/M options? happy benchmarking, rick jones

ipv6: remove unnecessary inet6_sk check

np is already assigned in the variable declaration of ping_v6_sendmsg. At this point, we have already dereferenced np several times, so the NULL check is also redundant. Suggested-by: Eric Dumazet <eric.duma...@gmail.com> Signed-off-by: Dave Jones <da...@codemonkey.org.uk> diff --gi

sunrpc: Illegal context switch in RCU read-side critical section!

Just noticed this on 4.9. Will try and repro on 4.10rc1 later, but hitting unrelated boot problems on that machine right now. === [ INFO: suspicious RCU usage. ] 4.9.0-backup-debug+ #1 Not tainted --- ./include/linux/rcupdate.h:557 Illegal

ipv6: handle -EFAULT from skb_copy_bits

); setsockopt(fd, SOL_IPV6, IPV6_DSTOPTS, , LEN); sendto(fd, buf, 1, 0, (struct sockaddr *) buf, 110); } Signed-off-by: Dave Jones <da...@codemonkey.org.uk> diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c index 291ebc260e70..ea89073c8247 100644 --- a/net/ipv6/raw.c +++ b/net/ipv6/raw.c @@

Re: ipv6: handle -EFAULT from skb_copy_bits

On Wed, Dec 21, 2016 at 10:33:20PM +0100, Hannes Frederic Sowa wrote: > > Given all of this, I think the best thing to do is validate the offset > > after the queue walks, which is pretty much what Dave Jones's original > > patch was doing. > > I think both approaches protect against the

Re: ipv6: handle -EFAULT from skb_copy_bits

On Tue, Dec 20, 2016 at 11:31:38AM -0800, Cong Wang wrote: > On Tue, Dec 20, 2016 at 10:17 AM, Dave Jones <da...@codemonkey.org.uk> wrote: > > On Mon, Dec 19, 2016 at 08:36:23PM -0500, David Miller wrote: > > > From: Dave Jones <da...@codemonkey.org.uk> > >

Re: ipv6: handle -EFAULT from skb_copy_bits

On Tue, Dec 20, 2016 at 01:28:13PM -0500, David Miller wrote: > This has to do with the SKB buffer layout and geometry, not whether > the packet is "fragmented" in the protocol sense. > > So no, this isn't a criteria for packets being filtered out by this > point. > > Can you try to

Re: ipv6: handle -EFAULT from skb_copy_bits

On Mon, Dec 19, 2016 at 08:36:23PM -0500, David Miller wrote: > From: Dave Jones <da...@codemonkey.org.uk> > Date: Mon, 19 Dec 2016 19:40:13 -0500 > > > On Mon, Dec 19, 2016 at 07:31:44PM -0500, Dave Jones wrote: > > > > > Unfortunately, this made no

Re: [PATCH 1/3] NFC: trf7970a: add device tree option for 27MHz clock

On 2016-12-20 17:16, Geoff Lansberry wrote: > From: Geoff Lansberry > > The TRF7970A has configuration options to support hardware designs > which use a 27.12MHz clock. This commit adds a device tree option > 'clock-frequency' to support configuring the this chip for default >

Re: ipv6: handle -EFAULT from skb_copy_bits

On Mon, Dec 19, 2016 at 07:31:44PM -0500, Dave Jones wrote: > Unfortunately, this made no difference. I spent some time today trying > to make a better reproducer, but failed. I'll revisit again tomorrow. > > Maybe I need >1 process/thread to trigger this. That would expla

Re: ipv6: handle -EFAULT from skb_copy_bits

On Mon, Dec 19, 2016 at 02:48:48PM -0500, David Miller wrote: > One thing that's interesting is that if the user picks "IPPROTO_RAW" > as the value of 'protocol' we set inet->hdrincl to 1. > > The user can also set inet->hdrincl to 1 or 0 via setsockopt(). > > I think this is part of the

Re: ipv6: handle -EFAULT from skb_copy_bits

50 > > [] SYSC_sendto+0xef/0x170 > > [] SyS_sendto+0xe/0x10 > > [] do_syscall_64+0x50/0xa0 > > [] entry_SYSCALL64_slow_path+0x25/0x25 > > > > Handle this in rawv6_push_pending_frames and jump to the failure path. > > > >

Re: ipv6: handle -EFAULT from skb_copy_bits

On Sat, Dec 17, 2016 at 10:41:20AM -0500, David Miller wrote: > From: Dave Jones <da...@codemonkey.org.uk> > Date: Wed, 14 Dec 2016 10:47:29 -0500 > > > It seems to be possible to craft a packet for sendmsg that triggers > > the -EFAULT path in skb_copy_bits resul

ipv6: handle -EFAULT from skb_copy_bits

+0x693/0x830 [] inet_sendmsg+0x67/0xa0 [] sock_sendmsg+0x38/0x50 [] SYSC_sendto+0xef/0x170 [] SyS_sendto+0xe/0x10 [] do_syscall_64+0x50/0xa0 [] entry_SYSCALL64_slow_path+0x25/0x25 Handle this in rawv6_push_pending_frames and jump to the failure path. Signed-off-by: Dave Jones <

netconsole: sleeping function called from invalid context

I think this has been around for a while, but for some reason I'm running into it a lot today. BUG: sleeping function called from invalid context at kernel/irq/manage.c:110 in_atomic(): 1, irqs_disabled(): 1, pid: 1839, name: modprobe no locks held by modprobe/1839. Preemption disabled at: []

Re: [PATCH net-next] udp: under rx pressure, try to condense skbs

lly, even under no stress at all, you really should complain then. Isn't that behaviour based (in part?) on the observation/belief that it is fewer cycles to copy the small packet into a small buffer than to send the larger buffer up the stack and have to allocate and map a replacement? rick jones

Re: [PATCH net-next 2/4] mlx4: xdp: Allow raising MTU up to one page minus eth and vlan hdrs

- (2 * VLAN_HLEN) which this patch is doing. It will be useful in the next patch which allows XDP program to extend the packet by adding new header(s). Is mlx4 the only driver doing page-per-packet? rick jones

Re: Initial thoughts on TXDP

On 12/01/2016 02:12 PM, Tom Herbert wrote: We have consider both request size and response side in RPC. Presumably, something like a memcache server is most serving data as opposed to reading it, we are looking to receiving much smaller packets than being sent. Requests are going to be quite

Re: Initial thoughts on TXDP

On 12/01/2016 12:18 PM, Tom Herbert wrote: On Thu, Dec 1, 2016 at 11:48 AM, Rick Jones <rick.jon...@hpe.com> wrote: Just how much per-packet path-length are you thinking will go away under the likes of TXDP? It is admittedly "just" netperf but losing TSO/GSO does some no

Re: Initial thoughts on TXDP

ne does have the CPU cycles to burn so to speak, the effect on power consumption needs to be included in the calculus. happy benchmarking, rick jones

Re: Netperf UDP issue with connected sockets

On 11/30/2016 02:43 AM, Jesper Dangaard Brouer wrote: Notice the "fib_lookup" cost is still present, even when I use option "-- -n -N" to create a connected socket. As Eric taught us, this is because we should use syscalls "send" or "write" on a connected socket. In theory, once the data

Re: Netperf UDP issue with connected sockets

On 11/28/2016 10:33 AM, Rick Jones wrote: On 11/17/2016 12:16 AM, Jesper Dangaard Brouer wrote: time to try IP_MTU_DISCOVER ;) To Rick, maybe you can find a good solution or option with Eric's hint, to send appropriate sized UDP packets with Don't Fragment (DF). Jesper - Top of trunk has

Re: Netperf UDP issue with connected sockets

On 11/17/2016 12:16 AM, Jesper Dangaard Brouer wrote: time to try IP_MTU_DISCOVER ;) To Rick, maybe you can find a good solution or option with Eric's hint, to send appropriate sized UDP packets with Don't Fragment (DF). Jesper - Top of trunk has a change adding an omni, test-specific -f

Re: Netperf UDP issue with connected sockets

On 11/17/2016 04:37 PM, Julian Anastasov wrote: On Thu, 17 Nov 2016, Rick Jones wrote: raj@tardy:~/netperf2_trunk$ strace -v -o /tmp/netperf.strace src/netperf -F src/nettest_omni.c -t UDP_STREAM -l 1 -- -m 1472 ... socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4 getsockopt(4, SOL_SOCKET

Re: Netperf UDP issue with connected sockets

ges from the send_ring over and over instead of putting different data into the buffers each time, but if one has a sufficiently large -W option specified... happy benchmarking, rick jones

Re: Netperf UDP issue with connected sockets

wouldn't be too difficult, along with another command-line option to cause it to happen. Could we leave things as "make sure you don't need fragmentation when you use this" or would netperf have to start processing ICMP messages? happy benchmarking, rick jones

Re: Netperf UDP issue with connected sockets

On 11/16/2016 02:40 PM, Jesper Dangaard Brouer wrote: On Wed, 16 Nov 2016 09:46:37 -0800 Rick Jones <rick.jon...@hpe.com> wrote: It is a wild guess, but does setting SO_DONTROUTE affect whether or not a connect() would have the desired effect? That is there to protect people from them

Re: Netperf UDP issue with connected sockets

f netperf users on Windows and there wasn't (at the time) support for git under Windows. But I am not against the idea in principle. happy benchmarking, rick jones PS - rick.jo...@hp.com no longer works. rick.jon...@hpe.com should be used instead.

Re: [patch] netlink.7: srcfix Change buffer size in example code about reading netlink message.

oblems on platforms with a large PAGE_SIZE? /* avoid msg truncation on > 4096 byte PAGE_SIZE platforms */ or something like that. rick jones

Re: [PATCH RFC 0/2] ethtool: Add actual port speed reporting

can, while "back in the day" (when some of the first ethtool changes to report speeds other than the "normal" ones went in) the speed of a flexnic was fixed, today, it can actually operate in a range. From a minimum guarantee to an "if there is bandwidth available" cap. rick jones

Re: [bnx2] [Regression 4.8] Driver loading fails without firmware

On 10/25/2016 08:31 AM, Paul Menzel wrote: To my knowledge, the firmware files haven’t changed since years [1]. Indeed - it looks like I read "bnx2" and thought "bnx2x" Must remember to hold-off on replying until after the morning orange juice is consumed :) rick

Re: [bnx2] [Regression 4.8] Driver loading fails without firmware

version of the firmware. Usually, finding a package "out there" with the newer version of the firmware, and installing it onto the system is sufficient. happy benchmarking, rick jones

Re: Accelerated receive flow steering (aRFS) for UDP

On 10/10/2016 09:08 AM, Rick Jones wrote: On 10/09/2016 03:33 PM, Eric Dumazet wrote: OK, I am adding/CC Rick Jones, netperf author, since it seems a netperf bug, not a kernel one. I believe I already mentioned fact that "UDP_STREAM -- -N" was not doing a connect() on the receiver

Re: Accelerated receive flow steering (aRFS) for UDP

On 10/09/2016 03:33 PM, Eric Dumazet wrote: OK, I am adding/CC Rick Jones, netperf author, since it seems a netperf bug, not a kernel one. I believe I already mentioned fact that "UDP_STREAM -- -N" was not doing a connect() on the receiver side. I can confirm that the re

Re: [PATCH v2 net-next 4/5] xps_flows: XPS for packets that don't have a socket

is currently selecting different TXQ. Just for completeness, in my testing, the VMs were single-vCPU. rick jones

Re: [PATCH RFC 0/4] xfs: Transmit flow steering

ro,E5-2670v3 12421 12612 BE3, E5-26408178 8484 82599, E5-2640 8499 8549 BCM57840, E5-2640 8544 8560 Skyhawk, E5-26408537 8701 happy benchmarking, Drew Balliet Jeurg Haefliger rick jones The

Re: [PATCH v3 net-next 16/16] tcp_bbr: add BBR congestion control

happy benchmarking, rick jones

I hope this email meets you well in good health condition

How you doing today? I hope you are doing well. My name is Jones, from the US. I'm in Syria right now fighting ISIS. I want to get to know you better, if I may be so bold. I consider myself an easy-going man, and I am currently looking for a relationship in which I feel loved. Please tell me

Re: [PATCH next 3/3] ipvlan: Introduce l3s mode

-tracking work. What is that first sentence trying to say? It appears to be incomplete, and is that supposed to be "L3-symmetric?" happy benchmarking, rick jones

Re: [PATCH RFC 11/11] net/mlx5e: XDP TX xmit more

hat can be used to create a bulk of packets to send with one doorbell. With small packets and the "default" ring size for this NIC/driver combination, is the BQL large enough that the ring fills before one hits the BQL? rick jones

Re: ipv6: release dst in ping_v6_sendmsg

On Tue, Sep 06, 2016 at 10:52:43AM -0700, Eric Dumazet wrote: > > > @@ -126,8 +126,10 @@ static int ping_v6_sendmsg(struct sock *sk, struct > > > msghdr *msg, size_t len) > > > rt = (struct rt6_info *) dst; > > > > > > np = inet6_sk(sk); > > > -if (!np) > > > -

ipv6: release dst in ping_v6_sendmsg

been fixed post 3.10, but it seems at least one case wasn't, where I've seen this triggered a lot from machines doing unprivileged icmp sockets. Cc: Martin Lau <ka...@fb.com> Signed-off-by: Dave Jones <da...@codemonkey.org.uk> diff --git a/net/ipv6/ping.c b/net/ipv6/ping.c index 0900

Re: [PATCH] softirq: let ksoftirqd do its job

On 08/31/2016 04:11 PM, Eric Dumazet wrote: On Wed, 2016-08-31 at 15:47 -0700, Rick Jones wrote: With regard to drops, are both of you sure you're using the same socket buffer sizes? Does it really matter ? At least at points in the past I have seen different drop counts at the SO_RCVBUF

Re: [PATCH] softirq: let ksoftirqd do its job

With regard to drops, are both of you sure you're using the same socket buffer sizes? In the meantime, is anything interesting happening with TCP_RR or TCP_STREAM? happy benchmarking, rick jones

Re: [PATCH v2 net-next] documentation: Document issues with VMs and XPS and drivers enabling it on their own

nue to exist in parallel a la RPS and RFS? rick jones

[PATCH v2 net-next] documentation: Document issues with VMs and XPS and drivers enabling it on their own

From: Rick Jones <rick.jon...@hpe.com> Since XPS was first introduced two things have happened. Some drivers have started enabling XPS on their own initiative, and it has been found that when a VM is sending data through a host interface with XPS enabled, that traffic can end-up serious

[PATCH net-next] documentation: Document issues with VMs and XPS and drivers enabling it on their own

From: Rick Jones <rick.jon...@hpe.com> Since XPS was first introduced two things have happened. Some drivers have started enabling XPS on their own initiative, and it has been found that when a VM is sending data through a host interface with XPS enabled, that traffic can end-up serious

Re: [RFC PATCH] net: Require socket to allow XPS to set queue mapping

On 08/25/2016 02:08 PM, Eric Dumazet wrote: When XPS was submitted, it was _not_ enabled by default and 'magic' Some NIC vendors decided it was a good thing, you should complain to them ;) I kindasorta am with the emails I've been sending to netdev :) And also hopefully precluding others

Re: [RFC PATCH] net: Require socket to allow XPS to set queue mapping

to pin VMs can enable XPS in that case. It isn't clear that one should always pin VMs - for example if a (public) cloud needed to oversubscribe the cores. happy benchmarking, rick jones

Re: A second case of XPS considerably reducing single-stream performance

On 08/25/2016 12:19 PM, Alexander Duyck wrote: The problem is that there is no socket associated with the guest from the host's perspective. This is resulting in the traffic bouncing between queues because there is no saved socket to lock the interface onto. I was looking into this recently

Re: A second case of XPS considerably reducing single-stream performance

jones

Re: [PATCH net-next] net: minor optimization in qdisc_qstats_cpu_drop()

On 08/24/2016 10:23 AM, Eric Dumazet wrote: From: Eric Dumazet <eduma...@google.com> per_cpu_inc() is faster (at least on x86) than per_cpu_ptr(xxx)++; Is it possible it is non-trivially slower on other architectures? rick jones Signed-off-by: Eric Dumazet <eduma...@g

A second case of XPS considerably reducing single-stream performance

Average 4108 8940 8859 8885 8671 happy benchmarking, rick jones The sample counts below may not fully support the additional statistics but for the curious: raj@tardy:/tmp$ ~/netperf2_trunk/doc/examples/parse_single_stream.py -r 6 waxon_performance.log -f 2

e1000: __pskb_pull_tail failed

MY NFS server running 4.8-rc1 is getting flooded with this message: e1000e :00:19.0 eth0: __pskb_pull_tail failed. Never saw it happen with 4.7 or earlier. That device is this onboard NIC: 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (2) I218-V Dave

Re: [PATCH net 1/2] tg3: Fix for diasllow rx coalescing time to be 0

of code? The logic there seems to suggest that it was intended to be able to have an rx_coalesce_usecs of 0 and rely on packet arrival to trigger an interrupt. Presumably setting rx_max_coalesced_frames to 1 to disable interrupt coalescing. happy benchmarking, rick jones

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

tly? I believe Phil posted something several messages back in the thread. happy benchmarking, rick jones

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

On 07/07/2016 09:34 AM, Eric W. Biederman wrote: Rick Jones <rick.jon...@hpe.com> writes: 300 routers is far from the upper limit/goal. Back in HP Public Cloud, we were running as many as 700 routers per network node (*), and more than four network nodes. (back then it was just t

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

espace per router and network). Mileage will of course vary based on the "oomph" of one's network node(s). happy benchmarking, rick jones * Didn't want to go much higher than that because each router had a port on a common linux bridge and getting to > 1024 would be an unpleasant day.

Re: strange Mac OSX RST behavior

it takes up server resources for sockets sitting in TCP_CLOSE_WAIT. Isn't the server application expected to act on the read return of zero (which is supposed to be) triggered by the receipt of the FIN segment? rick jones We are also in the process of contacting Apple to see what can be done

Re: [PATCH v12 net-next 1/1] hv_sock: introduce Hyper-V Sockets

tion which has been reset? Is it limited to those errno values listed in the read() manpage, or does it end-up getting an errno value from those listed in the recv() manpage? Or, perhaps even one not (presently) listed in either? rick jones

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

productively use TCP FastOpen. "Overall, very good success-rate" though tempered by "But... middleboxes were a big issue in some ISPs..." Though it doesn't get into how big (some connections, many, most, all?) and how many ISPs. rick jones Just an anecdote... Not that I am a "

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On 06/24/2016 02:46 PM, Tom Herbert wrote: On Fri, Jun 24, 2016 at 2:36 PM, Rick Jones <rick.jon...@hpe.com> wrote: How would you define "severely?" Has it actually been more severe than for say ECN? Or it was for say SACK or PAWS? ECN is probably even a bigger disappo

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

YN packets with data have together severely hindered what otherwise should have been straightforward and useful feature to deploy. How would you define "severely?" Has it actually been more severe than for say ECN? Or it was for say SACK or PAWS? rick jones

[4.6] kernel BUG at net/ipv6/raw.c:592

Found this logs after a Trinity run. kernel BUG at net/ipv6/raw.c:592! [ cut here ] invalid opcode: [#1] SMP Modules linked in: udp_diag dccp_ipv6 dccp_ipv4 dccp sctp af_key tcp_diag inet_diag ip6table_filter xt_NFLOG nfnetlink_log xt_comment xt_statistic

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On 06/22/2016 04:10 PM, Rick Jones wrote: My systems are presently in the midst of an install but I should be able to demonstrate it in the morning (US Pacific time, modulo the shuttle service of a car repair place) The installs finished sooner than I thought. So, receiver: root@np-cp1

  1   2   3   4   5   6   7   >