Re: [PATCH][net-next] bridge: increase mtu to 9000

/ #define BR_GROUPFWD_DEFAULT 0 /* Don't allow forwarding of control protocols like STP, MAC PAUSE and LACP */ If you are going to 9000. why not just go ahead and use the maximum size of an IP datagram? rick jones

Re: [PATCH net V1 1/6] net/mlx4_en: Count HW buffer overrun only once

accounting to show wrong results. Fix that. Use it for rx_fifo_errors only. Fixes: c27a02cd94d6 ('mlx4_en: Add driver for Mellanox ConnectX 10GbE NIC') Signed-off-by: Amir Vadai Signed-off-by: Eugenia Emantayev Signed-off-by: Or Gerlitz Reviewed-By: Rick Jones rick

Re: [PATCH net 1/6] net/mlx4_en: Do not count dropped packets twice

ors = 0; stats->rx_fifo_errors = be32_to_cpu(mlx4_en_stats->RdropOvflw); happy benchmarking, rick jones

Re: gro: Make GRO aware of lightweight tunnels.

On Tue, Feb 02, 2016 at 02:28:58AM +, Linux Kernel wrote: > Web: > https://git.kernel.org/torvalds/c/ce87fc6ce3f9f4488546187e3757cf666d9d4a2a > Commit: ce87fc6ce3f9f4488546187e3757cf666d9d4a2a > Parent: 5f2f3cad8b878b23f17a11dd5af4f4a2cc41c797 > Refname:refs/heads/maste

Re: Disabling XPS for 4.4.0-1+ixgbe+OpenStack VM over a VLAN means 65% increase in netperf TCP_STREAM

sd 20.5931 stack@fcperf-cp1-comp0001-mgmt:~$ grep "1 1" xps_tcp_rr_off_* | awk '{t+=$6;r+=$9;s+=$10}END{print "throughput",t/NR,"recv sd",r/NR,"send sd",s/NR}' throughput 20883.6 recv sd 19.6255 send sd 20.0178 So that is 12% on TCP_RR throughput. Looks like XPS shouldn't be enabled by default for ixgbe. happy benchmarking, rick jones

Re: Disabling XPS for 4.4.0-1+ixgbe+OpenStack VM over a VLAN means 65% increase in netperf TCP_STREAM

sd 0.6543 send sd 0.3606 stack@fcperf-cp1-comp0001-mgmt:~$ grep TCPOFO xps_off_* | awk '{sum += $NF}END{print "sum",sum/NR}' sum 173.9 happy benchmarking, rick jones raw results at ftp://ftp.netperf.org/xps_4.4.0-1_ixgbe.tgz

Re: Disabling XPS for 4.4.0-1+ixgbe+OpenStack VM over a VLAN means 65% increase in netperf TCP_STREAM

On 02/04/2016 12:13 PM, Tom Herbert wrote: On Thu, Feb 4, 2016 at 11:57 AM, Rick Jones wrote: On 02/04/2016 11:38 AM, Tom Herbert wrote: XPS has OOO avoidance for TCP, that should not be a problem. What/how much should I read into: With XPSTCPOFOQueue: 78206 Without XPS TCPOFOQueue

Re: Disabling XPS for 4.4.0-1+ixgbe+OpenStack VM over a VLAN means 65% increase in netperf TCP_STREAM

On 02/04/2016 11:38 AM, Tom Herbert wrote: On Thu, Feb 4, 2016 at 11:13 AM, Rick Jones wrote: The Intel folks suggested something about the process scheduler moving the sender around and ultimately causing some packet re-ordering. That could I suppose explain the TCP_STREAM difference, but

Disabling XPS for 4.4.0-1+ixgbe+OpenStack VM over a VLAN means 65% increase in netperf TCP_STREAM

around and ultimately causing some packet re-ordering. That could I suppose explain the TCP_STREAM difference, but not the TCP_RR since that has just a single segment in flight at one time. I can try to get perf/whatnot installed on the systems - suggestions as to what metrics to look at are we

Re: [PATCH net-next v5 1/2] ethtool: add speed/duplex validation functions

On 02/04/2016 04:47 AM, Michael S. Tsirkin wrote: On Wed, Feb 03, 2016 at 03:49:04PM -0800, Rick Jones wrote: And even for not-quite-virtual devices - such as a VC/FlexNIC in an HPE blade server there can be just about any speed set. I think we went down a path of patching some things to

Re: [PATCH net-next v5 1/2] ethtool: add speed/duplex validation functions

On 02/03/2016 03:32 PM, Stephen Hemminger wrote: But why check for valid value at all. At some point in the future, there will be yet another speed adopted by some standard body and the switch statement would need another value. Why not accept any value? This is a virtual device. And even fo

net/ipv6/ip6_flowlabel.c:543 suspicious rcu_dereference_check() usage!

=== [ INFO: suspicious RCU usage. ] 4.5.0-rc2-think+ #2 Tainted: GW --- net/ipv6/ip6_flowlabel.c:543 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 1

[PATCH net-next] ethtool: Declare netdev_rss_key as __read_mostly.

netdev_rss_key is written to once and thereafter is read by drivers when they are initialising. The fact that it is mostly read and not written to makes it a candidate for a __read_mostly declaration. Signed-off-by: Kim Jones Signed-off-by: Alan Carey Acked-by: Rami Rosen --- include/linux

Re: bonding (IEEE 802.3ad) not working with qemu/virtio

through an interface is significantly greater than the reported link speed. I have to wonder how unique it is in that regard. Doesn't mean there can't be a default, but does suggest it should be rather high. rick jones

Re: out of bounds in pptp_connect.

On Sun, Jan 17, 2016 at 12:06:58PM -0500, Dave Jones wrote: > I've managed to trigger this a few times the last few days, on Linus' tree. > > == > BUG: KASAN: slab-out-of-bounds in pptp_connect+0xb7

suspicious rcu_dereference in tcp_v6_send_synack

=== [ INFO: suspicious RCU usage. ] 4.4.0-rc8-firewall+ #1 Not tainted --- net/ipv6/tcp_ipv6.c:465 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 1 1 lock held by

Re: 4.4-rc7 failure report

On Wed, Dec 30, 2015 at 10:38:56AM +0100, Daniel Borkmann wrote: > Given that this drop doesn't strictly need to be caused by filter code, > it would be nice if you could pin the location down where the packet gets > dropped exactly. Perhaps dropwatch or perf with '-e skb:kfree_skb -a -g > dhc

Re: suspicious RCU usage (netlink/rhashtable)

On Tue, Dec 22, 2015 at 04:50:20PM -0500, David Miller wrote: > > > > Simple fix is below. Though, I don't understand the history of the > > > > multiple locks in this structure to be sure it's correct. I'll send > > > > it as a formal patch. Please reject if it's not the right approach.

Re: suspicious RCU usage (netlink/rhashtable)

On Tue, Dec 22, 2015 at 04:42:25PM -0500, David Miller wrote: > From: Craig Gallek > Date: Tue, 22 Dec 2015 16:38:32 -0500 > > > On Tue, Dec 22, 2015 at 4:28 PM, David Miller wrote: > >> From: Craig Gallek > >> Date: Tue, 22 Dec 2015 15:51:19 -0500 > >> > >>> I was actually just looking

suspicious RCU usage (netlink/rhashtable)

=== [ INFO: suspicious RCU usage. ] 4.4.0-rc6-think+ #1 Not tainted --- lib/rhashtable.c:522 suspicious rcu_dereference_protected() usage! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 2 locks held by t

Re: [BUG] net: performance regression on ixgbe (Intel 82599EB 10-Gigabit NIC)

since it wasn't the same per-core "horsepower" on either side and so why LRO on/off could have also affected the TCP_STREAM results. (When LRO was off it was off on both sides, and when on was on on both yes?) happy benchmarking, rick jones -- To unsubscribe from this li

Re: [BUG] net: performance regression on ixgbe (Intel 82599EB 10-Gigabit NIC)

y doing is turning on LRO support via ethtool -k to see if that is the issue you are seeing. Hi Alex, enabling LRO resolved the problem. So you had the same NIC and CPUs and whatnot on both sides? rick jones -- To unsubscribe from this list: send the line "unsubscribe netdev" in the

Re: suspicious rcu_dereference_check in sctp_v6_get_dst

On Sat, Dec 05, 2015 at 05:13:06PM -0800, Eric Dumazet wrote: > > diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c > > index acb45b8c2a9d..7081183f4d9f 100644 > > --- a/net/sctp/ipv6.c > > +++ b/net/sctp/ipv6.c > > @@ -328,7 +328,9 @@ static void sctp_v6_get_dst(struct sctp_transport *t, > >

suspicious rcu_dereference_check in sctp_v6_get_dst

=== [ INFO: suspicious RCU usage. ] 4.4.0-rc3-think+ #8 Tainted: GW --- net/sctp/ipv6.c:331 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 1 lock h

Re: [BUG] net: performance regression on ixgbe (Intel 82599EB 10-Gigabit NIC)

socket was created. If you want to see what they became by the end of the test, you need to use the appropriate output selectors (or, IIRC invoking the tests as "omni" rather than tcp_stream/tcp_maerts will report the end values rather than the start ones.). happy benchmarking, ric

Re: ipsec impact on performance

almost 80% on the netserver side. That is pure "effective" path-length increase. happy benchmarking, rick jones PS - the netperf commands were varations on this theme: ./netperf -P 0 -T 0 -H 10.12.49.1 -c -C -l 30 -i 30,3 -- -O throughput,local_cpu_util,local_sd,local_cpu

Re: ipsec impact on performance

On 12/01/2015 10:45 AM, Sowmini Varadhan wrote: On (12/01/15 10:17), Rick Jones wrote: What do the perf profiles show? Presumably, loss of TSO/GSO means an increase in the per-packet costs, but if the ipsec path significantly increases the per-byte costs... For ESP-null, there's act

Re: ipsec impact on performance

keeping the per-byte roughly the same. You could also compare the likes of a single-byte netperf TCP_RR test between ipsec enabled and not to get an idea of the basic path length differences without TSO/GSO/whatnot muddying the waters. happy benchmarking, rick jones -- To unsubscribe from this

4.4-rc2 xfrm_lookup kasan trace

My router fell off the internet. When I got home, I found a few hundred of these traces in the logs, and it refusing to route packets. Oddly, it only prints a stack trace, and no clue as to why it printed that trace. There was also nothing in the log prior to this that indicates how it got that

Re: [PATCH net-next 0/6] kcm: Kernel Connection Multiplexor (KCM)

jones -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

dccp->bind_conflict jump to null.

I've been trying to figure this one out for a while. It smells like a race, but I can't figure out any more than the clues below, and I've not really got the time to dig into it. After running Trinity for a while, I saw the machine just suddenly reboot. I managed to capture a partial trace over se

Re: 4.3.0+ breaks software VPN

On Fri, Nov 13, 2015 at 02:37:00PM -0700, Jens Axboe wrote: > Hi, > > Tried to connect to sw vpn today, and it isn't working. Running git > as-of yesterday. In dmesg: > > [23703.921542] vpn0: set_features() failed (-1); wanted > 0x008048c1, left 0x0080001b48c9 > > Revertin

Re: kasan r8169 use-after-free trace.

On Wed, Nov 11, 2015 at 10:19:28AM +0100, Francois Romieu wrote: > Dave Jones : > > This happens during boot, (and then there's a flood of traces that happen > > so fast > > afterwards it completely overwhelms serial console; not sure if they'

kasan r8169 use-after-free trace.

This happens during boot, (and then there's a flood of traces that happen so fast afterwards it completely overwhelms serial console; not sure if they're the same/related or not). == BUG: KASAN: use-after-free in rtl8169_poll+0x4b6/

Re: [PATCH] sh_eth: merge sh_eth_free_dma_buffer() into sh_eth_ring_free()

On Thu, Nov 05, 2015 at 01:29:15PM -0500, David Miller wrote: > From: Sergei Shtylyov > Date: Thu, 5 Nov 2015 20:19:17 +0300 > > >Hmm, I hadn't seen your announcement, else I would have refrained from > >sending. Will look for it now... > > I really don't know how to better get pe

Re: [PATCH net-next RFC 2/2] vhost_net: basic polling support

R and even aggregate _RR/packets per second for many VMs on the same system would be in order. happy benchmarking, rick jones -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.

Re: list of all network namespaces

etns . At least that is what an strace of that command suggests. rick jones -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: vethpair creation performance, 3.14 versus 4.2.0

On 08/31/2015 02:29 PM, David Ahern wrote: On 8/31/15 1:48 PM, Rick Jones wrote: My attempts to get a call-graph have been met with very limited success. Even though I've installed the dbg package from "make deb-pkg" the symbol resolution doesn't seem to be working. Lo

vethpair creation performance, 3.14 versus 4.2.0

Even though I've installed the dbg package from "make deb-pkg" the symbol resolution doesn't seem to be working. happy benchmarking, rick jones -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vge

Re: Low throughput in VMs using VxLAN

'm assuming the VM is using virtio_net) Does the behaviour change if vhost-net is loaded into the host and used by the VM? rick jones For completeness, it would also be good to compare the likes of netperf TCP_RR between VxLAN and without. -- To unsubscribe from this list: send the line &qu

I218 e1000e hangs.

I've got a machine with an onboard NIC that reproduces a hardware hang every time I do an rsync to it. [ 488.752630] e1000e :00:19.0 eth0: Detected Hardware Unit Hang: TDH <27> TDT <34> next_to_use <34> next_to_clean<23> buffer_info[n

Re: [PATCH v2 net-next] documentation: bring vxlan documentation more up-to-date

On 08/12/2015 04:46 PM, David Miller wrote: From: r...@tardy.usa.hp.com (Rick Jones) Date: Wed, 12 Aug 2015 10:23:14 -0700 (PDT) From: Rick Jones A few things have changed since the previous version of the vxlan documentation was written, so update it and correct some grammer and such while

[PATCH v2 net-next] documentation: bring vxlan documentation more up-to-date

From: Rick Jones A few things have changed since the previous version of the vxlan documentation was written, so update it and correct some grammer and such while we are at it. Signed-off-by: Rick Jones --- v2: Stephen Hemminger feedback to include dstport 4789 in command line example

Re: dccp related oops in inet_csk_get_port

On Wed, Jul 15, 2015 at 06:07:10PM -0400, Dave Jones wrote: > While experimenting with some dccp fuzzing, I hit this.. > > Oops: 0010 [#1] PREEMPT SMP DEBUG_PAGEALLOC > CPU: 3 PID: 19269 Comm: trinity-c22 Not tainted 4.2.0-rc2-think+ #2 > task: 88006f3954c0 ti: 8802b

Re: [PATCH net-next] documentation: bring vxlan documentation more up-to-date

On 08/11/2015 03:09 PM, Stephen Hemminger wrote: On Tue, 11 Aug 2015 13:47:16 -0700 (PDT) r...@tardy.usa.hp.com (Rick Jones) wrote: + # ip link add vxlan0 type vxlan id 42 group 239.1.1.1 dev eth1 + +This creates a new device named vxlan0. The device uses the +multicast group 239.1.1.1 over

[PATCH net-next] documentation: bring vxlan documentation more up-to-date

From: Rick Jones A few things have changed since the previous version of the vxlan documentation was written, so update it and correct some grammer and such while we are at it. Signed-off-by: Rick Jones diff --git a/Documentation/networking/vxlan.txt b/Documentation/networking/vxlan.txt

[PATCH net-next] net: add explicit logging and stat for neighbour table overflow

From: Rick Jones Add an explicit neighbour table overflow message (ratelimited) and statistic to make diagnosing neighbour table overflows tractable in the wild. Diagnosing a neighbour table overflow can be quite difficult in the wild because there is no explicit dmesg logged. Callers to

Diagnosing arp/neighbour table overflows and RFC for a related patch idea

arp_cache: neighbor table overflow! which seems rather more to the point. I'm still trying to decide if adding a table_overflow stat would be indicated as well. The forced_gc_runs stat doesn't indicate success or failure of the garbage collection, so in and of itself it doesn't mean we

Re: [PATCH net-next] virtio_net: add gro capability

On 08/03/2015 06:37 AM, Michael S. Tsirkin wrote: Ideally this needs to also be tested on non-vxlan configs with gro in host, to make sure this doesn't cause regressions. Measured with the same instances on the same hardware and software, taking a path through the stack (public rather than pri

[PATCH net-next] net: track success and failure of TCP PMTU probing

From: Rick Jones Track success and failure of TCP PMTU probing. Signed-off-by: Rick Jones --- Tested by loading-up into an OpenStack instance and kicking the MTU out from under it in the corresponding router namespace. diff --git a/include/uapi/linux/snmp.h b/include/uapi/linux/snmp.h index

dccp related oops in inet_csk_listen_start

While experimenting with some dccp fuzzing, I hit this.. Oops: 0010 [#1] PREEMPT SMP DEBUG_PAGEALLOC CPU: 3 PID: 19269 Comm: trinity-c22 Not tainted 4.2.0-rc2-think+ #2 task: 88006f3954c0 ti: 8802b89b task.ti: 8802b89b RIP: 0010:[<>] [< (null)>]

Re: [RFC net-next] net: Build IPv6 into kernel by default

On Thu, Jul 09, 2015 at 01:42:29PM -0700, Tom Herbert wrote: >For general information about IPv6, see >. > - For Linux IPv6 development information, see > . > - For specific information about IPv6 under

Re: [PATCH RFC net-next] vxlan: GRO support at tunnel layer

I went ahead and put the patched kernel on both systems. I was getting mixed results - in one direction, results in the 8Gbit/s range, in the other in the 7 Gbit/s. I noticed that interrupts were going to different CPUs so I started playing with IRQ assignments, and bound all interrupts of th

Re: [PATCH RFC net-next] vxlan: GRO support at tunnel layer

On 06/28/2015 10:20 AM, Ramu Ramamurthy wrote: Rick, in your test, are you seeing gro becoming effective on the vxlan interface with the 82599ES nic ? (ie, tcpdump on the vxlan interface shows larger frames than the mtu of that interface, and kernel trace shows vxlan_gro_receive() being hit) Thr

Re: [PATCH RFC net-next] vxlan: GRO support at tunnel layer

ction servers are doing. Slight drift - Linux is, for lack of a better expression, a complete fruit stand. One customer might indeed be into oranges, but I've had customers coming to me wanting to see shiny apples. happy benchmarking, rick jones -- To unsubscribe from this list: sen

Re: [PATCH RFC net-next] vxlan: GRO support at tunnel layer

fix (GRO disabled on VXLAN interface) Verified no GRO is happening. 9084 MBps tput 5.54% CPU utilization This has been an area of interest so: Tested-by: Rick Jones Some single-stream results between two otherwise identical systems with 82599ES NICs in them, one running a 4.1.0-rc1

Re: Issue with LACP mode support in Linux bonding driver

"pages" of the file. rick jones -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

4.1+ use after free in netlink_broadcast_filtered

I taught Trinity about NETLINK_LISTEN_ALL_NSID and NETLINK_LIST_MEMBERSHIPS yesterday, and this evening, this fell out.. general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC CPU: 1 PID: 9130 Comm: kworker/1:1 Not tainted 4.1.0-gelk-debug+ #1 Workqueue: sock_diag_events sock_diag_broadc

Re: ssh connections hanging on 4.1rc7

On Thu, Jun 11, 2015 at 11:24:21AM -0700, Eric Dumazet wrote: > > Just hit this weird problem where I can ssh into a machine once, > > then after logging out, subsequent ssh connections hang. > > Your tcpdumps look one way only. ok hit it again, so let's try again... client side: 15:34:1

Re: ssh connections hanging on 4.1rc7

On Thu, Jun 11, 2015 at 01:46:18PM -0400, Dave Jones wrote: > Just hit this weird problem where I can ssh into a machine once, > then after logging out, subsequent ssh connections hang. > > The client side looks like.. derp, missed half the tcpdump capture on both sides, and

ssh connections hanging on 4.1rc7

Just hit this weird problem where I can ssh into a machine once, then after logging out, subsequent ssh connections hang. The client side looks like.. 13:39:06.307781 IP wopr.kernelslacker.org.43982 > gelk.kernelslacker.org.ssh: Flags [S], seq 319726787, win 29200, options [mss 1460,sackOK,TS va

Re: [PATCH net-next] tcp: add tcpi_segs_in and tcpi_segs_out to tcp_info

On 05/20/2015 05:37 PM, Eric Dumazet wrote: Anyway, if we can send tcp data at 100Gbits on one flow, I guess we are doing a terrific job and do not need to tweak TCP stack anymore ;) :) rick -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to major

Re: [PATCH net-next] tcp: add tcpi_segs_in and tcpi_segs_out to tcp_info

1500 byte MTU the 32 bit segment counter would wrap in something like 500 seconds and change? rick jones -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [Question] TCP stack performance decrease since 3.14

filing to see how the CPU consumption break-down has changed. happy benchmarking, rick jones If others have seen this or is just simply to be expected (from new features and the like) is it due to the TCP stack itself or other changes in the kernel? If so, is there anyway to mitigate the effect

Re: [Xen-devel] "tcp: refine TSO autosizing" causes performance regression on Xen

On 04/15/2015 11:32 AM, Eric Dumazet wrote: On Wed, 2015-04-15 at 11:19 -0700, Rick Jones wrote: Well, I'm not sure that it is George and Jonathan themselves who don't want to change a sysctl, but the customers who would have to tweak that in their VMs? Keep in mind some VM use

Re: [Xen-devel] "tcp: refine TSO autosizing" causes performance regression on Xen

On 04/15/2015 11:08 AM, Eric Dumazet wrote: On Wed, 2015-04-15 at 10:55 -0700, Rick Jones wrote: Have you tested this patch on a NIC without GSO/TSO ? This would allow more than 500 packets for a single flow. Hello bufferbloat. Woudln't the fq_codel qdisc on that interface address

Re: [Xen-devel] "tcp: refine TSO autosizing" causes performance regression on Xen

Have you tested this patch on a NIC without GSO/TSO ? This would allow more than 500 packets for a single flow. Hello bufferbloat. Woudln't the fq_codel qdisc on that interface address that problem? rick -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a m

lockdep trace from rc2.

https://bugzilla.redhat.com/show_bug.cgi?id=431038 has some more info, but the trace is below... I'll get an rc3 kernel built and ask the user to retest, but in case this isn't a known problem, I'm forwarding this here. Dave Feb 24 17:53:21 cirithungol kernel: ==

permisions for Ethetool vs rtnetlink

would think the sensitivity of both sets of information would be about the same? Is the difference simply an artifact of history? sincerely, rick jones -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordom

Re: why does DCCP SO_REUSEADDR have to be SOL_DCCP?

Arnaldo Carvalho de Melo wrote: Em Fri, Feb 01, 2008 at 05:42:23PM -0800, Rick Jones escreveu: Hi - I'm tweaking the netperf omni tests to be able to run over DCCP. I've run across a not-unorecedented problem with getaddrinfo() not groking either SOCK_DCCP or IPPROTO_DCCP in the

why does DCCP SO_REUSEADDR have to be SOL_DCCP?

itself doesn't fail, only the later listen() or connect() call... happy benchmarking, rick jones -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Disable TSO for non standard qdiscs

mentioned person shaping for their DSL line happens to have enabled JumboFrames on their GbE network, will/should the qdisc negate that? Or is the qdisc currently assuming that the remote end of the DSL will have asked for a smaller MSS? rick jones -- To unsubscribe from this list: send the line

Re: [PATCH] Disable TSO for non standard qdiscs

of a 'TSO' based on the bitrate (and perhaps input as to how much time any one "burst" of data should be allowed to consume on the network) and pass that up the stack? right now you seem to be proposing what is effectively a cap of 1 MSS. rick jones -- To unsubscribe from thi

Re: e1000 full-duplex TCP performance well below wire speed

matter of getting specs for the various LBA's (is that the correct term? - lower bus adaptors) and then abstracting them a la the CPU perf counters as done by say perfmon and then used by papi :) rick jones -- To unsubscribe from this list: send the line "unsubscribe netdev" i

Re: e1000 full-duplex TCP performance well below wire speed

register clears per second (slow ioread/writes). The transactions double for TCP ack processing, and this all accumulates and starts to introduce latency, higher cpu utilization etc... Sounds like tools to show PCI* bus utilization would be helpful... rick jones -- To unsubscribe from this list: send

Re: [PATCH] Disable TSO for non standard qdiscs

Andi Kleen wrote: On Thu, Jan 31, 2008 at 10:26:19AM -0800, Rick Jones wrote: Andi Kleen wrote: TSO interacts badly with many queueing disciplines because they rely on reordering packets from different streams and the large TSO packets can make this difficult. This patch disables TSO for

Re: [PATCH] Disable TSO for non standard qdiscs

x27;s anything but noop or pfifo_fast and pfifo right now. Does this also imply that JumboFrames interacts badly with these qdiscs? Or IPoIB with its 65000ish byte MTU? rick jones -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL

running aggregate netperf TCP_RR Re: e1000 full-duplex TCP performance well below wire speed

experiment with the value you use with -b - the value necessary to get to saturation may not always be the same - particularly as you switch from link to link and from LAN to WAN and all those familiar bandwidthXdelay considerations. happy benchmarking, rick jones -- To unsubscribe from this list

Re: e1000 full-duplex TCP performance well below wire speed

perf2_trunk$ (this was a WAN test :) rick jones one of these days I may tweak netperf further so if the CPU utilization method for either end doesn't require calibration, CPU utilization will always be done on that end. people's thoughts on that tweak would be most welcome... -- To u

Re: e1000 full-duplex TCP performance well below wire speed

s/netperf-2.4.4/doc/netperf.html#Using-Netperf-to-Measure-Aggregate-Performance> and use a combination of TCP_STREAM and TCP_MAERTS (STREAM backwards) tests. happy benchmarking, rick jones -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body

Re: e1000 full-duplex TCP performance well below wire speed

orse than if it just lets the kernel auto-tune. That is the bit where explicit setsockopts are capped by core [rw]mem sysctls but the autotuning is not correct? rick jones BTW, a bit of netperf news - the "omni" (two routines to measure it all) tests seem to be more or less working no

Re: Netperf TCP_RR(loopback) 10% regression in 2.6.24-rc6, comparing with 2.6.22

() could have more code added to it to check for a UDP test over loopback, but probably needs to be a check for any local IP, and unless this becomes something bigger than "Doctor! Doctor! It hurts when I do this!" :) I'm inclined to leave it as caveat benchmarker and perhaps some a

Re: Netperf TCP_RR(loopback) 10% regression in 2.6.24-rc6, comparing with 2.6.22

r upgrading. happy benchmarking, rick jones -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: e1000 performance issue in 4 simultaneous links

HW counters to check that... Can you describe the I/O subsystem more completely? I understand that you are using at most two ports of a pair of quad-port cards at any one time, but am still curious to know if those two cards are on separate busses, or if they share any bus/link on the way to

Re: Netperf TCP_RR(loopback) 10% regression in 2.6.24-rc6, comparing with 2.6.22

-i option to set the confidence iteration count will silently cap the max at 30. happy benchmarking, rick jones -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: questions on NAPI processing latency and dropped network packets

een processed on both CPUs at various points in the past, it doesn't necessarily mean that they are being processed on both CPUs at the same time right? rick jones -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More major

Re: e1000 performance issue in 4 simultaneous links

12340 eth2 4: 00 0 1234 eth3 which you should be able to acheive via the method I think someone else has already mentioned about echoing values into /proc/irq//smp_affinity - after you have slain the dreaded irqbalance daemon. rick jones -- To u

Re: e1000 performance issue in 4 simultaneous links

g the global -T option to spread the netperf/netserver processes across the CPUs, or leaving that all up to the stack/scheduler/etc? I suspect there could be more but that is what comes to mind thusfar as far as things I often check when running netperf. rick jones -- To unsubscribe from this

Re: AF_UNIX MSG_PEEK bug?

he message length with a normal read/recv, and then read that many bytes in the next call? rick jones -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [RFC] ehea: kdump support using new shutdown hook

On Wed, Dec 12, 2007 at 05:53:43PM +0100, Thomas Klein wrote: > +static void ehea_update_adapter_handles(struct ehea_adapter *adapter) > +{ > +int i, k; > +int j = 0; > + > +memset(adapter->res_handles, sizeof(adapter->res_handles), 0); arguments wrong way around. Dave

delay via-rhine irq initialisation.

r the alloc_tbufs(), but I feel if a real interrupt occured, this diff would stand more chance of doing the right thing. Comments? Dave Delay irq registration until after we've allocated ring buffers, otherwise DEBUG_SHIRQ will complain. Signed-off-by: Dave Jones <[EMAIL PROTECTED]&g

Re: e1000 driver problems

us, one at a time request/response, never tries to have both sides talking at the same time. Finally, when/if you migrate to 1000Base-T, everything has to be set to auto-neg anyway. rick jones -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a messa

Re: Reproducible data corruption with sendfile+vsftp - splice regression?

Could the corruption be seen in a tcpdump trace prior to transmission (ie taken on the sender) or was it only seen after the data passed out the NIC? rick jones - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majo

Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.

Adrian Bunk wrote: On Tue, Nov 27, 2007 at 01:15:23PM -0800, Rick Jones wrote: The real problem is that these drivers are not in the upstream kernel. Are there common reasons why these drivers are not upstream? One might be that upstream has not accepted them. Anything doing or smelling

Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.

On Tue, Nov 27, 2007 at 10:09:42PM +0100, Adrian Bunk wrote: > On Tue, Nov 27, 2007 at 02:00:37PM -0500, Dave Jones wrote: > > On Mon, Nov 26, 2007 at 10:25:33AM -0800, Stephen Hemminger wrote: > > > > > 1) Why is everyone so concerned that expo

Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.

The real problem is that these drivers are not in the upstream kernel. Are there common reasons why these drivers are not upstream? One might be that upstream has not accepted them. Anything doing or smelling of TOE comes to mind right away. rick jones - To unsubscribe from this list: send

Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.

On Mon, Nov 26, 2007 at 10:25:33AM -0800, Stephen Hemminger wrote: > 1) Why is everyone so concerned that export symbol space is large? > - does it cost cpu or running memory? > - does it cause bugs? > - or are you just worried about "evil modules"? To clarify something here,

Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.

On Thu, Nov 22, 2007 at 03:43:06AM +0100, Andi Kleen wrote: > There seems to be rough consensus that the kernel currently has too many > exported symbols. A lot of these exports are generally usable utility > functions or important driver interfaces; but another large part are > functions

Re: [PATCH] LRO ack aggregation

. In some experiements a while back I thought I saw that LRO on the receiver was causing him to send fewer ACKs already? IIRC that was with a Myricom card, perhaps I was fooled by it's own ACK LRO it was doing. rick jones - To unsubscribe from this list: send the line "unsubscribe netdev

Re: [PATCH 10/13] tg3: Increase the PCI MRRS

the current value of the MRRS get displayed in lspci output? It wouldn't be a slam dunk, but if someone were looking at that and saw the value large they might make an educated guess. rick jones - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

<    1   2   3   4   5   6   7   8   9   10   >