From owner-freebsd-net@FreeBSD.ORG Sun Nov 13 05:10:05 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E0A61065670 for ; Sun, 13 Nov 2011 05:10:05 +0000 (UTC) (envelope-from sergeysaley@gmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id D11F68FC0A for ; Sun, 13 Nov 2011 05:10:04 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1RPSKR-000585-U1 for freebsd-net@freebsd.org; Sat, 12 Nov 2011 21:10:03 -0800 Date: Sat, 12 Nov 2011 21:10:03 -0800 (PST) From: Sergey Saley To: freebsd-net@freebsd.org Message-ID: <1321161003925-4988068.post@n5.nabble.com> In-Reply-To: <1319530877390-4935427.post@n5.nabble.com> References: <1319478384269-4933498.post@n5.nabble.com> <1319483324861-4933765.post@n5.nabble.com> <1319485884830-4933934.post@n5.nabble.com> <1319527328469-4935272.post@n5.nabble.com> <1319530877390-4935427.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Too much interrupts on ixgbe X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 05:10:05 -0000 Hi! To be continued... I replaced 82598 (2 cx4 ports) with 82599 (2 sfp+ ports) without any configuration changes. The same host, same system, same tuning, same load and traffic. Was (82598): # vmstat -i interrupt total rate irq19: atapci0 1667110 0 cpu0: timer 3386721810 328 irq256: ix0:que 0 3395843376 329 irq257: ix0:que 1 2642665824 256 irq258: ix0:que 2 2838302235 275 irq259: ix0:que 3 2176207954 211 irq260: ix0:link 18 0 irq261: ix1:que 0 282359321 27 irq262: ix1:que 1 3989170496 387 irq263: ix1:que 2 375956573 36 irq264: ix1:que 3 3966352151 384 irq265: ix1:link 1 0 irq266: em0:rx 0 10283114 0 irq269: em1:rx 0 10283114 0 cpu3: timer 3386697130 328 cpu1: timer 3386709028 328 cpu2: timer 3386700908 328 Total 33235920163 3225 Now (82599): # vmstat -i interrupt total rate irq1: atkbd0 353 1 irq19: atapci0 1368 3 cpu0: timer 682557 1978 irq256: ix0:que 0 3555342 10305 irq257: ix0:que 1 3120223 9044 irq258: ix0:que 2 3408333 9879 irq259: ix0:que 3 3279717 9506 irq260: ix0:link 4 0 irq261: ix1:que 0 2905248 8421 irq262: ix1:que 1 2647858 7674 irq263: ix1:que 2 2411908 6991 irq264: ix1:que 3 2319469 6723 irq265: ix1:link 3 0 irq266: em0:rx 0 338 0 irq269: em1:rx 0 338 0 cpu1: timer 682529 1978 cpu2: timer 682527 1978 cpu3: timer 682527 1978 Total 26380642 76465 Why interrupt count is so huge? What's wrong with this card (or with driver)? -- View this message in context: http://freebsd.1045724.n5.nabble.com/Too-much-interrupts-on-ixgbe-tp4931883p4988068.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Sun Nov 13 20:34:25 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45300106564A; Sun, 13 Nov 2011 20:34:25 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1D86F8FC0C; Sun, 13 Nov 2011 20:34:25 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pADKYOwU032458; Sun, 13 Nov 2011 20:34:24 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pADKYOES032454; Sun, 13 Nov 2011 20:34:24 GMT (envelope-from linimon) Date: Sun, 13 Nov 2011 20:34:24 GMT Message-Id: <201111132034.pADKYOES032454@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/162509: [re] [panic] Kernel panic may be related to if_re.c (realtek 8168 ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 20:34:25 -0000 Old Synopsis: Kernel panic may be related to if_re.c (realtek 8168 ) New Synopsis: [re] [panic] Kernel panic may be related to if_re.c (realtek 8168 ) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Nov 13 20:34:04 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=162509 From owner-freebsd-net@FreeBSD.ORG Sun Nov 13 21:16:40 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E5F51065675 for ; Sun, 13 Nov 2011 21:16:40 +0000 (UTC) (envelope-from weiler@soe.ucsc.edu) Received: from mail-01.cse.ucsc.edu (mail-01.cse.ucsc.edu [128.114.48.32]) by mx1.freebsd.org (Postfix) with ESMTP id 6F40B8FC0A for ; Sun, 13 Nov 2011 21:16:40 +0000 (UTC) Received: from erich-weilers-macbook-pro.local (hgfw-01.soe.ucsc.edu [128.114.58.17]) by mail-01.cse.ucsc.edu (Postfix) with ESMTPSA id 1F4541009CD1 for ; Sun, 13 Nov 2011 13:16:40 -0800 (PST) Message-ID: <4EC033B7.5080609@soe.ucsc.edu> Date: Sun, 13 Nov 2011 13:16:39 -0800 From: Erich Weiler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Arg. TCP slow start killing me. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 21:16:40 -0000 So, I have a FreeBSD 8.1 box that I'm using as a firewall (pfSense 2.0 really, which uses 8.1 as a base), and I'm filtering packets inbound and I'm seeing a typical sawtooth pattern where I get high bandwidth, then a packet drops somewhere, and the TCP connections back off a *lot*, then slowly get faster, then backoff, etc. These are all higher latency WAN connections. I get an average of 1.5 - 2.0 Gb/s incoming, but I see it spike to like 3Gb/s every once in a while, then drop again. I'm trying to maintain that 3Gb/s for as long as possible between it dropping. Given that 8.1 does not have the more advanced TCP congestion algorithms like cubic and H-TPC that might help that to some degree, I'm trying to "fake it". ;) My box has 24GB RAM on it. Is there some tunable I can set that would effectively buffer incoming packets, even though the buffers would eventually fill up, just to "delay" the TCP dropped packet signal telling the hosts on the internet to back off? Like, could I effectively buffer 10GB of packets in the queue before it sent the backoff signal? Would setting kern.ipc.nmbclusters or something similar help? Right now I have: loader.conf.local: vm.kmem_size_max=12G vm.kmem_size=10G sysctl.conf: kern.ipc.maxsockbuf=16777216 kern.ipc.nmbclusters=262144 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.recvspace=8192 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.sendspace=16384 I guess the goal is to keep the bandwidth high without dropoffs for as long as possible, with out as many TCP resets on the streams. Any help much appreciated! I'm probably missing a key point, but that's why I'm posting to the list. ;) cheers, erich From owner-freebsd-net@FreeBSD.ORG Sun Nov 13 21:48:20 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBED1106566B for ; Sun, 13 Nov 2011 21:48:20 +0000 (UTC) (envelope-from nitroboost@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9B2158FC0C for ; Sun, 13 Nov 2011 21:48:20 +0000 (UTC) Received: by gyd5 with SMTP id 5so6077973gyd.13 for ; Sun, 13 Nov 2011 13:48:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zRdUO+Sisa4SuFM4iacD9k0DCGW3Y4AfSNqtCHUoEF0=; b=GSPuB8GdAaZ+kt9sQFUF2K6oRxTXAulBKQMDJbedqm+DhlXXhAB+9uGCG90LkU4Upt PKdvoY2Tu1YeZsGo3wLuFS4esNvPV2NNfU220Thj+r5MMPNqRoYVoUXAbtf4jUQOQaRe yjsdzq/6MdHkipO3by+ZpH8hHoDcbFjGYpQ+0= MIME-Version: 1.0 Received: by 10.182.108.100 with SMTP id hj4mr4459532obb.34.1321220899685; Sun, 13 Nov 2011 13:48:19 -0800 (PST) Received: by 10.182.30.164 with HTTP; Sun, 13 Nov 2011 13:48:19 -0800 (PST) In-Reply-To: <4EC033B7.5080609@soe.ucsc.edu> References: <4EC033B7.5080609@soe.ucsc.edu> Date: Sun, 13 Nov 2011 14:48:19 -0700 Message-ID: From: Jason Wolfe To: Erich Weiler Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Arg. TCP slow start killing me. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 21:48:20 -0000 Erich, Slow start is actually just the initial ramp up limited by RFC 3390 being enabled by default (usually 3/4 packets), but this is only the case for the first few seconds of the stream. You can effectively speed that up with something like this though: net.inet.tcp.rfc3390=0 net.inet.tcp.slowstart_flightsize=10 net.inet.tcp.sendspace=262144 net.inet.tcp.recvspace=262144 The first 2 allow 10 packets to be sent before an ACK, and the 2nd 2 just bump as the starting window size. With your memory and the massive max you set no reason to force them to slowly step up from such a low initial size. Looks like the numbers you used for initial are actually the default increment/step size of the window growth. Also since you mentioned latency playing a factor here, try this sysctl. If overruns are an issue you'll likely see a bit of an increase in retransmits, but could potentially show a sizable positive impact in the saw tooth. net.inet.tcp.inflight.enable=0 Is it possible to upgrade to 8.2-STABLE? Cubic has shown some really great improvement in my latent paths, a steady 10% overall increase in same cases. Jason Wolfe On Sun, Nov 13, 2011 at 2:16 PM, Erich Weiler wrote: > So, I have a FreeBSD 8.1 box that I'm using as a firewall (pfSense 2.0 > really, which uses 8.1 as a base), and I'm filtering packets inbound and > I'm seeing a typical sawtooth pattern where I get high bandwidth, then a > packet drops somewhere, and the TCP connections back off a *lot*, then > slowly get faster, then backoff, etc. These are all higher latency WAN > connections. > > I get an average of 1.5 - 2.0 Gb/s incoming, but I see it spike to like > 3Gb/s every once in a while, then drop again. I'm trying to maintain that > 3Gb/s for as long as possible between it dropping. > > Given that 8.1 does not have the more advanced TCP congestion algorithms > like cubic and H-TPC that might help that to some degree, I'm trying to > "fake it". ;) > > My box has 24GB RAM on it. Is there some tunable I can set that would > effectively buffer incoming packets, even though the buffers would > eventually fill up, just to "delay" the TCP dropped packet signal telling > the hosts on the internet to back off? Like, could I effectively buffer > 10GB of packets in the queue before it sent the backoff signal? Would > setting kern.ipc.nmbclusters or something similar help? > > Right now I have: > > loader.conf.local: > > vm.kmem_size_max=12G > vm.kmem_size=10G > > sysctl.conf: > > kern.ipc.maxsockbuf=16777216 > kern.ipc.nmbclusters=262144 > net.inet.tcp.recvbuf_max=16777216 > net.inet.tcp.recvspace=8192 > net.inet.tcp.sendbuf_max=16777216 > net.inet.tcp.sendspace=16384 > > I guess the goal is to keep the bandwidth high without dropoffs for as > long as possible, with out as many TCP resets on the streams. > > Any help much appreciated! I'm probably missing a key point, but that's > why I'm posting to the list. ;) > > cheers, > erich > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sun Nov 13 21:54:36 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E98DA106564A for ; Sun, 13 Nov 2011 21:54:36 +0000 (UTC) (envelope-from nitroboost@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id A7F0F8FC08 for ; Sun, 13 Nov 2011 21:54:36 +0000 (UTC) Received: by yenl11 with SMTP id l11so660115yen.13 for ; Sun, 13 Nov 2011 13:54:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XT+ELrr/azINNaf8c73paLfBrC4ZnCdTWeGyx1rFs2I=; b=krfDBCL1l7xfKYBOrHz8uI0viUfHF80t3M7dUWoUXwOaBoKCTKxnHCxb5mFrKXdH9r jv7ExJM7plftoq5MwTe9V8qnqc9FNyckzGXkA5NbcYPoIrHZZbVbxO0xofQ6fE+kQQ0Y W1pJVmUskIUKwcBvs7fVbXG7LOMZXBXl2Y7G4= MIME-Version: 1.0 Received: by 10.182.108.100 with SMTP id hj4mr4462818obb.34.1321221275767; Sun, 13 Nov 2011 13:54:35 -0800 (PST) Received: by 10.182.30.164 with HTTP; Sun, 13 Nov 2011 13:54:35 -0800 (PST) In-Reply-To: References: <4EC033B7.5080609@soe.ucsc.edu> Date: Sun, 13 Nov 2011 14:54:35 -0700 Message-ID: From: Jason Wolfe To: Erich Weiler Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Arg. TCP slow start killing me. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 21:54:37 -0000 Erich, Forgot to mention net.inet.tcp.delayed_ack can be a detriment in latent paths, might try setting it to 0 to see if it improves your throughput. Jason Wolfe On Sun, Nov 13, 2011 at 2:48 PM, Jason Wolfe wrote: > Erich, > > Slow start is actually just the initial ramp up limited by RFC 3390 being > enabled by default (usually 3/4 packets), but this is only the case for the > first few seconds of the stream. You can effectively speed that up with > something like this though: > > net.inet.tcp.rfc3390=0 > net.inet.tcp.slowstart_flightsize=10 > net.inet.tcp.sendspace=262144 > net.inet.tcp.recvspace=262144 > > The first 2 allow 10 packets to be sent before an ACK, and the 2nd 2 just > bump as the starting window size. With your memory and the massive max you > set no reason to force them to slowly step up from such a low initial size. > Looks like the numbers you used for initial are actually the default > increment/step size of the window growth. > > Also since you mentioned latency playing a factor here, try this sysctl. > If overruns are an issue you'll likely see a bit of an increase in > retransmits, but could potentially show a sizable positive impact in the > saw tooth. > > net.inet.tcp.inflight.enable=0 > > Is it possible to upgrade to 8.2-STABLE? Cubic has shown some really > great improvement in my latent paths, a steady 10% overall increase in same > cases. > > Jason Wolfe > > On Sun, Nov 13, 2011 at 2:16 PM, Erich Weiler wrote: > >> So, I have a FreeBSD 8.1 box that I'm using as a firewall (pfSense 2.0 >> really, which uses 8.1 as a base), and I'm filtering packets inbound and >> I'm seeing a typical sawtooth pattern where I get high bandwidth, then a >> packet drops somewhere, and the TCP connections back off a *lot*, then >> slowly get faster, then backoff, etc. These are all higher latency WAN >> connections. >> >> I get an average of 1.5 - 2.0 Gb/s incoming, but I see it spike to like >> 3Gb/s every once in a while, then drop again. I'm trying to maintain that >> 3Gb/s for as long as possible between it dropping. >> >> Given that 8.1 does not have the more advanced TCP congestion algorithms >> like cubic and H-TPC that might help that to some degree, I'm trying to >> "fake it". ;) >> >> My box has 24GB RAM on it. Is there some tunable I can set that would >> effectively buffer incoming packets, even though the buffers would >> eventually fill up, just to "delay" the TCP dropped packet signal telling >> the hosts on the internet to back off? Like, could I effectively buffer >> 10GB of packets in the queue before it sent the backoff signal? Would >> setting kern.ipc.nmbclusters or something similar help? >> >> Right now I have: >> >> loader.conf.local: >> >> vm.kmem_size_max=12G >> vm.kmem_size=10G >> >> sysctl.conf: >> >> kern.ipc.maxsockbuf=16777216 >> kern.ipc.nmbclusters=262144 >> net.inet.tcp.recvbuf_max=16777216 >> net.inet.tcp.recvspace=8192 >> net.inet.tcp.sendbuf_max=16777216 >> net.inet.tcp.sendspace=16384 >> >> I guess the goal is to keep the bandwidth high without dropoffs for as >> long as possible, with out as many TCP resets on the streams. >> >> Any help much appreciated! I'm probably missing a key point, but that's >> why I'm posting to the list. ;) >> >> cheers, >> erich >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > From owner-freebsd-net@FreeBSD.ORG Sun Nov 13 22:45:03 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15F9E106566B for ; Sun, 13 Nov 2011 22:45:03 +0000 (UTC) (envelope-from garmitage@swin.edu.au) Received: from gpo4.cc.swin.edu.au (gpo4.cc.swin.edu.au [136.186.1.33]) by mx1.freebsd.org (Postfix) with ESMTP id A12448FC08 for ; Sun, 13 Nov 2011 22:45:02 +0000 (UTC) Received: from [136.186.229.44] (garmitage3.caia.swin.edu.au [136.186.229.44]) by gpo4.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id pADLei1o011180 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 14 Nov 2011 08:40:54 +1100 Message-ID: <4EC0395C.3030302@swin.edu.au> Date: Mon, 14 Nov 2011 08:40:44 +1100 From: grenville armitage User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101211 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4EC033B7.5080609@soe.ucsc.edu> In-Reply-To: <4EC033B7.5080609@soe.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Arg. TCP slow start killing me. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 22:45:03 -0000 On 11/14/2011 08:16, Erich Weiler wrote: > So, I have a FreeBSD 8.1 box that I'm using as a firewall (pfSense > 2.0 really, which uses 8.1 as a base), and I'm filtering packets > inbound and I'm seeing a typical sawtooth pattern where I get high > bandwidth, then a packet drops somewhere, and the TCP connections > back off a *lot*, then slowly get faster, then backoff, etc. These > are all higher latency WAN connections. [..] > Any help much appreciated! I'm probably missing a key point, but > that's why I'm posting to the list. ;) Possibly not much you can do if you only have control of a firewall. (And it sounds like your firewall is neither the TCP source or destination.) A TCP sender pretty much dictates how it will react to packet loss (so the senders are the ones who need to explore the use of e.g. cubic). Now, if it is your firewall that's causing some of the packet losses, then you can help by increasing buffering locally -- but that's only to avoid the overflow that causes packets to be lost. If your firewall isn't the cause of the packet losses, then you don't really have much control -- the TCP source(s) _will_ detect the packet losses, either due to duplicate ACKs coming back from the destination or timeout waiting for ACK from destination. Adding buffering on the firewall wont help here either -- unless you artificially rate-limit flows through the firewall (e.g. with dummynet) there's little reason for a queue to build up, and if you enforce a queue (more latency) the path's RTT will be artificially high, causing much badness (reduced goodput) for all TCP sessions passing through your firewall. cheers, gja From owner-freebsd-net@FreeBSD.ORG Sun Nov 13 23:38:58 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A6A41065672 for ; Sun, 13 Nov 2011 23:38:58 +0000 (UTC) (envelope-from weiler@soe.ucsc.edu) Received: from mail-01.cse.ucsc.edu (mail-01.cse.ucsc.edu [128.114.48.32]) by mx1.freebsd.org (Postfix) with ESMTP id 282FD8FC0C for ; Sun, 13 Nov 2011 23:38:58 +0000 (UTC) Received: from erich-weilers-macbook-pro.local (dsl-63-249-90-171.static.cruzio.com [63.249.90.171]) by mail-01.cse.ucsc.edu (Postfix) with ESMTPSA id D8D7B4E44057; Sun, 13 Nov 2011 15:38:57 -0800 (PST) Message-ID: <4EC05511.1080102@soe.ucsc.edu> Date: Sun, 13 Nov 2011 15:38:57 -0800 From: Erich Weiler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Jason Wolfe References: <4EC033B7.5080609@soe.ucsc.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Arg. TCP slow start killing me. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 23:38:58 -0000 Thanks Jason! > Is it possible to upgrade to 8.2-STABLE? Cubic has shown some really > great improvement in my latent paths, a steady 10% overall increase in > same cases. Alas no, my OS is a pre-baked install for pfSense, and if I tried to upgrade it, it would likely break some of the functionality of how pfSense is built. I've considered patching in some kernel mods to add cubic and H-TCP to the kernel, but even that makes me nervous. From owner-freebsd-net@FreeBSD.ORG Sun Nov 13 23:42:05 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9ED0106566C for ; Sun, 13 Nov 2011 23:42:03 +0000 (UTC) (envelope-from weiler@soe.ucsc.edu) Received: from mail-01.cse.ucsc.edu (mail-01.cse.ucsc.edu [128.114.48.32]) by mx1.freebsd.org (Postfix) with ESMTP id D8C728FC08 for ; Sun, 13 Nov 2011 23:42:03 +0000 (UTC) Received: from erich-weilers-macbook-pro.local (dsl-63-249-90-171.static.cruzio.com [63.249.90.171]) by mail-01.cse.ucsc.edu (Postfix) with ESMTPSA id 70D284E44052; Sun, 13 Nov 2011 15:42:03 -0800 (PST) Message-ID: <4EC055CB.40100@soe.ucsc.edu> Date: Sun, 13 Nov 2011 15:42:03 -0800 From: Erich Weiler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: grenville armitage References: <4EC033B7.5080609@soe.ucsc.edu> <4EC0395C.3030302@swin.edu.au> In-Reply-To: <4EC0395C.3030302@swin.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Arg. TCP slow start killing me. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 23:42:05 -0000 > If your firewall > isn't the cause of the packet losses, then you don't really have much > control -- the TCP source(s) _will_ detect the packet losses, either due > to duplicate ACKs coming back from the destination or timeout waiting for > ACK from destination. I suspect my firewall *is* the cause of the packet loss, unfortunately. We're sending multiple streams in from multiple sources and destinations, but the aggregate bandwidth coming into the firewall is consistent no matter how many sources and destinations we have. It maxes at about 2Gb/s. That's why I was trying to tweak the firewall, to try and get that number up. From owner-freebsd-net@FreeBSD.ORG Sun Nov 13 23:53:03 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D342C106564A for ; Sun, 13 Nov 2011 23:53:03 +0000 (UTC) (envelope-from weiler@soe.ucsc.edu) Received: from mail-01.cse.ucsc.edu (mail-01.cse.ucsc.edu [128.114.48.32]) by mx1.freebsd.org (Postfix) with ESMTP id C18488FC14 for ; Sun, 13 Nov 2011 23:53:03 +0000 (UTC) Received: from erich-weilers-macbook-pro.local (50-0-69-3.dsl.static.fusionbroadband.com [50.0.69.3]) by mail-01.cse.ucsc.edu (Postfix) with ESMTPSA id 8AA861009C1E; Sun, 13 Nov 2011 15:53:03 -0800 (PST) Message-ID: <4EC0585F.5000104@soe.ucsc.edu> Date: Sun, 13 Nov 2011 15:53:03 -0800 From: Erich Weiler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: grenville armitage References: <4EC033B7.5080609@soe.ucsc.edu> <4EC0395C.3030302@swin.edu.au> <4EC055CB.40100@soe.ucsc.edu> In-Reply-To: <4EC055CB.40100@soe.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Arg. TCP slow start killing me. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 23:53:03 -0000 > I suspect my firewall *is* the cause of the packet loss, unfortunately. > We're sending multiple streams in from multiple sources and > destinations, but the aggregate bandwidth coming into the firewall is > consistent no matter how many sources and destinations we have. It maxes > at about 2Gb/s. That's why I was trying to tweak the firewall, to try > and get that number up. Sorry, to be clear, the *average* bandwidth was like 2Gb/s, I'm really trying to dodge the sawtooth traffic pattern in some way, I see it go up to 3Gb/s every once in a while. I was hoping to achieve getting closer to 3Gb/s on average by adding buffers to my firewall, but maybe that isn't the answer... I tried Jason's suggestions earlier but it didn't seem to help much unfortunately. From owner-freebsd-net@FreeBSD.ORG Mon Nov 14 00:02:03 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72B0E106564A for ; Mon, 14 Nov 2011 00:02:03 +0000 (UTC) (envelope-from nitroboost@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 322F68FC13 for ; Mon, 14 Nov 2011 00:02:02 +0000 (UTC) Received: by gyd5 with SMTP id 5so6141929gyd.13 for ; Sun, 13 Nov 2011 16:02:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n98DWDMKQCHsRbbpXNSdH0CGWVkgEX8JOV7PzdSw/Bg=; b=V5x/jhGa92AhfV9MbamLddABviG37tGXXoqIjGrJdwZsDH5kEIXZ7tHWAHfiA0jlU9 8v1CtUkSktsbrv221JmfGrWoHvut65Q5y1v74vlQBXDbqzC07YYiGwU+fP21hbXDZ6ZN gvaALSHCmuvXRr1FeuAQ4i6TouhkA+KliLrW0= MIME-Version: 1.0 Received: by 10.182.108.100 with SMTP id hj4mr4520592obb.34.1321228922297; Sun, 13 Nov 2011 16:02:02 -0800 (PST) Received: by 10.182.30.164 with HTTP; Sun, 13 Nov 2011 16:02:02 -0800 (PST) In-Reply-To: <4EC0585F.5000104@soe.ucsc.edu> References: <4EC033B7.5080609@soe.ucsc.edu> <4EC0395C.3030302@swin.edu.au> <4EC055CB.40100@soe.ucsc.edu> <4EC0585F.5000104@soe.ucsc.edu> Date: Sun, 13 Nov 2011 17:02:02 -0700 Message-ID: From: Jason Wolfe To: Erich Weiler Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, grenville armitage Subject: Re: Arg. TCP slow start killing me. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 00:02:03 -0000 On Sun, Nov 13, 2011 at 4:53 PM, Erich Weiler wrote: > I suspect my firewall *is* the cause of the packet loss, unfortunately. >> We're sending multiple streams in from multiple sources and >> destinations, but the aggregate bandwidth coming into the firewall is >> consistent no matter how many sources and destinations we have. It maxes >> at about 2Gb/s. That's why I was trying to tweak the firewall, to try >> and get that number up. >> > > Sorry, to be clear, the *average* bandwidth was like 2Gb/s, I'm really > trying to dodge the sawtooth traffic pattern in some way, I see it go up to > 3Gb/s every once in a while. I was hoping to achieve getting closer to > 3Gb/s on average by adding buffers to my firewall, but maybe that isn't the > answer... > > I tried Jason's suggestions earlier but it didn't seem to help much > unfortunately. Yeah, skimming fail, I didn't realize the machine was not the termination point of your connections. I do have patches back ported that would likely get the modular congestion control working on 8.1, but neither my suggestions nor the implementation of Cubic will help much as mentioned. Jason From owner-freebsd-net@FreeBSD.ORG Mon Nov 14 00:22:49 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 028361065675 for ; Mon, 14 Nov 2011 00:22:49 +0000 (UTC) (envelope-from weiler@soe.ucsc.edu) Received: from mail-01.cse.ucsc.edu (mail-01.cse.ucsc.edu [128.114.48.32]) by mx1.freebsd.org (Postfix) with ESMTP id E22CA8FC14 for ; Mon, 14 Nov 2011 00:22:48 +0000 (UTC) Received: from erich-weilers-macbook-pro.local (50-0-69-3.dsl.static.fusionbroadband.com [50.0.69.3]) by mail-01.cse.ucsc.edu (Postfix) with ESMTPSA id B3D1A1009CAB; Sun, 13 Nov 2011 16:22:48 -0800 (PST) Message-ID: <4EC05F58.1050103@soe.ucsc.edu> Date: Sun, 13 Nov 2011 16:22:48 -0800 From: Erich Weiler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Jason Wolfe References: <4EC033B7.5080609@soe.ucsc.edu> <4EC0395C.3030302@swin.edu.au> <4EC055CB.40100@soe.ucsc.edu> <4EC0585F.5000104@soe.ucsc.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, grenville armitage Subject: Re: Arg. TCP slow start killing me. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 00:22:49 -0000 > Yeah, skimming fail, I didn't realize the machine was not the > termination point of your connections. I do have patches back ported > that would likely get the modular congestion control working on 8.1, > but neither my suggestions nor the implementation of Cubic will help > much as mentioned. Given that my firewall is simply forwarding packets in and out, and is not an endpoint, does anyone think tuning up buffers would help here? If so, which buffers/sysctl parameters would be worth trying? Thanks for the help everyone! From owner-freebsd-net@FreeBSD.ORG Mon Nov 14 00:33:12 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62ADE106566B for ; Mon, 14 Nov 2011 00:33:12 +0000 (UTC) (envelope-from weiler@soe.ucsc.edu) Received: from mail-01.cse.ucsc.edu (mail-01.cse.ucsc.edu [128.114.48.32]) by mx1.freebsd.org (Postfix) with ESMTP id 4E36F8FC19 for ; Mon, 14 Nov 2011 00:33:12 +0000 (UTC) Received: from erich-weilers-macbook-pro.local (50-0-69-3.dsl.static.fusionbroadband.com [50.0.69.3]) by mail-01.cse.ucsc.edu (Postfix) with ESMTPSA id 1E09D1009CD1; Sun, 13 Nov 2011 16:33:12 -0800 (PST) Message-ID: <4EC061C7.1040406@soe.ucsc.edu> Date: Sun, 13 Nov 2011 16:33:11 -0800 From: Erich Weiler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Jason Wolfe References: <4EC033B7.5080609@soe.ucsc.edu> <4EC0395C.3030302@swin.edu.au> <4EC055CB.40100@soe.ucsc.edu> <4EC0585F.5000104@soe.ucsc.edu> <4EC05F58.1050103@soe.ucsc.edu> In-Reply-To: <4EC05F58.1050103@soe.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, grenville armitage Subject: Re: Arg. TCP slow start killing me. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 00:33:12 -0000 Actually, another question might be: How can I prove that my firewall really is dropping packets in transit, as it forwards them on? Is there some sysctl oid that would show dropped packets, so some netstat counter I can look at? On 11/13/11 4:22 PM, Erich Weiler wrote: >> Yeah, skimming fail, I didn't realize the machine was not the >> termination point of your connections. I do have patches back ported >> that would likely get the modular congestion control working on 8.1, >> but neither my suggestions nor the implementation of Cubic will help >> much as mentioned. > > Given that my firewall is simply forwarding packets in and out, and is > not an endpoint, does anyone think tuning up buffers would help here? If > so, which buffers/sysctl parameters would be worth trying? > > Thanks for the help everyone! > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Nov 14 01:45:54 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB831106564A for ; Mon, 14 Nov 2011 01:45:54 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 7DA488FC14 for ; Mon, 14 Nov 2011 01:45:54 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id pAE1jpL0060448 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 13 Nov 2011 17:45:52 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4EC072CB.5030800@freebsd.org> Date: Sun, 13 Nov 2011 17:45:47 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.24) Gecko/20111103 Thunderbird/3.1.16 MIME-Version: 1.0 To: Erich Weiler References: <4EC033B7.5080609@soe.ucsc.edu> <4EC0395C.3030302@swin.edu.au> <4EC055CB.40100@soe.ucsc.edu> <4EC0585F.5000104@soe.ucsc.edu> <4EC05F58.1050103@soe.ucsc.edu> In-Reply-To: <4EC05F58.1050103@soe.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Jason Wolfe , grenville armitage Subject: Re: Arg. TCP slow start killing me. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 01:45:54 -0000 On 11/13/11 4:22 PM, Erich Weiler wrote: >> Yeah, skimming fail, I didn't realize the machine was not the >> termination point of your connections. I do have patches back ported >> that would likely get the modular congestion control working on 8.1, >> but neither my suggestions nor the implementation of Cubic will help >> much as mentioned. > > Given that my firewall is simply forwarding packets in and out, and > is not an endpoint, does anyone think tuning up buffers would help > here? If so, which buffers/sysctl parameters would be worth trying? I can not answer abut pf but I'll say that if I were using ipfw I would use dummynet to rate linit the speed that the incoming packets were passed on to the client macjines and I would make that limit just alittle slower than the incoming link's real speed. that way the linit would be In my machine instead of in my ISPs machines. If pf has a similar mechanism to dummy net then you may be able to try that. > > Thanks for the help everyone! > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Nov 14 03:15:19 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42B141065672 for ; Mon, 14 Nov 2011 03:15:19 +0000 (UTC) (envelope-from bsd@xerq.net) Received: from cartman.xerq.net (cartman.xerq.net [67.52.126.46]) by mx1.freebsd.org (Postfix) with ESMTP id 1C1878FC13 for ; Mon, 14 Nov 2011 03:15:18 +0000 (UTC) Received: from cartman.xerq.net (unknown [127.52.126.46]) by cartman.xerq.net (Postfix) with ESMTP id 62935569D9 for ; Sun, 13 Nov 2011 18:59:00 -0800 (PST) Received: from cartman.xerq.net ([127.52.126.46]) by cartman.xerq.net (cartman.xerq.net [127.52.126.46]) (amavisd-new, port 10024) with ESMTP id oz_NCe7nIaKd for ; Sun, 13 Nov 2011 18:58:54 -0800 (PST) Received: from www1.xerq.net (localhost [127.52.126.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by cartman.xerq.net (Postfix) with ESMTPSA id 00595569B5 for ; Sun, 13 Nov 2011 18:58:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 13 Nov 2011 18:58:53 -0800 From: Matt Connor To: In-Reply-To: <4EC072CB.5030800@freebsd.org> References: <4EC033B7.5080609@soe.ucsc.edu> "<4EC0395C.3030302@swin.edu.au>" <4EC055CB.40100@soe.ucsc.edu> "<4EC0585F.5000104@soe.ucsc.edu>" <4EC05F58.1050103@soe.ucsc.edu> <4EC072CB.5030800@freebsd.org> Message-ID: <9898624e64a38e5e860591d194ec5c70@www1.xerq.net> X-Sender: bsd@xerq.net User-Agent: XERQ Webmail/0.6 Subject: Re: Arg. TCP slow start killing me. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 03:15:19 -0000 On 13.11.2011 17:45, Julian Elischer wrote: > On 11/13/11 4:22 PM, Erich Weiler wrote: >>> Yeah, skimming fail, I didn't realize the machine was not the >>> termination point of your connections. I do have patches back >>> ported >>> that would likely get the modular congestion control working on >>> 8.1, >>> but neither my suggestions nor the implementation of Cubic will >>> help >>> much as mentioned. >> >> Given that my firewall is simply forwarding packets in and out, and >> is not an endpoint, does anyone think tuning up buffers would help >> here? If so, which buffers/sysctl parameters would be worth trying? > > I can not answer abut pf but I'll say that if I were using ipfw I > would use dummynet to rate linit the speed that the incoming packets > were passed on to the client macjines and I would make that limit > just > alittle slower than the incoming link's real speed. > that way the linit would be In my machine instead of in my ISPs > machines. > > If pf has a similar mechanism to dummy net then you may be able to > try that. > Have you considered empty ACK prioritization? I implemented this a year ago on a pair of production edge routers and noticed significant improvement on throughput. I have production code examples if you require them, but this link should be more than enough to get you started: http://www.benzedrine.cx/ackpri.html -Matt From owner-freebsd-net@FreeBSD.ORG Mon Nov 14 04:25:31 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B22BB10656B7 for ; Mon, 14 Nov 2011 04:25:31 +0000 (UTC) (envelope-from remy.sanchez@hyperthese.net) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by mx1.freebsd.org (Postfix) with ESMTP id 6A8788FC21 for ; Mon, 14 Nov 2011 04:25:31 +0000 (UTC) Received: from magi.localnet (unknown [IPv6:2a01:e35:2e3d:8820:21f:16ff:feb6:9aac]) (Authenticated sender: remy.sanchez@hyperthese.net) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id DEBC8A8AEC for ; Mon, 14 Nov 2011 05:25:19 +0100 (CET) From: =?iso-8859-1?q?R=E9my_Sanchez?= To: freebsd-net@freebsd.org Date: Mon, 14 Nov 2011 05:24:58 +0100 User-Agent: KMail/1.13.7 (Linux/3.0.0-2-amd64; KDE/4.6.5; x86_64; ; ) References: <4EC033B7.5080609@soe.ucsc.edu> <4EC05F58.1050103@soe.ucsc.edu> <4EC061C7.1040406@soe.ucsc.edu> In-Reply-To: <4EC061C7.1040406@soe.ucsc.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2703490.FKZ5JMMmkU"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201111140525.14450.remy.sanchez@hyperthese.net> Subject: Re: Arg. TCP slow start killing me. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 04:25:31 -0000 --nextPart2703490.FKZ5JMMmkU Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Monday 14 November 2011 01:33:11 Erich Weiler wrote: > Actually, another question might be: How can I prove that my firewall=20 > really is dropping packets in transit, as it forwards them on? Is there= =20 > some sysctl oid that would show dropped packets, so some netstat counter= =20 > I can look at? I'll say something stupid, but in the worst case just use tcpdump to captur= e=20 both of your interfaces, and then compare them, one way or the other... A quick google of "pcap diff" gives some results, like=20 http://sourceforge.net/projects/tpcat/ =2D-=20 R=E9my Sanchez http://hyperthese.net/ --nextPart2703490.FKZ5JMMmkU Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk7AmBoACgkQpMMQ4XyIN1ZOAwCeNmnLakJLy8fl+vXl8NY9hMIK XugAoKbrZl63Ol1d3iGeSaNwBduJvU5W =TTnU -----END PGP SIGNATURE----- --nextPart2703490.FKZ5JMMmkU-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 14 05:37:01 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91B4A106566C for ; Mon, 14 Nov 2011 05:37:01 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 47C318FC0C for ; Mon, 14 Nov 2011 05:37:00 +0000 (UTC) Received: by gyd5 with SMTP id 5so6363023gyd.13 for ; Sun, 13 Nov 2011 21:37:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=D1b+wBCoJN7LwrZ/fT/UJZ+6EYKYjd1q1z6DOuhx45Q=; b=tLpLf3uB/Zm9Ed3FyTU1JPS1SWzifCoxrlq0dCHnCBR84L6+zqpSLOZx1xDVvQrcZi 0Iku4My98SNVD5MJvz5sde1wpWj8Y6zY9sAZUrjpy9Z+tuG+1xAt6OTh+0J4tQAP3M/e u+CUasrlI3QQfGTEfpZX9FyYvdO9mIH4A/mcg= Received: by 10.236.180.200 with SMTP id j48mr11877279yhm.26.1321248600297; Sun, 13 Nov 2011 21:30:00 -0800 (PST) Received: from DataIX.net (adsl-99-35-12-148.dsl.klmzmi.sbcglobal.net. [99.35.12.148]) by mx.google.com with ESMTPS id 4sm58121855ano.9.2011.11.13.21.29.58 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Nov 2011 21:29:58 -0800 (PST) Sender: Jason Hellenthal Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id pAE5TuFM048886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Nov 2011 00:29:56 -0500 (EST) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id pAE5TtCg048885; Mon, 14 Nov 2011 00:29:55 -0500 (EST) (envelope-from jhell@DataIX.net) Date: Mon, 14 Nov 2011 00:29:55 -0500 From: Jason Hellenthal To: Erich Weiler Message-ID: <20111114052955.GB46977@DataIX.net> References: <4EC033B7.5080609@soe.ucsc.edu> <4EC05511.1080102@soe.ucsc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EC05511.1080102@soe.ucsc.edu> Cc: freebsd-net@freebsd.org, Jason Wolfe Subject: Re: Arg. TCP slow start killing me. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 05:37:01 -0000 Sorry this is a little more proper of a thread. http://freebsd.1045724.n5.nabble.com/The-tale-of-a-TCP-bug-td4262914.html On Sun, Nov 13, 2011 at 03:38:57PM -0800, Erich Weiler wrote: > Thanks Jason! > > > Is it possible to upgrade to 8.2-STABLE? Cubic has shown some really > > great improvement in my latent paths, a steady 10% overall increase in > > same cases. > > Alas no, my OS is a pre-baked install for pfSense, and if I tried to > upgrade it, it would likely break some of the functionality of how > pfSense is built. I've considered patching in some kernel mods to add > cubic and H-TCP to the kernel, but even that makes me nervous. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Nov 14 05:47:44 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCE76106566C for ; Mon, 14 Nov 2011 05:47:44 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 933A38FC08 for ; Mon, 14 Nov 2011 05:47:44 +0000 (UTC) Received: by yenl11 with SMTP id l11so948344yen.13 for ; Sun, 13 Nov 2011 21:47:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=GcSOoT9GlcjGVZwMjOt9vJzfEDCg2J4C2SjG9YpyUJ8=; b=XC2MDYxgAQvsVT+9XBpw0gzKBw5POZqtoiNUz9PQ0hf3omExc+IM6Te8QCoDmEDxxB vtZNkkLp/62jv7HYlQX2hJMzd4cBsrXFuRlTd+OK+LtONwUE5LQbOiHmCcAsu+OcSWTF yCW83e3vhZjNM9jP8vreg6yaBfV6XHtZ04oFs= Received: by 10.236.168.2 with SMTP id j2mr3430277yhl.10.1321248128676; Sun, 13 Nov 2011 21:22:08 -0800 (PST) Received: from DataIX.net (adsl-99-35-12-148.dsl.klmzmi.sbcglobal.net. [99.35.12.148]) by mx.google.com with ESMTPS id v5sm58096984anf.3.2011.11.13.21.22.06 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Nov 2011 21:22:07 -0800 (PST) Sender: Jason Hellenthal Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id pAE5M4ta048632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Nov 2011 00:22:04 -0500 (EST) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id pAE5M4EZ048631; Mon, 14 Nov 2011 00:22:04 -0500 (EST) (envelope-from jhell@DataIX.net) Date: Mon, 14 Nov 2011 00:22:04 -0500 From: Jason Hellenthal To: Erich Weiler Message-ID: <20111114052204.GA46977@DataIX.net> References: <4EC033B7.5080609@soe.ucsc.edu> <4EC05511.1080102@soe.ucsc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EC05511.1080102@soe.ucsc.edu> Cc: freebsd-net@freebsd.org, Jason Wolfe Subject: Re: Arg. TCP slow start killing me. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 05:47:44 -0000 Have you considered this thread ? A Tale of a TCP bug... http://lists.freebsd.org/pipermail/freebsd-net/2011-April/028448.html This was fixed in 8-STABLE before 8.2 release but after 8.1-RELEASE. A pcap dump of the traffic at the routing end and the recieving end might just reveal this as the cause. On Sun, Nov 13, 2011 at 03:38:57PM -0800, Erich Weiler wrote: > Thanks Jason! > > > Is it possible to upgrade to 8.2-STABLE? Cubic has shown some really > > great improvement in my latent paths, a steady 10% overall increase in > > same cases. > > Alas no, my OS is a pre-baked install for pfSense, and if I tried to > upgrade it, it would likely break some of the functionality of how > pfSense is built. I've considered patching in some kernel mods to add > cubic and H-TCP to the kernel, but even that makes me nervous. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Nov 14 06:54:45 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA14D106564A for ; Mon, 14 Nov 2011 06:54:45 +0000 (UTC) (envelope-from weiler@soe.ucsc.edu) Received: from mail-01.cse.ucsc.edu (mail-01.cse.ucsc.edu [128.114.48.32]) by mx1.freebsd.org (Postfix) with ESMTP id B35998FC14 for ; Mon, 14 Nov 2011 06:54:45 +0000 (UTC) Received: from erich-weilers-macbook-pro.local (50-0-69-3.dsl.static.fusionbroadband.com [50.0.69.3]) by mail-01.cse.ucsc.edu (Postfix) with ESMTPSA id 5B97C1009C69; Sun, 13 Nov 2011 22:54:45 -0800 (PST) Message-ID: <4EC0BB34.3020600@soe.ucsc.edu> Date: Sun, 13 Nov 2011 22:54:44 -0800 From: Erich Weiler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Matt Connor References: <4EC033B7.5080609@soe.ucsc.edu> "<4EC0395C.3030302@swin.edu.au>" <4EC055CB.40100@soe.ucsc.edu> "<4EC0585F.5000104@soe.ucsc.edu>" <4EC05F58.1050103@soe.ucsc.edu> <4EC072CB.5030800@freebsd.org> <9898624e64a38e5e860591d194ec5c70@www1.xerq.net> In-Reply-To: <9898624e64a38e5e860591d194ec5c70@www1.xerq.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Arg. TCP slow start killing me. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 06:54:45 -0000 > Have you considered empty ACK prioritization? I implemented this a year > ago on a pair of production edge routers and noticed significant > improvement on throughput. I have production code examples if you > require them, but this link should be more than enough to get you started: Fascinating. pfSense does have traffic shaping options, among them ACK prioritization and queues. Let me play with that a bit. Totally could be affecting me - my downstream traffic could be great enough to crows out ACKs, thus causing the TCP stream resets. Sounds plausible, at least. From owner-freebsd-net@FreeBSD.ORG Mon Nov 14 06:58:27 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2A1F1065670 for ; Mon, 14 Nov 2011 06:58:27 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 823128FC0A for ; Mon, 14 Nov 2011 06:58:27 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id pAE6wPb9061362 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 13 Nov 2011 22:58:26 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4EC0BC0D.9060608@freebsd.org> Date: Sun, 13 Nov 2011 22:58:21 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.24) Gecko/20111103 Thunderbird/3.1.16 MIME-Version: 1.0 To: Erich Weiler References: <4EC033B7.5080609@soe.ucsc.edu> "<4EC0395C.3030302@swin.edu.au>" <4EC055CB.40100@soe.ucsc.edu> "<4EC0585F.5000104@soe.ucsc.edu>" <4EC05F58.1050103@soe.ucsc.edu> <4EC072CB.5030800@freebsd.org> <9898624e64a38e5e860591d194ec5c70@www1.xerq.net> <4EC0BB34.3020600@soe.ucsc.edu> In-Reply-To: <4EC0BB34.3020600@soe.ucsc.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Matt Connor Subject: Re: Arg. TCP slow start killing me. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 06:58:27 -0000 On 11/13/11 10:54 PM, Erich Weiler wrote: >> Have you considered empty ACK prioritization? I implemented this a >> year >> ago on a pair of production edge routers and noticed significant >> improvement on throughput. I have production code examples if you >> require them, but this link should be more than enough to get you >> started: > > Fascinating. pfSense does have traffic shaping options, among them > ACK prioritization and queues. Let me play with that a bit. > Totally could be affecting me - my downstream traffic could be great > enough to crowd out ACKs, thus causing the TCP stream resets. > Sounds plausible, at least. As I said before, try shaping traffic in each direction to be just a little less than what the other limits (e.g. your link) might be. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Nov 14 09:14:38 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACC61106566C for ; Mon, 14 Nov 2011 09:14:38 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 754A28FC14 for ; Mon, 14 Nov 2011 09:14:38 +0000 (UTC) Received: by iakl21 with SMTP id l21so8136292iak.13 for ; Mon, 14 Nov 2011 01:14:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TdDcRA4joMznl8Gkbtm/lfE8wOIOkSUkSh27YyIElAE=; b=LtKctCsEozLS66QLIHodcQIsOdnS3NQjJWk37Ep4SUNH+gxaxJq6vrtsMim9XyFpUj vQlYX895qjur8Se7oYPzczIXUcPmDhEsWOsjSKv60IX1Sf9dH1crOTMcbS2bsQkA59hw B6RhKWM/qK2ltQdobG8uUVuh4LqNJlWdxDvRg= MIME-Version: 1.0 Received: by 10.42.153.6 with SMTP id k6mr21710654icw.30.1321260618122; Mon, 14 Nov 2011 00:50:18 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.231.53.213 with HTTP; Mon, 14 Nov 2011 00:50:18 -0800 (PST) In-Reply-To: <4EC0BB34.3020600@soe.ucsc.edu> References: <4EC033B7.5080609@soe.ucsc.edu> <4EC0395C.3030302@swin.edu.au> <4EC055CB.40100@soe.ucsc.edu> <4EC0585F.5000104@soe.ucsc.edu> <4EC05F58.1050103@soe.ucsc.edu> <4EC072CB.5030800@freebsd.org> <9898624e64a38e5e860591d194ec5c70@www1.xerq.net> <4EC0BB34.3020600@soe.ucsc.edu> Date: Mon, 14 Nov 2011 09:50:18 +0100 X-Google-Sender-Auth: 4jTqANC4qnaxOCOKXvGeV3B4a6g Message-ID: From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Erich Weiler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Matt Connor Subject: Re: Arg. TCP slow start killing me. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 09:14:38 -0000 On Mon, Nov 14, 2011 at 7:54 AM, Erich Weiler wrote: >> Have you considered empty ACK prioritization? I implemented this a year >> ago on a pair of production edge routers and noticed significant >> improvement on throughput. I have production code examples if you >> require them, but this link should be more than enough to get you starte= d: > > Fascinating. =A0pfSense does have traffic shaping options, among them ACK > prioritization and queues. =A0Let me play with that a bit. =A0Totally cou= ld be > affecting me - my downstream traffic could be great enough to crows out > ACKs, thus causing the TCP stream resets. =A0Sounds plausible, at least. pfSense has dummynet and ACK prioritization that can help here though i think before implementing a fix you should find the cause to fix! --=20 Ermal From owner-freebsd-net@FreeBSD.ORG Mon Nov 14 11:07:12 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88FDE1065674 for ; Mon, 14 Nov 2011 11:07:12 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7734B8FC2B for ; Mon, 14 Nov 2011 11:07:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pAEB7CNx083581 for ; Mon, 14 Nov 2011 11:07:12 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pAEB7Bd1083579 for freebsd-net@FreeBSD.org; Mon, 14 Nov 2011 11:07:11 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 14 Nov 2011 11:07:11 GMT Message-Id: <201111141107.pAEB7Bd1083579@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 11:07:12 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/162509 net [re] [panic] Kernel panic may be related to if_re.c (r o kern/162352 net [patch] Enhancement: add SO_PROTO to socket.h o kern/162201 net [ip] [patch] multicast forwarding cache hash always al o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161908 net [netgraph] [patch] ng_vlan update for QinQ support o kern/161899 net [route] ntpd(8): Repeating RTM_MISS packets causing hi o kern/161381 net [re] RTL8169SC - re0: PHY write failed o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160420 net [msk] phy write timeout on HP 5310m o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159795 net [tcp] excessive duplicate ACKs and TCP session freezes o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157429 net [re] Realtek RTL8169 doesn't work with re(4) o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155604 net [flowtable] Flowtable excessively caches dest MAC addr o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/155004 net [bce] [panic] kernel panic in bce0 driver o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o bin/145934 net [patch] add count option to netstat(1) o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123045 net [ng_mppc] ng_mppc_decompress - disabling node o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 382 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Nov 14 17:16:59 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33743106564A; Mon, 14 Nov 2011 17:16:59 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id E412E8FC14; Mon, 14 Nov 2011 17:16:58 +0000 (UTC) Received: by iakl21 with SMTP id l21so8796747iak.13 for ; Mon, 14 Nov 2011 09:16:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Dv7M+CqQxKvN1c31QDjV0ko7A1kqeazyooGeF7oXdvY=; b=cLmqVJ6qliikgY5/at8JCrlH49Tjj3S387iwh2H5nYOQSKK4pfoX4plbijz4s5lcp7 z72qzG9mqihiwkk1Jkp64u5LtSAaEsejV+/2PVxjhjRvNOor1HhuBgWL65AoHjBcKaX/ ZqWDm/NN3IS2udIcDl/Es8uZ5ihsWti9MFlU8= MIME-Version: 1.0 Received: by 10.231.9.40 with SMTP id j40mr5489481ibj.59.1321291018460; Mon, 14 Nov 2011 09:16:58 -0800 (PST) Received: by 10.231.32.12 with HTTP; Mon, 14 Nov 2011 09:16:58 -0800 (PST) In-Reply-To: <4EBDA4B2.6030602@FreeBSD.org> References: <4EBDA4B2.6030602@FreeBSD.org> Date: Mon, 14 Nov 2011 19:16:58 +0200 Message-ID: From: Sami Halabi To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net , David Hooton Subject: Re: MPD LAC Scaling X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 17:16:59 -0000 Hi, i wonder why not putting all your suggestions on MPD instead of making hacks, as I see it its necessary for performance, after all MPD is aimed to FBSD only, so its elementary to use ke Sami 2011/11/12 Alexander Motin > Hi. > > > I'm currently evaluating MPD as a potential LAC solution for a > > project I'm working on. I'm looking to try and handle at least 4Gbit > > and 20,000 sessions worth of PPPoE -> L2TP LAC traffic per server. > > The reading I've done from the archives so far seems to indicate that > > this has not yet been done. > > I also haven't heard about so big cases, but also can't say it is > theoretically impossible after some tuning and development work. At this > point I have neither production/test environment nor much time to > actively work on it, but I want to express some experience and ideas in > case somebody wants to take that. > > First, as Julian said, it is not necessary should be one server to > handle all load. Cluster of smaller machines should be preferable from > many points. PPPoE allows you to have several servers and load-balance > them. At this moment MPD can't balance load dynamically, but you can do > it manually, limiting number of sessions per one server. > > As some example point of hardware from personal experience I can say > that three years ago mpd5 on 1U servers with single Core2Duo CPUs, 1GB > of RAM and two 1Gb NICs (less then $1K that time) handled in production > about 2000 PPPoE sessions and 600Mbps of traffic per server, including > Netflow generation, per-customer typed traffic shaping and accounting. > Modern and more powerful hardware is able to do more. > > Getting higher numbers there can mostly be split in two questions: > getting more traffic and getting more sessions, as limitations are > different. > - Getting more traffic mostly means scaling kernel Netgraph and > networking code to more CPU cores. As soon as Netgraph uses direct > function calls when possible, it depends on number of network interrupt > threads in system. Three years ago there was only one net SWI thread and > setting net.isr.direct=1 while having several NICs in system allowed to > distribute load between CPUs. Modern high-level NICs with several MSI-X > interrupts should give the same effect. Now it is also possible to have > several net SWI threads, but I haven't tested it. > - Getting more sessions also means tuning and optimizing user-level mpd > daemon. Three years ago on Pentium4-level test machine I've reached > about 5K PPPoE sessions with RADIUS auth/acct. Main limiting factor was > user-level daemon performance. The more sessions connected, the more > overhead daemon had in face of LCP echo requests and event timeouts to > handle, number of netgraph kernel sockets to listen, etc. At some point > daemon is just unable to handle all new incoming events in time and > resending requests by clients causes cumulative effect. So the main > limiting factor is not just number of users, but also number of events. > If users connect one by one, number of sessions can be quite high. But > if due to some accident you have all users dropped and reconnecting, > that may cause overload sooner. In that case it is important even what > LCP echo timeout set on the server and clients, or how many logs are > enabled. My best tuning result that time on Pentium4-level machine was > about 100 connections per second. It allowed to setup 5000 simultaneous > sessions within 50 seconds. Higher numbers were problematic. At this > moment user-level MPD's main state machine is single-threaded, except > authorization and accounting (like RADIUS), that are done in separate > threads, but require synchronized completion to return the data. > Splitting main FPM on several threads is difficult, because it would > require to somehow to group links and bundles within different threads > with different locks, that is difficult, because of multilink support > and because until user is authorized, it is impossible to say which > bundle it should join. If there is need to handle several PPPoE services > with different names or several LAN segments, it theoretically may be > effective to have several MPD daemon instances running, one for each > service/segment. Generally I've spent less time on profiling and > optimizing MPD daemon itself then kernel code, so there still should be > a lot of space for improvement. Some possible optimization points I > still remember are: > - rework pevent() engine used by MPD state machine to use kqueue() > instead of poll() to reduce event overhead overhead; > - optimize locking of paction() functions used for thread creation and > completion for MPD-specific case; Idea was that by the cost of > functionality it could be simplified to reduce number of context switches; > - rewrite RADIUS auth/acct support to run within main mpd thread or > fixed number of external threads; since existing threaded approach was > implemented, libradius got support for asynchronous operation; that > should reduce overhead for thread creation/destruction; > - optimize ng_ksocket node when work with large number of hooks, using > some optimized search, and/or make MPD to create another sockets for > each next number of links to balance kernel and user-level search > overheads; initially MPD created separate set of sockets for every link, > but it was found too expensive for user-level FSM and was rewritten into > present state with almost minimal number of sockets and most > multiplexing tone in kernel. > > I have no personal production experience with PPPoE-L2TP LAC case. It is > used much less often and I had only several reports from people actively > using it and no much numbers. I think LAC case should have smaller > overhead and CPU load and so better scalability then usual traffic > termination: there is no IPCP layer in PPP to negotiate, there is no > interfaces to create and configure, no Netflow, no shapes, no periodic > accounting, etc. If you don't need to authenticate users, but only to > forward connections, and so server doesn't need to handle LCP protocol, > task simplifies even much more. > > If you can setup test environment to stress-test the LAC stuffs, it > would be interesting to see the numbers. On my test lab I used several > machines with mpd configured for thousands of PPPoE client sessions each > to generate simultaneous connections. For testing LAC you also should > have some fast enough L2TP terminator. If you have no such hardware for > test, you may try use several systems with mpd L2TP servers spreading > load between them in one of ways to avoid bottleneck there, while system > load in such case may potentially slightly differ. > > -- > Alexander Motin > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Sami Halabi Information Systems Engineer NMS Projects Expert From owner-freebsd-net@FreeBSD.ORG Mon Nov 14 17:25:08 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DFC61065690; Mon, 14 Nov 2011 17:25:08 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1BC498FC17; Mon, 14 Nov 2011 17:25:06 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so8495635bkb.13 for ; Mon, 14 Nov 2011 09:25:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=jAvvOzRFMobXwsCljwzUhREkPJr72LuS8tPtRzSfetk=; b=RRXPVI1zrL/lo7goJ7uWwgchiS3BI0mRhROB/y201z2vnfcak4QLhO1Hw4GvQNL+7m pfy1cNF8ZpCSeZSzEvrsdxMduE4ajnki42hs1DTzq5QHkjnkubpzOVYpyWVpvEJVHphC 05URaYXOui5EVKlZu/TBn9nQxoDo9YY6A3P/0= Received: by 10.205.127.134 with SMTP id ha6mr20122959bkc.23.1321291475251; Mon, 14 Nov 2011 09:24:35 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id q6sm33599334bka.6.2011.11.14.09.24.32 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Nov 2011 09:24:33 -0800 (PST) Sender: Alexander Motin Message-ID: <4EC14ECF.6050502@FreeBSD.org> Date: Mon, 14 Nov 2011 19:24:31 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: Sami Halabi References: <4EBDA4B2.6030602@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net , David Hooton Subject: Re: MPD LAC Scaling X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 17:25:08 -0000 On 11/14/11 19:16, Sami Halabi wrote: > i wonder why not putting all your suggestions on MPD instead of making > hacks, as I see it its necessary for performance, > after all MPD is aimed to FBSD only, so its elementary to use ke I don't understand your question. What hacks are you talking about? You have some patches? Suggestions are still suggestions, because they require some work. If somebody do it well, it should be added to MPD. > 2011/11/12 Alexander Motin > > > I'm currently evaluating MPD as a potential LAC solution for a > > project I'm working on. I'm looking to try and handle at least 4Gbit > > and 20,000 sessions worth of PPPoE -> L2TP LAC traffic per server. > > The reading I've done from the archives so far seems to indicate that > > this has not yet been done. > > I also haven't heard about so big cases, but also can't say it is > theoretically impossible after some tuning and development work. At this > point I have neither production/test environment nor much time to > actively work on it, but I want to express some experience and ideas in > case somebody wants to take that. > > First, as Julian said, it is not necessary should be one server to > handle all load. Cluster of smaller machines should be preferable from > many points. PPPoE allows you to have several servers and load-balance > them. At this moment MPD can't balance load dynamically, but you can do > it manually, limiting number of sessions per one server. > > As some example point of hardware from personal experience I can say > that three years ago mpd5 on 1U servers with single Core2Duo CPUs, 1GB > of RAM and two 1Gb NICs (less then $1K that time) handled in production > about 2000 PPPoE sessions and 600Mbps of traffic per server, including > Netflow generation, per-customer typed traffic shaping and accounting. > Modern and more powerful hardware is able to do more. > > Getting higher numbers there can mostly be split in two questions: > getting more traffic and getting more sessions, as limitations are > different. > - Getting more traffic mostly means scaling kernel Netgraph and > networking code to more CPU cores. As soon as Netgraph uses direct > function calls when possible, it depends on number of network interrupt > threads in system. Three years ago there was only one net SWI thread and > setting net.isr.direct=1 while having several NICs in system allowed to > distribute load between CPUs. Modern high-level NICs with several MSI-X > interrupts should give the same effect. Now it is also possible to have > several net SWI threads, but I haven't tested it. > - Getting more sessions also means tuning and optimizing user-level mpd > daemon. Three years ago on Pentium4-level test machine I've reached > about 5K PPPoE sessions with RADIUS auth/acct. Main limiting factor was > user-level daemon performance. The more sessions connected, the more > overhead daemon had in face of LCP echo requests and event timeouts to > handle, number of netgraph kernel sockets to listen, etc. At some point > daemon is just unable to handle all new incoming events in time and > resending requests by clients causes cumulative effect. So the main > limiting factor is not just number of users, but also number of events. > If users connect one by one, number of sessions can be quite high. But > if due to some accident you have all users dropped and reconnecting, > that may cause overload sooner. In that case it is important even what > LCP echo timeout set on the server and clients, or how many logs are > enabled. My best tuning result that time on Pentium4-level machine was > about 100 connections per second. It allowed to setup 5000 simultaneous > sessions within 50 seconds. Higher numbers were problematic. At this > moment user-level MPD's main state machine is single-threaded, except > authorization and accounting (like RADIUS), that are done in separate > threads, but require synchronized completion to return the data. > Splitting main FPM on several threads is difficult, because it would > require to somehow to group links and bundles within different threads > with different locks, that is difficult, because of multilink support > and because until user is authorized, it is impossible to say which > bundle it should join. If there is need to handle several PPPoE services > with different names or several LAN segments, it theoretically may be > effective to have several MPD daemon instances running, one for each > service/segment. Generally I've spent less time on profiling and > optimizing MPD daemon itself then kernel code, so there still should be > a lot of space for improvement. Some possible optimization points I > still remember are: > - rework pevent() engine used by MPD state machine to use kqueue() > instead of poll() to reduce event overhead overhead; > - optimize locking of paction() functions used for thread creation and > completion for MPD-specific case; Idea was that by the cost of > functionality it could be simplified to reduce number of context > switches; > - rewrite RADIUS auth/acct support to run within main mpd thread or > fixed number of external threads; since existing threaded approach was > implemented, libradius got support for asynchronous operation; that > should reduce overhead for thread creation/destruction; > - optimize ng_ksocket node when work with large number of hooks, using > some optimized search, and/or make MPD to create another sockets for > each next number of links to balance kernel and user-level search > overheads; initially MPD created separate set of sockets for every link, > but it was found too expensive for user-level FSM and was rewritten into > present state with almost minimal number of sockets and most > multiplexing tone in kernel. > > I have no personal production experience with PPPoE-L2TP LAC case. It is > used much less often and I had only several reports from people actively > using it and no much numbers. I think LAC case should have smaller > overhead and CPU load and so better scalability then usual traffic > termination: there is no IPCP layer in PPP to negotiate, there is no > interfaces to create and configure, no Netflow, no shapes, no periodic > accounting, etc. If you don't need to authenticate users, but only to > forward connections, and so server doesn't need to handle LCP protocol, > task simplifies even much more. > > If you can setup test environment to stress-test the LAC stuffs, it > would be interesting to see the numbers. On my test lab I used several > machines with mpd configured for thousands of PPPoE client sessions each > to generate simultaneous connections. For testing LAC you also should > have some fast enough L2TP terminator. If you have no such hardware for > test, you may try use several systems with mpd L2TP servers spreading > load between them in one of ways to avoid bottleneck there, while system > load in such case may potentially slightly differ. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Mon Nov 14 19:11:07 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2070F1065672; Mon, 14 Nov 2011 19:11:07 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EDC0E8FC19; Mon, 14 Nov 2011 19:11:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pAEJB6fr035987; Mon, 14 Nov 2011 19:11:06 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pAEJB69E035976; Mon, 14 Nov 2011 19:11:06 GMT (envelope-from linimon) Date: Mon, 14 Nov 2011 19:11:06 GMT Message-Id: <201111141911.pAEJB69E035976@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/162558: [dummynet] [panic] seldom dummynet panics X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 19:11:07 -0000 Old Synopsis: [panic] seldom dummynet panics New Synopsis: [dummynet] [panic] seldom dummynet panics Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Nov 14 19:10:55 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=162558 From owner-freebsd-net@FreeBSD.ORG Tue Nov 15 00:20:38 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A624106566C for ; Tue, 15 Nov 2011 00:20:38 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 16DF88FC13 for ; Tue, 15 Nov 2011 00:20:37 +0000 (UTC) Received: by iakl21 with SMTP id l21so9389301iak.13 for ; Mon, 14 Nov 2011 16:20:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=F04YehH41U+RKDdMzzAt5zKhDF5ajQky9Bgh9g5eihU=; b=ifM711ks0YgWPIJNcCa+UU+40qXDqrnLqrhnSKEw6tRC42HVfOBzP8zMOx1+R1Ft+C 9JmI/Haz4cpnuRfS0fHaEJTimw8SCYorVZ3bjZNDUgUV6K2NPj+qyVvctLpDqG3UNkC5 Byk3sC+OwveH5Zrg6IAfML7fS4Cev2fI+U0Fk= Received: by 10.42.159.1 with SMTP id j1mr25075577icx.20.1321316437504; Mon, 14 Nov 2011 16:20:37 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id p16sm32362596ibk.6.2011.11.14.16.20.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Nov 2011 16:20:36 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 14 Nov 2011 16:18:36 -0800 From: YongHyeon PYUN Date: Mon, 14 Nov 2011 16:18:36 -0800 To: Michael =?iso-8859-1?B?TGHf?= Message-ID: <20111115001836.GB3901@michelle.cdnetworks.com> References: <1320494003.19667.41.camel@bevan-pc.fritz.box> <20111106234054.GB1906@michelle.cdnetworks.com> <20111107175953.GA1646@michelle.cdnetworks.com> <1321046480.8512.3.camel@bevan-pc.fritz.box> <20111111235526.GC17792@michelle.cdnetworks.com> <1321101868.8512.11.camel@bevan-pc.fritz.box> <1321106653.4734.4.camel@bevan-pc.fritz.box> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1321106653.4734.4.camel@bevan-pc.fritz.box> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Gigabit Ethernet performance with Realtek 8111E X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 00:20:38 -0000 On Sat, Nov 12, 2011 at 03:04:13PM +0100, Michael La?? wrote: > I should have tried this earlier: > > When using Windows instead of Linux on the other host I don't have any > problems. I'm getting a constant transfer rate of over 500Mbit/s without > a single frame missed on the freebsd-machine. > > So maybe this problem is more related to the ATL1E driver in the linux > kernel. > Hmm, it smells like GSO/TSO related issue of Linux ATL1E driver to me. Would you turn both features OFF on Linux box and try it again? From owner-freebsd-net@FreeBSD.ORG Tue Nov 15 14:50:08 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1017D106566B for ; Tue, 15 Nov 2011 14:50:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DA4058FC12 for ; Tue, 15 Nov 2011 14:50:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pAFEo7oR060798 for ; Tue, 15 Nov 2011 14:50:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pAFEo7vg060797; Tue, 15 Nov 2011 14:50:07 GMT (envelope-from gnats) Date: Tue, 15 Nov 2011 14:50:07 GMT Message-Id: <201111151450.pAFEo7vg060797@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Jukka A. Ukkonen" Cc: Subject: Re: kern/162352: [patch] Enhancement: add SO_PROTO to socket.h X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Jukka A. Ukkonen" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 14:50:08 -0000 The following reply was made to PR kern/162352; it has been noted by GNATS. From: "Jukka A. Ukkonen" To: bug-followup@FreeBSD.org, jau@iki.fi Cc: Subject: Re: kern/162352: [patch] Enhancement: add SO_PROTO to socket.h Date: Tue, 15 Nov 2011 16:46:55 +0200 Apparently also HP-UX uses the name SO_PROTOTYPE, though, with a somewhat odd twist. A comment in implies that in HP-UX this option could be used with setsockopt() to push another protocol to a raw socket. --jau From owner-freebsd-net@FreeBSD.ORG Tue Nov 15 19:07:35 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AA82106564A for ; Tue, 15 Nov 2011 19:07:35 +0000 (UTC) (envelope-from bevan@bi-co.net) Received: from tomahna.bi-co.net (tomahna.bi-co.net [178.77.99.158]) by mx1.freebsd.org (Postfix) with ESMTP id 3E5248FC13 for ; Tue, 15 Nov 2011 19:07:32 +0000 (UTC) Received: (qmail 31790 invoked from network); 15 Nov 2011 20:07:30 +0100 Received: from ip-109-91-30-235.unitymediagroup.de (HELO ?192.168.178.21?) (109.91.30.235) by tomahna.bi-co.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 15 Nov 2011 20:07:30 +0100 Message-ID: <1321384054.23819.14.camel@bevan-pc.fritz.box> From: Michael =?ISO-8859-1?Q?La=DF?= To: pyunyh@gmail.com Date: Tue, 15 Nov 2011 20:07:34 +0100 In-Reply-To: <20111115001836.GB3901@michelle.cdnetworks.com> References: <1320494003.19667.41.camel@bevan-pc.fritz.box> <20111106234054.GB1906@michelle.cdnetworks.com> <20111107175953.GA1646@michelle.cdnetworks.com> <1321046480.8512.3.camel@bevan-pc.fritz.box> <20111111235526.GC17792@michelle.cdnetworks.com> <1321101868.8512.11.camel@bevan-pc.fritz.box> <1321106653.4734.4.camel@bevan-pc.fritz.box> <20111115001836.GB3901@michelle.cdnetworks.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.1 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: freebsd-net@freebsd.org Subject: Re: Gigabit Ethernet performance with Realtek 8111E X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bevan@bi-co.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 19:07:35 -0000 Hi! Am Montag, den 14.11.2011, 16:18 -0800 schrieb YongHyeon PYUN: > Hmm, it smells like GSO/TSO related issue of Linux ATL1E driver to > me. Would you turn both features OFF on Linux box and try it again? I tried that and it made no difference. These were the settings on the Linux machine: Offload parameters for eth0: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: off udp-fragmentation-offload: off generic-segmentation-offload: off generic-receive-offload: on large-receive-offload: off rx-vlan-offload: on tx-vlan-offload: on ntuple-filters: off receive-hashing: off Greetings, Michael From owner-freebsd-net@FreeBSD.ORG Tue Nov 15 22:43:25 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CABF106566B for ; Tue, 15 Nov 2011 22:43:25 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id CE1048FC19 for ; Tue, 15 Nov 2011 22:43:24 +0000 (UTC) Received: by vws11 with SMTP id 11so9952029vws.13 for ; Tue, 15 Nov 2011 14:43:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=d+qzU4JVczFOvcdF5sJ9UzOoLW0/U13hlFfZAcdLkeA=; b=UpmCPdw2n+iuiUqFIVaHMly+l8fmQp1O4QfpBqMjI/1ocYUA5MKa8BbK4q+HQT9Ucd Rn7gjuguKVgQZspz8GrZ1PYMCgS5q1UCMxF2BucvVqzC5bT90Nev10Q1hY3/LpRAI9Y7 WyjSr6aEHJ9Tw4C4HugOOFgusC0J2i7jtJFZ4= MIME-Version: 1.0 Received: by 10.52.95.164 with SMTP id dl4mr46682531vdb.72.1321397003955; Tue, 15 Nov 2011 14:43:23 -0800 (PST) Received: by 10.220.75.68 with HTTP; Tue, 15 Nov 2011 14:43:23 -0800 (PST) Date: Tue, 15 Nov 2011 14:43:23 -0800 Message-ID: From: Vijay Singh To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: ipf(8) issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 22:43:25 -0000 Hi. Apologies if this message is a duplicate. I am having issues posting to this list. I am wondering if setting an ipf rule such as the one below will cause some TCP rate limiting. pass in quick on proto tcp from any to 172.17.167.126/32 port = http keep state I am trying to explain TCP RSTs being seen with ipfstat: clabf5% sudo ipfstat bad packets: in 0 out 0 IPv6 packets: in 0 out 0 before => input packets: blocked 9971298 passed 1285221084 nomatch 0 counted 0 short 0 after => input packets: blocked 9975079 passed 1285286724 nomatch 0 counted 0 short 0 -------------------------------------------------------------------------------------- Diff =====> 3781 output packets: blocked 0 passed 1223457926 nomatch 11506 counted 0 short 0 input packets logged: blocked 0 passed 0 output packets logged: blocked 0 passed 0 packets logged: input 0 output 11506 log failures: input 0 output 10147 fragment state(in): kept 0 lost 0 not fragmented 0 fragment state(out): kept 0 lost 0 not fragmented 0 packet state(in): kept 11432484 lost 7811812 packet state(out): kept 3676883 lost 16089 before => ICMP replies: 0 TCP RSTs sent: 7766345 after => ICMP replies: 0 TCP RSTs sent: 7769835 ----------------------------------------------- Diff ==========> 3490 Invalid source(in): 0 Result cache hits(in): 422528946 (out): 309901634 IN Pullups succeeded: 538 failed: 0 OUT Pullups succeeded: 21889 failed: 0 Fastroute successes: 7766345 failures: 0 TCP cksum fails(in): 0 (out): 0 IPF Ticks: 2097481 Packet log flags set: (0) none -vijay From owner-freebsd-net@FreeBSD.ORG Wed Nov 16 10:41:52 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7E55106566B for ; Wed, 16 Nov 2011 10:41:52 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id DCD578FC23 for ; Wed, 16 Nov 2011 10:41:51 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id pAGAfmJP045596 for ; Wed, 16 Nov 2011 17:41:48 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4EC39367.4030109@rdtc.ru> Date: Wed, 16 Nov 2011 17:41:43 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: "net@freebsd.org" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: dummynet(4) kernel process CPU usage monitoring X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 10:41:52 -0000 Hi! How do I give out dummynet's CPU usage via SNMP? Preferable as ever-incrementing raw counter. I already use bsnmpd and its plugin bsnmp-ucd. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Wed Nov 16 15:05:19 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45918106566C for ; Wed, 16 Nov 2011 15:05:19 +0000 (UTC) (envelope-from keith.arner@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id D5C128FC14 for ; Wed, 16 Nov 2011 15:05:18 +0000 (UTC) Received: by wwg14 with SMTP id 14so870095wwg.31 for ; Wed, 16 Nov 2011 07:05:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=eINlFRcAmDjr/dNUp8jOcXL1bFEsTxIjCvuL7P9dRmQ=; b=PhmZldX6R/mq2X1Einy4KBspE9ohsH77sEnTiVdgE+/2snM3OKa6k+vezu0F/afysX 5S7D8QCMOuGDVKHXEUvldeARWeBkTGbflAJI4pNYP7NPkHlB3gVorLsZFsCPBPOoDG8u Xx5hw3AqcTHfVPxR2IHpS7tGMxWQKAlspvxBo= MIME-Version: 1.0 Received: by 10.52.33.140 with SMTP id r12mr51711377vdi.36.1321454390376; Wed, 16 Nov 2011 06:39:50 -0800 (PST) Sender: keith.arner@gmail.com Received: by 10.52.111.70 with HTTP; Wed, 16 Nov 2011 06:39:50 -0800 (PST) Date: Wed, 16 Nov 2011 09:39:50 -0500 X-Google-Sender-Auth: -D53ne-bjp8jS5n7ZZ7JhCgz4BM Message-ID: From: Keith Arner To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: "writable" variable in m_pulldown() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 15:05:19 -0000 I'm trying to make sense out of the use of the variable "writable" in the function m_pulldown(). In particular, how writable is used on the line: if ((off == 0 || offp) && len <= n->m_len - off && writable) goto ok; If the first two conditions in this test (off/offp and len) hold true, then the requested data is already contiguous, and at a position that the requestor is satisfied with -- in other words, no modifications are necessary. However, the use of writable in this test prevents an otherwise satisfactory buffer from fulfilling the request. The other two uses of writable in m_pulldown() make sense (i.e in conjunction with M_TRAILINGSPACE() or M_LEADINGSPACE()). In both those cases m_pulldown() is scribbling to the data region, which is only kosher on a writable buffer. It is the first use of writable, where no data modification is needed, that has me confused. Is there something subtle going on with the first use of writable? Keith -- "A problem well put is half solved." From owner-freebsd-net@FreeBSD.ORG Thu Nov 17 11:59:12 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A83F106564A for ; Thu, 17 Nov 2011 11:59:12 +0000 (UTC) (envelope-from dynax60@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id AB2998FC08 for ; Thu, 17 Nov 2011 11:59:11 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so2537331bkb.13 for ; Thu, 17 Nov 2011 03:59:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=RuIq75sCxBo8jJC+m8D8SXa76Bn0fdQCbFa3sF6qsw0=; b=wzwiZBUVF4O299LA8YC9ffp4dIMQVfXmrXEBsA3m3+Y8IcefhqpIeyjdFg0vOGFpxT wHxDxwvpSSBAjeowZ8XAm0NBPYK6QDFmDtOC1j+AtRYbqiEH1aN9ZJMufy5N4VmNqp+U 8g72dmZvV/jTWvviCI44wMoMB3p3NftuSa+EE= Received: by 10.205.139.71 with SMTP id iv7mr27821163bkc.60.1321529558782; Thu, 17 Nov 2011 03:32:38 -0800 (PST) Received: from [192.168.150.201] (r-msk-mar.nexo.ru. [213.152.136.229]) by mx.google.com with ESMTPS id o7sm31070143bkw.16.2011.11.17.03.32.36 (version=SSLv3 cipher=OTHER); Thu, 17 Nov 2011 03:32:37 -0800 (PST) Message-ID: <4EC4F0CE.3050002@gmail.com> Date: Thu, 17 Nov 2011 15:32:30 +0400 From: "Denis S.Davydov" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Strange issue with the encapsulation of gre into ipip protocol (FreeBSD 8.2) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 11:59:12 -0000 Good day! I have the IPSec-connection with a some company: X.X.X.X - my IPSec-peer (real ipaddress) A.A.A.A - service for the mobile terminals (real ipaddress) Y.Y.Y.Y - remote IPSec-peer (real ipaddress) Z.Z.Z.Z - remote GRE gateway (real ipaddress) 10.0.0.0/24 - remote the mobile terminal's network beyond the gre on Z.Z.Z.Z. Objective: The mobile terminals from network 10.0.0.0/24 must have an access to A.A.A.A via my router. Remote private network is beyond the GRE-tunnel (without private subnet /30, they do route via gre interface directly), GRE tunnel must be accessed via IPSec on Y.Y.Y.Y. So the scheme: tcp->gre->ipip->esp. I have no idea why there's a double-encapsulation - this is a requirements of the remote side. /etc/rc.conf: gif_interfaces="gif0" static_routes="vpn0" cloned_interfaces="gre0" gifconfig_gif0="X.X.X.X Y.Y.Y.Y" ifconfig_gre0="tunnel X.X.X.X Z.Z.Z.Z" route_vpn0="10.0.0.0/24 -interface gre0" /usr/local/etc/racoon/setkey.conf: flush; spdflush; spdadd X.X.X.X/32[any] Z.Z.Z.Z/32[any] 47 -P out ipsec esp/tunnel/X.X.X.X-Y.Y.Y.Y/unique; spdadd Z.Z.Z.Z/32[any] X.X.X.X/32[any] 47 -P in ipsec esp/tunnel/Y.Y.Y.Y-X.X.X.X/unique; /usr/local/etc/racoon/racoon.conf: remote Y.Y.Y.Y [500] { exchange_mode main; doi ipsec_doi; situation identity_only; nonce_size 16; initial_contact on; support_proxy on; proposal_check obey; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; lifetime time 600 sec; dh_group 2; } } sainfo address X.X.X.X/32 47 address Z.Z.Z.Z/32 47 { pfs_group 2; encryption_algorithm 3des; authentication_algorithm hmac_sha1; compression_algorithm deflate; lifetime time 3600 sec; } # ifconfig gre0 gre0: flags=9051 metric 0 mtu 1476 tunnel inet X.X.X.X --> Y.Y.Y.Y # ifconfig gif0 gif0: flags=8051 metric 0 mtu 1280 tunnel inet X.X.X.X --> Z.Z.Z.Z options=1 # netstat -rn | grep gre 10.0.0.0/24 gre0 US 0 4191 gre0 So, it's like a terminals are trying to work, but I noticed strange traffic on enc0 interface: 10:27:58.028806 (authentic,confidential): SPI 0x0d640bcb: IP Y.Y.Y.Y > X.X.X.X: IP Z.Z.Z.Z > X.X.X.X: GREv0, length 48: IP 10.0.0.1.7337 > A.A.A.A.10008: Flags [S], seq 14633856, win 32120, options [[|tcp] (ipip-proto-4) 10:27:58.029544 (authentic,confidential): SPI 0x9e06a435: IP X.X.X.X > Z.Z.Z.Z: GREv0, length 48: IP A.A.A.A.10008 > 10.0.0.1.7337: Flags [S.], seq 1966363414, ack 14633857, win 8192, options [mss 1460], length 0 10:27:58.029552 (authentic,confidential): SPI 0x9e06a435: IP X.X.X.X > Y.Y.Y.Y: IP X.X.X.X > Z.Z.Z.Z: GREv0, length 48: IP A.A.A.A.10008 > 10.0.0.1.7337: Flags [S.], seq 1966363414, ack 14633857, win 8192, options [[|tcp] (ipip-proto-4) 10:27:58.628570 (authentic,confidential): SPI 0x0d640bcb: IP Y.Y.Y.Y > X.X.X.X: IP Z.Z.Z.Z > X.X.X.X: GREv0, length 44: IP 10.0.0.1.7337 > A.A.A.A.10008: Flags [.], ack 1, win 32120, length 0 (ipip-proto-4) 10:28:00.829033 (authentic,confidential): SPI 0x0d640bcb: IP Y.Y.Y.Y > X.X.X.X: IP Z.Z.Z.Z > X.X.X.X: GREv0, length 137: IP 10.0.0.1.7337 > A.A.A.A.9990: Flags [FSRP.W], seq 667402656:667402725, ack 2153916852, win 64615, options [[|tcp] (ipip-proto-4) 10:28:08.622620 (authentic,confidential): SPI 0x9e06a435: IP X.X.X.X > Z.Z.Z.Z: GREv0, length 44: IP A.A.A.A.10008 > 10.0.0.1.7337: Flags [F.], seq 1, ack 1, win 64240, length 0 10:28:08.622632 (authentic,confidential): SPI 0x9e06a435: IP X.X.X.X > Y.Y.Y.Y: IP X.X.X.X > Z.Z.Z.Z: GREv0, length 44: IP A.A.A.A.10008 > 10.0.0.1.7337: Flags [F.], seq 1, ack 1, win 64240, length 0 (ipip-proto-4) 10:28:09.808942 (authentic,confidential): SPI 0x0d640bcb: IP Y.Y.Y.Y > X.X.X.X: IP Z.Z.Z.Z > X.X.X.X: GREv0, length 44: IP 10.0.0.1.7337 > A.A.A.A.10008: Flags [.], ack 2, win 32120, length 0 (ipip-proto-4) 10:28:10.449265 (authentic,confidential): SPI 0x0d640bcb: IP Y.Y.Y.Y > X.X.X.X: IP Z.Z.Z.Z > X.X.X.X: GREv0, length 137: IP 10.0.0.1.7337 > A.A.A.A.10008: Flags [P.], ack 1, win 32120, length 93 (ipip-proto-4) 10:28:10.449672 (authentic,confidential): SPI 0x9e06a435: IP X.X.X.X > Z.Z.Z.Z: GREv0, length 44: IP A.A.A.A.10008 > 10.0.0.1.7337: Flags [R.], seq 2, ack 94, win 0, length 0 10:28:10.449679 (authentic,confidential): SPI 0x9e06a435: IP X.X.X.X > Y.Y.Y.Y: IP X.X.X.X > Z.Z.Z.Z: GREv0, length 44: IP A.A.A.A.10008 > 10.0.0.1.7337: Flags [R.], seq 2, ack 94, win 0, length 0 (ipip-proto-4) It is not clear to me why the first gre packet response from A.A.A.A is not encapsulated into ipip protocol and sent directly to Z.Z.Z.Z (via esp protocol), and the next gre packet with the same ack-id normally encapsulated into IPIP for sending it to the peer Y.Y.Y.Y? Where I'm wrong? FreeBSD 8.2. -- Kind regards, Dennis From owner-freebsd-net@FreeBSD.ORG Thu Nov 17 21:36:59 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E44F31065676 for ; Thu, 17 Nov 2011 21:36:59 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id AB7398FC18 for ; Thu, 17 Nov 2011 21:36:59 +0000 (UTC) Received: by yenl11 with SMTP id l11so2433286yen.13 for ; Thu, 17 Nov 2011 13:36:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=UzAk3syWLzZPg0L1RCiucYzsPsgdkdZKB+IPVQqxGeU=; b=nIua0YkGiT8Wyy6FngDXiH6Cgcipyq5J7whg+fwwU6Ixe7LGjF9fVhs0GbcNfgEOIJ 6srEuZc/fk9vCxTcP8v2QM86jne5bE38XxAVcY9dTzi/VD8XIUuWEuv0G0zv6clklBdm R7t513kDUsIJsLqHr0bCOBeCQ6PpIXcL7R9W0= MIME-Version: 1.0 Received: by 10.236.161.4 with SMTP id v4mr378759yhk.89.1321564360545; Thu, 17 Nov 2011 13:12:40 -0800 (PST) Received: by 10.100.122.19 with HTTP; Thu, 17 Nov 2011 13:12:40 -0800 (PST) Date: Thu, 17 Nov 2011 13:12:40 -0800 Message-ID: From: Maksim Yevmenkin To: freebsd-net Content-Type: text/plain; charset=ISO-8859-1 Subject: confused with if_baudrate X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 21:37:00 -0000 hello, i'm a little bit confused about if_baudrate. from system headers #define if_baudrate if_data.ifi_baudrate and u_long ifi_baudrate; /* linespeed */ so, i'm taking this as if_baudrate really should be an interface line speed in megabits per second. am i correct? if so, then it appears that at least some drivers lie about true line speed. for example from ixgbe(4) ifp->if_baudrate = 1000000000; it looks like its order of magnitude lower (i.e. 1 gigabit per second instead of 10 gigabits per second). am i missing something here or its just a typo? thanks, max From owner-freebsd-net@FreeBSD.ORG Thu Nov 17 21:39:46 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD0301065687 for ; Thu, 17 Nov 2011 21:39:46 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6DB9F8FC16 for ; Thu, 17 Nov 2011 21:39:46 +0000 (UTC) Received: by wwg14 with SMTP id 14so3753086wwg.31 for ; Thu, 17 Nov 2011 13:39:45 -0800 (PST) Received: by 10.227.207.205 with SMTP id fz13mr293084wbb.0.1321565985057; Thu, 17 Nov 2011 13:39:45 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.227.135.5 with HTTP; Thu, 17 Nov 2011 13:39:24 -0800 (PST) In-Reply-To: References: From: Juli Mallett Date: Thu, 17 Nov 2011 13:39:24 -0800 X-Google-Sender-Auth: K2nUddfanCyWwVGKxF2iA2TONrc Message-ID: To: Maksim Yevmenkin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net Subject: Re: confused with if_baudrate X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 21:39:46 -0000 On Thu, Nov 17, 2011 at 13:12, Maksim Yevmenkin wrote: > hello, > > i'm a little bit confused about if_baudrate. from system headers > > #define if_baudrate =C2=A0 =C2=A0 if_data.ifi_baudrate > > and > > u_long =C2=A0ifi_baudrate; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* linespee= d */ > > so, i'm taking this as if_baudrate really should be an interface line > speed in megabits per second. am i correct? if so, then it appears > that at least some drivers lie about true line speed. for example from > ixgbe(4) > > =C2=A0 =C2=A0 =C2=A0 =C2=A0ifp->if_baudrate =3D 1000000000; > > it looks like its order of magnitude lower (i.e. 1 gigabit per second > instead of 10 gigabits per second). am i missing something here or its > just a typo? ixgbe's developer is excessively concerned about overflow on 32-bit hosts (and unwilling to correct it under a preprocessor conditional), unlike several of the other 10GbE driver developers, although I think one 10GbE driver opts to omit if_baudrate entirely. Thanks, Juli. From owner-freebsd-net@FreeBSD.ORG Thu Nov 17 22:03:06 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53AD0106566B; Thu, 17 Nov 2011 22:03:06 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id C94E68FC17; Thu, 17 Nov 2011 22:03:05 +0000 (UTC) Received: by iakl21 with SMTP id l21so3961779iak.13 for ; Thu, 17 Nov 2011 14:03:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=ibA6mXmq5CV7a5OPve8XEGH+W+cHF3yaInPPh24ep4Y=; b=i8iJ6HK80UGgb7eP2TruEJsaLiPdw5o4xaU1Sb4BduXQWuMcLEcPVwgW0A7r6R128a rOs+LE8dWzToFLh2tdJzPCaagcVaX4iVXdXrQoVwedvdqcD/6eyy9Og4Vx0N08BADZ6t O3uyRRRu8M0wbKqPubhsptHrAxI8R+AsnLNY8= Received: by 10.43.53.1 with SMTP id vo1mr558icb.2.1321567385175; Thu, 17 Nov 2011 14:03:05 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id ew6sm34403854igc.4.2011.11.17.14.03.02 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Nov 2011 14:03:04 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 17 Nov 2011 14:01:04 -0800 From: YongHyeon PYUN Date: Thu, 17 Nov 2011 14:01:04 -0800 To: Juli Mallett Message-ID: <20111117220104.GD11828@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net , Maksim Yevmenkin Subject: Re: confused with if_baudrate X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 22:03:06 -0000 On Thu, Nov 17, 2011 at 01:39:24PM -0800, Juli Mallett wrote: > On Thu, Nov 17, 2011 at 13:12, Maksim Yevmenkin > wrote: > > hello, > > > > i'm a little bit confused about if_baudrate. from system headers > > > > #define if_baudrate ?? ?? if_data.ifi_baudrate > > > > and > > > > u_long ??ifi_baudrate; ?? ?? ?? ?? ?? /* linespeed */ > > > > so, i'm taking this as if_baudrate really should be an interface line > > speed in megabits per second. am i correct? if so, then it appears > > that at least some drivers lie about true line speed. for example from > > ixgbe(4) > > > > ?? ?? ?? ??ifp->if_baudrate = 1000000000; > > > > it looks like its order of magnitude lower (i.e. 1 gigabit per second > > instead of 10 gigabits per second). am i missing something here or its > > just a typo? > > ixgbe's developer is excessively concerned about overflow on 32-bit > hosts (and unwilling to correct it under a preprocessor conditional), > unlike several of the other 10GbE driver developers, although I think > one 10GbE driver opts to omit if_baudrate entirely. > Probably the driver could have used something like this. ifp->if_baudrate = IF_Gbps(10UL); I think the driver should update if_baudrate depending on resolved speed(lost link, resolved speed etc). And if we really care about overflowing if_baudrate on 32bit machines, the IF_Gbps macro could be conditionally defined. > Thanks, > Juli. From owner-freebsd-net@FreeBSD.ORG Fri Nov 18 01:38:20 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB83F1065670; Fri, 18 Nov 2011 01:38:20 +0000 (UTC) (envelope-from bhutchings@solarflare.com) Received: from exchange.solarflare.com (mail.solarflare.com [216.237.3.220]) by mx1.freebsd.org (Postfix) with ESMTP id B5F628FC15; Fri, 18 Nov 2011 01:38:20 +0000 (UTC) Received: from OCEX02.SolarFlarecom.com ([10.20.40.31]) by exchange.solarflare.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Nov 2011 17:38:19 -0800 Received: from [10.17.20.137] (10.17.20.137) by ocex02.SolarFlarecom.com (10.20.40.31) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 17 Nov 2011 17:38:19 -0800 From: Ben Hutchings To: In-Reply-To: <20111117220104.GD11828@michelle.cdnetworks.com> References: <20111117220104.GD11828@michelle.cdnetworks.com> Content-Type: text/plain; charset="UTF-8" Organization: Solarflare Communications Date: Fri, 18 Nov 2011 01:38:16 +0000 Message-ID: <1321580296.2749.78.camel@bwh-desktop> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit X-Originating-IP: [10.17.20.137] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18524.005 X-TM-AS-Result: No--23.762300-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-OriginalArrivalTime: 18 Nov 2011 01:38:19.0956 (UTC) FILETIME=[C0745740:01CCA592] Cc: Juli Mallett , freebsd-net , Maksim Yevmenkin Subject: Re: confused with if_baudrate X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 01:38:20 -0000 On Thu, 2011-11-17 at 14:01 -0800, YongHyeon PYUN wrote: > On Thu, Nov 17, 2011 at 01:39:24PM -0800, Juli Mallett wrote: > > On Thu, Nov 17, 2011 at 13:12, Maksim Yevmenkin > > wrote: > > > hello, > > > > > > i'm a little bit confused about if_baudrate. from system headers > > > > > > #define if_baudrate ?? ?? if_data.ifi_baudrate > > > > > > and > > > > > > u_long ??ifi_baudrate; ?? ?? ?? ?? ?? /* linespeed */ > > > > > > so, i'm taking this as if_baudrate really should be an interface line > > > speed in megabits per second. am i correct? if so, then it appears > > > that at least some drivers lie about true line speed. for example from > > > ixgbe(4) > > > > > > ?? ?? ?? ??ifp->if_baudrate = 1000000000; > > > > > > it looks like its order of magnitude lower (i.e. 1 gigabit per second > > > instead of 10 gigabits per second). am i missing something here or its > > > just a typo? > > > > ixgbe's developer is excessively concerned about overflow on 32-bit > > hosts (and unwilling to correct it under a preprocessor conditional), > > unlike several of the other 10GbE driver developers, although I think > > one 10GbE driver opts to omit if_baudrate entirely. > > > > Probably the driver could have used something like this. > ifp->if_baudrate = IF_Gbps(10UL); > > I think the driver should update if_baudrate depending on > resolved speed(lost link, resolved speed etc). > And if we really care about overflowing if_baudrate on 32bit > machines, the IF_Gbps macro could be conditionally defined. It could also overflow on 64-bit machines too because the caller didn't know to use UL (which they shouldn't have to - what kind of encapsulation is that?). How about: #define IF_Gbps(x) ((ulong)MIN(IF_Mbps((uint64_t)(x)), ULONG_MAX)) Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. From owner-freebsd-net@FreeBSD.ORG Fri Nov 18 02:08:30 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8FE41065680; Fri, 18 Nov 2011 02:08:30 +0000 (UTC) (envelope-from bhutchings@solarflare.com) Received: from exchange.solarflare.com (exchange.solarflare.com [216.237.3.220]) by mx1.freebsd.org (Postfix) with ESMTP id C24978FC0C; Fri, 18 Nov 2011 02:08:30 +0000 (UTC) Received: from OCEX02.SolarFlarecom.com ([10.20.40.31]) by exchange.solarflare.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Nov 2011 18:08:29 -0800 Received: from [10.17.20.137] (10.17.20.137) by ocex02.SolarFlarecom.com (10.20.40.31) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 17 Nov 2011 18:08:29 -0800 From: Ben Hutchings To: In-Reply-To: <1321580296.2749.78.camel@bwh-desktop> References: <20111117220104.GD11828@michelle.cdnetworks.com> <1321580296.2749.78.camel@bwh-desktop> Content-Type: text/plain; charset="UTF-8" Organization: Solarflare Communications Date: Fri, 18 Nov 2011 02:08:26 +0000 Message-ID: <1321582106.2749.82.camel@bwh-desktop> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit X-Originating-IP: [10.17.20.137] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18524.005 X-TM-AS-Result: No--23.762300-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-OriginalArrivalTime: 18 Nov 2011 02:08:29.0910 (UTC) FILETIME=[F7456760:01CCA596] Cc: Juli Mallett , freebsd-net , Maksim Yevmenkin Subject: Re: confused with if_baudrate X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 02:08:31 -0000 On Fri, 2011-11-18 at 01:38 +0000, Ben Hutchings wrote: > On Thu, 2011-11-17 at 14:01 -0800, YongHyeon PYUN wrote: > > On Thu, Nov 17, 2011 at 01:39:24PM -0800, Juli Mallett wrote: > > > On Thu, Nov 17, 2011 at 13:12, Maksim Yevmenkin > > > wrote: > > > > hello, > > > > > > > > i'm a little bit confused about if_baudrate. from system headers > > > > > > > > #define if_baudrate ?? ?? if_data.ifi_baudrate > > > > > > > > and > > > > > > > > u_long ??ifi_baudrate; ?? ?? ?? ?? ?? /* linespeed */ > > > > > > > > so, i'm taking this as if_baudrate really should be an interface line > > > > speed in megabits per second. am i correct? if so, then it appears > > > > that at least some drivers lie about true line speed. for example from > > > > ixgbe(4) > > > > > > > > ?? ?? ?? ??ifp->if_baudrate = 1000000000; > > > > > > > > it looks like its order of magnitude lower (i.e. 1 gigabit per second > > > > instead of 10 gigabits per second). am i missing something here or its > > > > just a typo? > > > > > > ixgbe's developer is excessively concerned about overflow on 32-bit > > > hosts (and unwilling to correct it under a preprocessor conditional), > > > unlike several of the other 10GbE driver developers, although I think > > > one 10GbE driver opts to omit if_baudrate entirely. > > > > > > > Probably the driver could have used something like this. > > ifp->if_baudrate = IF_Gbps(10UL); > > > > I think the driver should update if_baudrate depending on > > resolved speed(lost link, resolved speed etc). > > And if we really care about overflowing if_baudrate on 32bit > > machines, the IF_Gbps macro could be conditionally defined. > > It could also overflow on 64-bit machines too because the caller didn't > know to use UL (which they shouldn't have to - what kind of > encapsulation is that?). How about: > > #define IF_Gbps(x) ((ulong)MIN(IF_Mbps((uint64_t)(x)), ULONG_MAX)) Er, make that: #define IF_Gbps(x) ((ulong)MIN(IF_Mbps((uint64_t)(x) * 1000), ULONG_MAX)) Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. From owner-freebsd-net@FreeBSD.ORG Fri Nov 18 11:11:11 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D45281065673 for ; Fri, 18 Nov 2011 11:11:11 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id 31D798FC15 for ; Fri, 18 Nov 2011 11:11:11 +0000 (UTC) Received: (qmail invoked by alias); 18 Nov 2011 11:11:09 -0000 Received: from adsl-21.109.242.12.tellas.gr (EHLO [192.168.73.192]) [109.242.12.21] by mail.gmx.com (mp-eu004) with SMTP; 18 Nov 2011 12:11:09 +0100 X-Authenticated: #46156728 X-Provags-ID: V01U2FsdGVkX1/LFDN6UAvLXMLWPYo5a23Sn5wwn4tfFpAnSLLm92 Go7EUomSqYukJw Message-ID: <4EC63D37.4050105@gmx.com> Date: Fri, 18 Nov 2011 13:10:47 +0200 From: Nikos Vassiliadis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: arprequest triggered panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 11:11:11 -0000 Hello, I was playing with lagg and found out a kernel panic. Here is the backtrace: > #5 0xc0a65613 in kdb_trap (type=12, code=0, tf=0xc3f1bb1c) at /usr/src/sys/kern/subr_kdb.c:625 > #6 0xc0dbbc1f in trap_fatal (frame=0xc3f1bb1c, eva=24) at /usr/src/sys/i386/i386/trap.c:966 > #7 0xc0dbbd1c in trap_pfault (frame=0xc3f1bb1c, usermode=0, eva=24) at /usr/src/sys/i386/i386/trap.c:839 > #8 0xc0dbc9b5 in trap (frame=0xc3f1bb1c) at /usr/src/sys/i386/i386/trap.c:558 > #9 0xc0da54fc in calltrap () at /usr/src/sys/i386/i386/exception.s:168 > #10 0xc0b496eb in arprequest (ifp=0xc42c5400, sip=0xc46625ac, tip=0xc46625ac, enaddr=0xc41d3d9b "\b") at /usr/src/sys/netinet/if_ether.c:264 > #11 0xc0b4acef in arp_ifinit (ifp=0xc42c5400, ifa=0xc4662500) at /usr/src/sys/netinet/if_ether.c:880 > #12 0xc0aea7ae in if_setlladdr (ifp=0xc42c5400, lladdr=0xc49ac204 "\b", len=6) at /usr/src/sys/net/if.c:3317 > #13 0xc4bb7bd3 in lagg_port_setlladdr (arg=0xc4a47b00, pending=1) at /usr/src/sys/modules/if_lagg/../../net/if_lagg.c:476 > #14 0xc0a730fb in taskqueue_run_locked (queue=0xc42f3400) at /usr/src/sys/kern/subr_taskqueue.c:308 > #15 0xc0a7321f in taskqueue_run (queue=0xc42f3400) at /usr/src/sys/kern/subr_taskqueue.c:322 > #16 0xc0a732d3 in taskqueue_swi_run (dummy=0x0) at /usr/src/sys/kern/subr_taskqueue.c:418 It's triggered with these commands: ifconfig em2 10.0.156.1/24 ifconfig em3 10.0.156.2/24 i=`ifconfig lagg create` ifconfig $i laggport em2 laggport em3 ifconfig $i 10.0.156.3/24 Just reporting, should I fill a PR? Nikos From owner-freebsd-net@FreeBSD.ORG Fri Nov 18 20:53:53 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84103106568A; Fri, 18 Nov 2011 20:53:53 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2B0438FC13; Fri, 18 Nov 2011 20:53:53 +0000 (UTC) Received: by ywe9 with SMTP id 9so4313166ywe.13 for ; Fri, 18 Nov 2011 12:53:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XkGtvxlRV5zkWkLRGMytXuzzOS9fuOaiJLSbwzc7/SM=; b=tOhJCRY0CWOK/nSe4Ry5qY7wdUSddE/5rVglmcwsxoKLMZvbWOUdpZjfs54v/Pxc73 NSCxKm4DHs5WPX0V4t3G2zyn9crHOVa9PkpDLqrzHGE7gXlLYzsnFZXG9fHeiWJ04cD7 MvPgTAAzliGDF+erFb1Ssmqu6bx7LraiZjeH4= MIME-Version: 1.0 Received: by 10.236.184.225 with SMTP id s61mr8054901yhm.80.1321649632632; Fri, 18 Nov 2011 12:53:52 -0800 (PST) Received: by 10.100.122.19 with HTTP; Fri, 18 Nov 2011 12:53:52 -0800 (PST) In-Reply-To: References: Date: Fri, 18 Nov 2011 12:53:52 -0800 Message-ID: From: Maksim Yevmenkin To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net Subject: Re: confused with if_baudrate X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 20:53:53 -0000 On Thu, Nov 17, 2011 at 1:39 PM, Juli Mallett wrote: > On Thu, Nov 17, 2011 at 13:12, Maksim Yevmenkin > wrote: >> hello, >> >> i'm a little bit confused about if_baudrate. from system headers >> >> #define if_baudrate =A0 =A0 if_data.ifi_baudrate >> >> and >> >> u_long =A0ifi_baudrate; =A0 =A0 =A0 =A0 =A0 /* linespeed */ >> >> so, i'm taking this as if_baudrate really should be an interface line >> speed in megabits per second. am i correct? if so, then it appears >> that at least some drivers lie about true line speed. for example from >> ixgbe(4) >> >> =A0 =A0 =A0 =A0ifp->if_baudrate =3D 1000000000; >> >> it looks like its order of magnitude lower (i.e. 1 gigabit per second >> instead of 10 gigabits per second). am i missing something here or its >> just a typo? > > ixgbe's developer is excessively concerned about overflow on 32-bit > hosts (and unwilling to correct it under a preprocessor conditional), > unlike several of the other 10GbE driver developers, although I think > one 10GbE driver opts to omit if_baudrate entirely. well, this is unfortunate as if_baudrate reported as part of ifmib, so, when interface is monitored over snmp value of ifSpeed and HCOutSpeed can not be trusted :( thanks, max From owner-freebsd-net@FreeBSD.ORG Fri Nov 18 21:32:19 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C73F6106564A; Fri, 18 Nov 2011 21:32:19 +0000 (UTC) (envelope-from bhutchings@solarflare.com) Received: from exchange.solarflare.com (exchange.solarflare.com [216.237.3.220]) by mx1.freebsd.org (Postfix) with ESMTP id A60108FC08; Fri, 18 Nov 2011 21:32:19 +0000 (UTC) Received: from OCEX02.SolarFlarecom.com ([10.20.40.31]) by exchange.solarflare.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Nov 2011 13:32:18 -0800 Received: from [10.17.20.137] (10.17.20.137) by ocex02.SolarFlarecom.com (10.20.40.31) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 18 Nov 2011 13:32:18 -0800 From: Ben Hutchings To: Philip Paeps Content-Type: text/plain; charset="UTF-8" Organization: Solarflare Communications Date: Fri, 18 Nov 2011 21:32:15 +0000 Message-ID: <1321651935.2883.74.camel@bwh-desktop> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit X-Originating-IP: [10.17.20.137] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18526.005 X-TM-AS-Result: No--6.004500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-OriginalArrivalTime: 18 Nov 2011 21:32:18.0833 (UTC) FILETIME=[8C8D7810:01CCA639] Cc: freebsd-net@freebsd.org, marius@freebsd.org Subject: sfxge: Fix if_baudrate reports X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 21:32:19 -0000 sfxge: Fix if_baudrate reports This field is supposed to be set to the interface bit rate, but for some reason I thought it was denominated in kilobits. Multiply the values up accordingly, taking care to saturate rather than overflow on 32-bit architectures. --- a/sys/dev/sfxge/sfxge_port.c +++ b/sys/dev/sfxge/sfxge_port.c @@ -31,6 +31,7 @@ __FBSDID("$FreeBSD$"); #include +#include #include #include @@ -219,14 +220,14 @@ sfxge_port_link_fc_handler(SYSCTL_HANDLE #endif /* SFXGE_HAVE_PAUSE_MEDIAOPTS */ -static const int sfxge_link_speed_kbit[EFX_LINK_NMODES] = { - [EFX_LINK_10HDX] = 10000, - [EFX_LINK_10FDX] = 10000, - [EFX_LINK_100HDX] = 100000, - [EFX_LINK_100FDX] = 100000, - [EFX_LINK_1000HDX] = 1000000, - [EFX_LINK_1000FDX] = 1000000, - [EFX_LINK_10000FDX] = 10000000, +static const u_long sfxge_link_baudrate[EFX_LINK_NMODES] = { + [EFX_LINK_10HDX] = IF_Mbps(10), + [EFX_LINK_10FDX] = IF_Mbps(10), + [EFX_LINK_100HDX] = IF_Mbps(100), + [EFX_LINK_100FDX] = IF_Mbps(100), + [EFX_LINK_1000HDX] = IF_Gbps(1), + [EFX_LINK_1000FDX] = IF_Gbps(1), + [EFX_LINK_10000FDX] = MIN(IF_Gbps(10ULL), ULONG_MAX), }; void @@ -245,7 +246,7 @@ sfxge_mac_link_update(struct sfxge_softc /* Push link state update to the OS */ link_state = (port->link_mode != EFX_LINK_DOWN ? LINK_STATE_UP : LINK_STATE_DOWN); - sc->ifnet->if_baudrate = sfxge_link_speed_kbit[port->link_mode]; + sc->ifnet->if_baudrate = sfxge_link_baudrate[port->link_mode]; if_link_state_change(sc->ifnet, link_state); } -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. From owner-freebsd-net@FreeBSD.ORG Fri Nov 18 21:34:19 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F26FF106566C; Fri, 18 Nov 2011 21:34:19 +0000 (UTC) (envelope-from bhutchings@solarflare.com) Received: from exchange.solarflare.com (exchange.solarflare.com [216.237.3.220]) by mx1.freebsd.org (Postfix) with ESMTP id D0A4D8FC13; Fri, 18 Nov 2011 21:34:19 +0000 (UTC) Received: from OCEX02.SolarFlarecom.com ([10.20.40.31]) by exchange.solarflare.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Nov 2011 13:34:14 -0800 Received: from [10.17.20.137] (10.17.20.137) by ocex02.SolarFlarecom.com (10.20.40.31) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 18 Nov 2011 13:34:14 -0800 From: Ben Hutchings To: Philip Paeps Content-Type: text/plain; charset="UTF-8" Organization: Solarflare Communications Date: Fri, 18 Nov 2011 21:34:11 +0000 Message-ID: <1321652051.2883.76.camel@bwh-desktop> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit X-Originating-IP: [10.17.20.137] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18526.005 X-TM-AS-Result: No--3.092200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-OriginalArrivalTime: 18 Nov 2011 21:34:14.0755 (UTC) FILETIME=[D1A5C330:01CCA639] Cc: freebsd-net@freebsd.org, marius@freebsd.org Subject: sfxge: Remove interrupt self-test code X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 21:34:20 -0000 sfxge: Remove interrupt self-test code It's not currently used; it didn't build on 32-bit and the previous build fix is incorrect. If we really implement self-tests we can do this again properly. --- a/sys/dev/sfxge/sfxge.h +++ b/sys/dev/sfxge/sfxge.h @@ -144,7 +144,6 @@ struct sfxge_intr { int n_alloc; int type; efsys_mem_t status; - uint64_t mask; uint32_t zero_count; }; --- a/sys/dev/sfxge/sfxge_intr.c +++ b/sys/dev/sfxge/sfxge_intr.c @@ -65,15 +65,9 @@ sfxge_intr_line_filter(void *arg) KASSERT(intr->type == EFX_INTR_LINE, ("intr->type != EFX_INTR_LINE")); - if (intr->state != SFXGE_INTR_STARTED && - intr->state != SFXGE_INTR_TESTING) + if (intr->state != SFXGE_INTR_STARTED) return FILTER_STRAY; - if (intr->state == SFXGE_INTR_TESTING) { - intr->mask |= 1; /* only one interrupt */ - return FILTER_HANDLED; - } - (void)efx_intr_status_line(enp, &fatal, &qmask); if (fatal) { @@ -137,21 +131,9 @@ sfxge_intr_message(void *arg) KASSERT(intr->type == EFX_INTR_MESSAGE, ("intr->type != EFX_INTR_MESSAGE")); - if (intr->state != SFXGE_INTR_STARTED && - intr->state != SFXGE_INTR_TESTING) + if (intr->state != SFXGE_INTR_STARTED) return; - if (intr->state == SFXGE_INTR_TESTING) { - uint64_t mask; - - do { - mask = intr->mask; - } while (atomic_cmpset_ptr(&intr->mask, mask, - mask | (1 << index)) == 0); - - return; - } - (void)efx_intr_status_message(enp, index, &fatal); if (fatal) { @@ -447,7 +429,6 @@ sfxge_intr_stop(struct sfxge_softc *sc) intr->state = SFXGE_INTR_INITIALIZED; /* Disable interrupts at the NIC */ - intr->mask = 0; efx_intr_disable(sc->enp); /* Disable interrupts at the bus */ @@ -480,13 +461,11 @@ sfxge_intr_start(struct sfxge_softc *sc) if ((rc = sfxge_intr_bus_enable(sc)) != 0) goto fail; - intr->state = SFXGE_INTR_TESTING; + intr->state = SFXGE_INTR_STARTED; /* Enable interrupts at the NIC */ efx_intr_enable(sc->enp); - intr->state = SFXGE_INTR_STARTED; - return (0); fail: -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. From owner-freebsd-net@FreeBSD.ORG Fri Nov 18 23:35:06 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C7FA106564A; Fri, 18 Nov 2011 23:35:06 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 18DCE8FC0A; Fri, 18 Nov 2011 23:35:05 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id pAINZ4Jr030006; Sat, 19 Nov 2011 00:35:04 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id pAINZ416030005; Sat, 19 Nov 2011 00:35:04 +0100 (CET) (envelope-from marius) Date: Sat, 19 Nov 2011 00:35:04 +0100 From: Marius Strobl To: Ben Hutchings Message-ID: <20111118233504.GK93221@alchemy.franken.de> References: <1321652051.2883.76.camel@bwh-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1321652051.2883.76.camel@bwh-desktop> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, Philip Paeps Subject: Re: sfxge: Remove interrupt self-test code X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 23:35:06 -0000 On Fri, Nov 18, 2011 at 09:34:11PM +0000, Ben Hutchings wrote: > sfxge: Remove interrupt self-test code > > It's not currently used; it didn't build on 32-bit and the previous > build fix is incorrect. If we really implement self-tests we can do > this again properly. Yes, I've also already noticed that this part of r227640 wasn't quite correct. However Philip suggested to just leave it in for now until we figure out what on earth the code actually is supposed to do and as the atomic_cmpset_ptr(9) also works on LP64 and isn't more broken than the atomic_cmpset_long(9) that was in there before (actually this should have been atomic_cmpset_64(9) for an uint64_t, which isn't necessarily available on ILP32 including i386 though). Probably this should have been converted to be of type cpuset_t and to use the accessors from as nowadays we also support more than 64 CPUs. I'm also fine with just nuking the interrupt self-test altogether though. Marius From owner-freebsd-net@FreeBSD.ORG Sat Nov 19 00:21:45 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8104106566B; Sat, 19 Nov 2011 00:21:45 +0000 (UTC) (envelope-from bhutchings@solarflare.com) Received: from exchange.solarflare.com (exchange.solarflare.com [216.237.3.220]) by mx1.freebsd.org (Postfix) with ESMTP id A2C628FC17; Sat, 19 Nov 2011 00:21:45 +0000 (UTC) Received: from OCEX02.SolarFlarecom.com ([10.20.40.31]) by exchange.solarflare.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Nov 2011 16:21:44 -0800 Received: from [10.17.20.137] (10.17.20.137) by ocex02.SolarFlarecom.com (10.20.40.31) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 18 Nov 2011 16:21:44 -0800 From: Ben Hutchings To: Marius Strobl In-Reply-To: <20111118233504.GK93221@alchemy.franken.de> References: <1321652051.2883.76.camel@bwh-desktop> <20111118233504.GK93221@alchemy.franken.de> Content-Type: text/plain; charset="UTF-8" Organization: Solarflare Communications Date: Sat, 19 Nov 2011 00:21:41 +0000 Message-ID: <1321662101.2883.102.camel@bwh-desktop> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit X-Originating-IP: [10.17.20.137] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18526.005 X-TM-AS-Result: No--24.532100-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-OriginalArrivalTime: 19 Nov 2011 00:21:44.0915 (UTC) FILETIME=[38027A30:01CCA651] Cc: freebsd-net@freebsd.org, Philip Paeps Subject: Re: sfxge: Remove interrupt self-test code X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 00:21:45 -0000 On Sat, 2011-11-19 at 00:35 +0100, Marius Strobl wrote: > On Fri, Nov 18, 2011 at 09:34:11PM +0000, Ben Hutchings wrote: > > sfxge: Remove interrupt self-test code > > > > It's not currently used; it didn't build on 32-bit and the previous > > build fix is incorrect. If we really implement self-tests we can do > > this again properly. > > Yes, I've also already noticed that this part of r227640 wasn't quite > correct. However Philip suggested to just leave it in for now until > we figure out what on earth the code actually is supposed to do and as > the atomic_cmpset_ptr(9) also works on LP64 and isn't more broken than > the atomic_cmpset_long(9) that was in there before (actually this should > have been atomic_cmpset_64(9) for an uint64_t, which isn't necessarily > available on ILP32 including i386 though). Probably this should have > been converted to be of type cpuset_t and to use the accessors from > as nowadays we also support more than 64 CPUs. I'm also > fine with just nuking the interrupt self-test altogether though. The hardware RX flow hash indirection table has 6-bit entries so it's not possible to use more than 64 RX queues without some kind of flow steering. So for the time being this driver sets a limit of 64 interrupts. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. From owner-freebsd-net@FreeBSD.ORG Sat Nov 19 09:18:09 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34BCF106566B; Sat, 19 Nov 2011 09:18:09 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from rincewind.paeps.cx (rincewind.paeps.cx [IPv6:2002:596a:f092::149]) by mx1.freebsd.org (Postfix) with ESMTP id F07558FC1E; Sat, 19 Nov 2011 09:18:08 +0000 (UTC) Received: from [192.168.2.103] (IGLD-84-229-200-171.inter.net.il [84.229.200.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: philip) by rincewind.paeps.cx (Postfix) with ESMTPSA id ADC9DD744B0; Sat, 19 Nov 2011 10:18:01 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Philip Paeps In-Reply-To: <1321651935.2883.74.camel@bwh-desktop> Date: Sat, 19 Nov 2011 11:18:08 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <1321651935.2883.74.camel@bwh-desktop> To: Ben Hutchings X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-net@freebsd.org, marius@freebsd.org Subject: Re: sfxge: Fix if_baudrate reports X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 09:18:09 -0000 On 18 Nov 2011, at 23:32, Ben Hutchings wrote: > sfxge: Fix if_baudrate reports > > This field is supposed to be set to the interface bit rate, but for > some reason I thought it was denominated in kilobits. Multiply the > values up accordingly, taking care to saturate rather than overflow on > 32-bit architectures. Committed. Thanks! - Philip -- Philip Paeps Senior Reality Engineer Ministry of Information From owner-freebsd-net@FreeBSD.ORG Sat Nov 19 09:20:33 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8007E106564A; Sat, 19 Nov 2011 09:20:33 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from rincewind.paeps.cx (rincewind.paeps.cx [IPv6:2002:596a:f092::149]) by mx1.freebsd.org (Postfix) with ESMTP id 477628FC14; Sat, 19 Nov 2011 09:20:33 +0000 (UTC) Received: from [192.168.2.103] (IGLD-84-229-200-171.inter.net.il [84.229.200.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: philip) by rincewind.paeps.cx (Postfix) with ESMTPSA id 0B281D744B0; Sat, 19 Nov 2011 10:20:25 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Philip Paeps In-Reply-To: <1321652051.2883.76.camel@bwh-desktop> Date: Sat, 19 Nov 2011 11:20:33 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <1321652051.2883.76.camel@bwh-desktop> To: Ben Hutchings X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-net@freebsd.org, marius@freebsd.org Subject: Re: sfxge: Remove interrupt self-test code X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 09:20:33 -0000 On 18 Nov 2011, at 23:34, Ben Hutchings wrote: > sfxge: Remove interrupt self-test code > > It's not currently used; it didn't build on 32-bit and the previous > build fix is incorrect. If we really implement self-tests we can do > this again properly. Committed. Thanks! Have you had a chance to see if the driver still works on i386? If so, I'll enable it again in the i386 build, now that it compiles again. - Philip -- Philip Paeps Senior Reality Engineer Ministry of Information From owner-freebsd-net@FreeBSD.ORG Sat Nov 19 11:57:21 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E77421065670 for ; Sat, 19 Nov 2011 11:57:21 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from mailhost.dlr.de (mailhost.dlr.de [129.247.252.33]) by mx1.freebsd.org (Postfix) with ESMTP id 55EB98FC0A for ; Sat, 19 Nov 2011 11:57:21 +0000 (UTC) Received: from DLREXHUB01.intra.dlr.de (172.21.152.130) by dlrexedge02.dlr.de (172.21.163.101) with Microsoft SMTP Server (TLS) id 14.1.339.1; Sat, 19 Nov 2011 12:46:05 +0100 Received: from DLREXMBX02.intra.dlr.de ([fe80::8cc6:b83e:ddc1:4e8b]) by dlrexhub01.intra.dlr.de ([::1]) with mapi id 14.01.0339.002; Sat, 19 Nov 2011 12:46:05 +0100 From: To: , Thread-Topic: confused with if_baudrate Thread-Index: AQHMpXEifT4z59Svcky9mLmJ56EfpZWxhxkAgAGFnACAAQkYPw== Date: Sat, 19 Nov 2011 11:46:05 +0000 Message-ID: <611243783F62AF48AFB07BC25FA4B1060BE5F4C7@dlrexmbx02.intra.dlr.de> References: , In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.136.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: freebsd-net@freebsd.org Subject: RE: confused with if_baudrate X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 11:57:22 -0000 Hi,=0A= =0A= the 64-bit statistics counters are also likely to be wrong, if the polling = interval is too short (it is determined by the interface in the system with= the highest baudrate). This can be fixed by setting begemotIfPoll to an ap= propriate value in bsnmp, though.=0A= =0A= harti=0A= ________________________________________=0A= From: owner-freebsd-net@freebsd.org [owner-freebsd-net@freebsd.org] on beha= lf of Maksim Yevmenkin [maksim.yevmenkin@gmail.com]=0A= Sent: Friday, November 18, 2011 9:53 PM=0A= To: Juli Mallett=0A= Cc: freebsd-net=0A= Subject: Re: confused with if_baudrate=0A= =0A= On Thu, Nov 17, 2011 at 1:39 PM, Juli Mallett wrote:= =0A= > On Thu, Nov 17, 2011 at 13:12, Maksim Yevmenkin=0A= > wrote:=0A= >> hello,=0A= >>=0A= >> i'm a little bit confused about if_baudrate. from system headers=0A= >>=0A= >> #define if_baudrate if_data.ifi_baudrate=0A= >>=0A= >> and=0A= >>=0A= >> u_long ifi_baudrate; /* linespeed */=0A= >>=0A= >> so, i'm taking this as if_baudrate really should be an interface line=0A= >> speed in megabits per second. am i correct? if so, then it appears=0A= >> that at least some drivers lie about true line speed. for example from= =0A= >> ixgbe(4)=0A= >>=0A= >> ifp->if_baudrate =3D 1000000000;=0A= >>=0A= >> it looks like its order of magnitude lower (i.e. 1 gigabit per second=0A= >> instead of 10 gigabits per second). am i missing something here or its= =0A= >> just a typo?=0A= >=0A= > ixgbe's developer is excessively concerned about overflow on 32-bit=0A= > hosts (and unwilling to correct it under a preprocessor conditional),=0A= > unlike several of the other 10GbE driver developers, although I think=0A= > one 10GbE driver opts to omit if_baudrate entirely.=0A= =0A= well, this is unfortunate as if_baudrate reported as part of ifmib,=0A= so, when interface is monitored over snmp value of ifSpeed and=0A= HCOutSpeed can not be trusted :(=0A= =0A= thanks,=0A= max=0A= _______________________________________________=0A= freebsd-net@freebsd.org mailing list=0A= http://lists.freebsd.org/mailman/listinfo/freebsd-net=0A= To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"=0A= =0A=