From owner-freebsd-net@FreeBSD.ORG Sun Apr 13 03:09:22 2008 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 65F69106564A for ; Sun, 13 Apr 2008 03:09:22 +0000 (UTC) (envelope-from tmm@fastmail.fm) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 2FDAE8FC2B for ; Sun, 13 Apr 2008 03:09:22 +0000 (UTC) (envelope-from tmm@fastmail.fm) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id AE069EC5CB; Sat, 12 Apr 2008 23:09:21 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sat, 12 Apr 2008 23:09:21 -0400 X-Sasl-enc: aUgcBj0rXDJ/V+usmGr2XF1s9sjPkfKLCWv3L4qnnohz 1208056161 Received: from [192.168.11.3] (bas4-toronto46-1279334009.dsl.bell.ca [76.65.22.121]) by mail.messagingengine.com (Postfix) with ESMTPSA id 2A93C40E2; Sat, 12 Apr 2008 23:09:21 -0400 (EDT) Message-ID: <48017958.8020302@fastmail.fm> Date: Sat, 12 Apr 2008 23:09:12 -0400 From: tmm User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <4800E2D5.20107@fastmail.fm> <480147C7.6090107@FreeBSD.org> In-Reply-To: <480147C7.6090107@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Howto send a limited broadcast? 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 Apr 2008 03:09:22 -0000 Bruce M. Simpson wrote: > tmm wrote: >> So, can anyone suggest how I can send a limited broadcast (on an >> interface that has been initalized with an IP and a subnet)? > > Use the IP_ONESBCAST option and send to the network broadcast address > for that subnet. The stack will change it into 255.255.255.255 on > output. See man page ip(4) for details. > > It's a hack, but it's largely due to how the stack has worked > historically. > > BMS Thanks. I wasn't aware of that option. But now I find that this option is not present in my (eCos port of) FreeBSD stack. Either it was removed during the port, or the ported version is too old. Perhaps the best thing for me to do is to look at the 'normal' FreeBSD stack (as opposed to the eCos one) and see how IP_ONESBCAST is implemented. Then perhaps I could do the same thing in my FreeBSD stack. Is there a way for me to download the FreeBSD source code without actually downloading, burning, and installing FreeBSD? Looking around the FreeBSD website I don't see a source download link. thanks, Tom. From owner-freebsd-net@FreeBSD.ORG Sun Apr 13 06:25:11 2008 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 29EF8106564A for ; Sun, 13 Apr 2008 06:25:11 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id C956E8FC18 for ; Sun, 13 Apr 2008 06:25:10 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: (qmail 4474 invoked from network); 13 Apr 2008 05:58:28 -0000 Received: from unknown (HELO ?192.168.0.2?) (spawk@69.123.45.64) by acm.poly.edu with AES256-SHA encrypted SMTP; 13 Apr 2008 05:58:28 -0000 Message-ID: <4801A0F8.1060002@acm.poly.edu> Date: Sun, 13 Apr 2008 01:58:16 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: tmm References: <4800E2D5.20107@fastmail.fm> <480147C7.6090107@FreeBSD.org> <48017958.8020302@fastmail.fm> In-Reply-To: <48017958.8020302@fastmail.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Howto send a limited broadcast? 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 Apr 2008 06:25:11 -0000 tmm wrote: > > > Bruce M. Simpson wrote: >> tmm wrote: >>> So, can anyone suggest how I can send a limited broadcast (on an >>> interface that has been initalized with an IP and a subnet)? >> >> Use the IP_ONESBCAST option and send to the network broadcast address >> for that subnet. The stack will change it into 255.255.255.255 on >> output. See man page ip(4) for details. >> >> It's a hack, but it's largely due to how the stack has worked >> historically. >> >> BMS > Thanks. I wasn't aware of that option. > > But now I find that this option is not present in my (eCos port of) > FreeBSD stack. Either it was removed during the port, or the ported > version is too old. > > Perhaps the best thing for me to do is to look at the 'normal' FreeBSD > stack (as opposed to the eCos one) and see how IP_ONESBCAST is > implemented. Then perhaps I could do the same thing in my FreeBSD stack. > > Is there a way for me to download the FreeBSD source code without > actually downloading, burning, and installing FreeBSD? Looking around > the FreeBSD website I don't see a source download link. > > thanks, > Tom. > _______________________________________________ > 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" You can get them via CVS: http://www.freebsd.org/doc/en/books/handbook/cvsup.html. Also, although it, too, may be considered hacky, if the system you're working on has pcap(3), you could just manually craft the broadcast frame and send it out the interface yourself. I can provide some sample code. -Boris From owner-freebsd-net@FreeBSD.ORG Sun Apr 13 10:16:03 2008 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 44491106566C for ; Sun, 13 Apr 2008 10:16:03 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from gtcomm.net (web.gtcomm.net [72.10.164.67]) by mx1.freebsd.org (Postfix) with ESMTP id 016BA8FC1D for ; Sun, 13 Apr 2008 10:16:02 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from [192.168.1.3] (c-76-108-179-28.hsd1.fl.comcast.net [76.108.179.28]) by gtcomm.net (8.12.20/8.12.10) with ESMTP id m3D97rgS019381 for ; Sun, 13 Apr 2008 06:07:54 -0300 Message-ID: <4801CDB5.6020008@gtcomm.net> Date: Sun, 13 Apr 2008 05:09:09 -0400 From: Paul User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Tcpdumping on lagg interface with em driver 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 Apr 2008 10:16:03 -0000 I am setting up two new FREEBSD_7 RELEASE routers. So far so good on the setup, everything looks good then I go to do some testing. I have polling enabled with high settings 500 burst 8000 max, etc. I can't check exactly because I managed to nuke the networking in the kernel somehow by doing this..... Testing with random ip packet generator sending 200kpps directly to the ip address of lagg1 interface. say 1.1.1.1 for example, so we have 200k packets/second going to 1.1.1.1 on lagg1 I do tcpdump -n -i lagg1 and that's it.. networking code dead. All interfaces are sending weird packets (corrupted,etc) I did manage one ssh login back to the box for a short period and there is no information in dmesg.. All the em interfaces on the machine (there's 8) were not working properly. The way we could ssh in was through the BCE interface but it was very shaky and eventually died off after trying to do ifconfig em6 down em7 down etc.. and back up. tcpdump -n -i lagg1 works fine without the 200kpps going to it.. Is this a known issue or something new? How can I test this? On a side note, what exactly does the lost polls and suspect polls and stalled mean? I see some incrementing slowly and would like some help tuning the polling values to rid myself of new increments of the lost/suspsect/stalled. But first this tcpdump problem should be addressed. Thank you!! Paul From owner-freebsd-net@FreeBSD.ORG Sun Apr 13 15:06:20 2008 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 C86E4106566B for ; Sun, 13 Apr 2008 15:06:20 +0000 (UTC) (envelope-from tmm@fastmail.fm) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 888B48FC0C for ; Sun, 13 Apr 2008 15:06:20 +0000 (UTC) (envelope-from tmm@fastmail.fm) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id DCCB7FEDF6; Sun, 13 Apr 2008 11:06:19 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 13 Apr 2008 11:06:19 -0400 X-Sasl-enc: rfQKP4W6LoMPaAQwtpFWGCk6nqeGJTWxbUtJCOgO7Elz 1208099179 Received: from [192.168.11.3] (bas4-toronto46-1279334009.dsl.bell.ca [76.65.22.121]) by mail.messagingengine.com (Postfix) with ESMTPSA id 6365E1769D; Sun, 13 Apr 2008 11:06:19 -0400 (EDT) Message-ID: <48022162.4030601@fastmail.fm> Date: Sun, 13 Apr 2008 11:06:10 -0400 From: tmm User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Boris Kochergin References: <4800E2D5.20107@fastmail.fm> <480147C7.6090107@FreeBSD.org> <48017958.8020302@fastmail.fm> <4801A0F8.1060002@acm.poly.edu> In-Reply-To: <4801A0F8.1060002@acm.poly.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Howto send a limited broadcast? 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 Apr 2008 15:06:20 -0000 Boris Kochergin wrote: > tmm wrote: >> >> >> Bruce M. Simpson wrote: >>> tmm wrote: >>>> So, can anyone suggest how I can send a limited broadcast (on an >>>> interface that has been initalized with an IP and a subnet)? >>> >>> Use the IP_ONESBCAST option and send to the network broadcast >>> address for that subnet. The stack will change it into >>> 255.255.255.255 on output. See man page ip(4) for details. >>> >>> It's a hack, but it's largely due to how the stack has worked >>> historically. >>> >>> BMS >> Thanks. I wasn't aware of that option. >> >> But now I find that this option is not present in my (eCos port of) >> FreeBSD stack. Either it was removed during the port, or the ported >> version is too old. >> >> Perhaps the best thing for me to do is to look at the 'normal' >> FreeBSD stack (as opposed to the eCos one) and see how IP_ONESBCAST >> is implemented. Then perhaps I could do the same thing in my FreeBSD >> stack. >> >> Is there a way for me to download the FreeBSD source code without >> actually downloading, burning, and installing FreeBSD? Looking >> around the FreeBSD website I don't see a source download link. >> >> thanks, >> Tom. >> _______________________________________________ >> 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" > You can get them via CVS: > http://www.freebsd.org/doc/en/books/handbook/cvsup.html. > > Also, although it, too, may be considered hacky, if the system you're > working on has pcap(3), you could just manually craft the broadcast > frame and send it out the interface yourself. I can provide some > sample code. > > -Boris Yes, that is what I was looking for - I'll use cvsup/csup to get the sources. I don't have pcap, but I do have access to the lower layers of the stack, so yes, I would be interested in seeing your code. Doing something like that might turn out to be a better solution for me. Thanks a lot. Tom. From owner-freebsd-net@FreeBSD.ORG Sun Apr 13 17:24:46 2008 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 2D6881065675 for ; Sun, 13 Apr 2008 17:24:46 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id C86888FC19 for ; Sun, 13 Apr 2008 17:24:45 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m3DGvurZ095239 for ; Sun, 13 Apr 2008 12:57:56 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m3DGvuG6039297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 13 Apr 2008 12:57:56 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200804131657.m3DGvuG6039297@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 13 Apr 2008 12:58:03 -0400 To: freebsd-net@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: route change and MTU 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 Apr 2008 17:24:46 -0000 This sort of seems like a bug, but not sure If I had 2 interfaces, one tun1, pppoe with an MTU of 1492, and one ethernet, a normal MTU of 1500. if the default route was via tun1, and I did a route change default the MTU stays at 1492 e.g. on my RELENG_7 box 0[cage]# route add 1.1.1.1/30 64.7.157.1 add net 1.1.1.1: gateway 64.7.157.1 0[cage]# route get 1.1.1.1 route to: 1.1.1.1 destination: 1.1.1.0 mask: 255.255.255.252 gateway: dslborder1.sentex.ca interface: tun0 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1492 0 This is correct. The MTU on the PPPoE interface is 1492 0[cage]# route change 1.1.1.1/30 192.168.0.3 change net 1.1.1.1: gateway 192.168.0.3 0[cage]# route get 1.1.1.1 route to: 1.1.1.1 destination: 1.1.1.0 mask: 255.255.255.252 gateway: 192.168.0.3 interface: bge0 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1492 0 0[cage]# ifconfig bge0 bge0: flags=8843 metric 0 mtu 1500 options=9b ether 00:10:18:14:15:43 inet 192.168.0.12 netmask 0xffffff00 broadcast 192.168.0.255 media: Ethernet autoselect (100baseTX ) status: active 0[cage]# The MTU should be 1500 after the route change no ? ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-net@FreeBSD.ORG Mon Apr 14 02:28:28 2008 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 B142F106566C for ; Mon, 14 Apr 2008 02:28:28 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 647A28FC21 for ; Mon, 14 Apr 2008 02:28:28 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: (qmail 12520 invoked from network); 14 Apr 2008 02:28:26 -0000 Received: from unknown (HELO ?192.168.0.2?) (spawk@69.123.45.64) by acm.poly.edu with AES256-SHA encrypted SMTP; 14 Apr 2008 02:28:26 -0000 Message-ID: <4802C140.9020304@acm.poly.edu> Date: Sun, 13 Apr 2008 22:28:16 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: tmm References: <4800E2D5.20107@fastmail.fm> <480147C7.6090107@FreeBSD.org> <48017958.8020302@fastmail.fm> <4801A0F8.1060002@acm.poly.edu> <48022162.4030601@fastmail.fm> In-Reply-To: <48022162.4030601@fastmail.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Howto send a limited broadcast? 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 Apr 2008 02:28:28 -0000 tmm wrote: > Boris Kochergin wrote: >> tmm wrote: >>> >>> >>> Bruce M. Simpson wrote: >>>> tmm wrote: >>>>> So, can anyone suggest how I can send a limited broadcast (on an >>>>> interface that has been initalized with an IP and a subnet)? >>>> >>>> Use the IP_ONESBCAST option and send to the network broadcast >>>> address for that subnet. The stack will change it into >>>> 255.255.255.255 on output. See man page ip(4) for details. >>>> >>>> It's a hack, but it's largely due to how the stack has worked >>>> historically. >>>> >>>> BMS >>> Thanks. I wasn't aware of that option. >>> >>> But now I find that this option is not present in my (eCos port of) >>> FreeBSD stack. Either it was removed during the port, or the ported >>> version is too old. >>> >>> Perhaps the best thing for me to do is to look at the 'normal' >>> FreeBSD stack (as opposed to the eCos one) and see how IP_ONESBCAST >>> is implemented. Then perhaps I could do the same thing in my >>> FreeBSD stack. >>> >>> Is there a way for me to download the FreeBSD source code without >>> actually downloading, burning, and installing FreeBSD? Looking >>> around the FreeBSD website I don't see a source download link. >>> >>> thanks, >>> Tom. >>> _______________________________________________ >>> 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" >> You can get them via CVS: >> http://www.freebsd.org/doc/en/books/handbook/cvsup.html. >> >> Also, although it, too, may be considered hacky, if the system you're >> working on has pcap(3), you could just manually craft the broadcast >> frame and send it out the interface yourself. I can provide some >> sample code. >> >> -Boris > Yes, that is what I was looking for - I'll use cvsup/csup to get the > sources. > > I don't have pcap, but I do have access to the lower layers of the > stack, so yes, I would be interested in seeing your code. Doing > something like that might turn out to be a better solution for me. > > Thanks a lot. > Tom. > _______________________________________________ > 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" http://acm.poly.edu/~spawk/arpCounterattack.tbz That's some code I wrote a while ago that detects ARP attacks against a configured set of IP/Ethernet address pairs on broadcast networks, and sends out gratuitous ARP requests in an attempt to correct the situation. The relevant function here is sendGratuitousARPRequest() in arpCounterattack.hpp. It constructs a gratuitous ARP frame and sends it out the configured interface. -Boris From owner-freebsd-net@FreeBSD.ORG Mon Apr 14 04:18:16 2008 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 D2FFB106564A; Mon, 14 Apr 2008 04:18:16 +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 AC0608FC28; Mon, 14 Apr 2008 04:18:16 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3E4IGpv022563; Mon, 14 Apr 2008 04:18:16 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3E4IGw3022559; Mon, 14 Apr 2008 04:18:16 GMT (envelope-from linimon) Date: Mon, 14 Apr 2008 04:18:16 GMT Message-Id: <200804140418.m3E4IGw3022559@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/122697: [ath] Atheros card is not well supported 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 Apr 2008 04:18:16 -0000 Old Synopsis: Atheros card is not well supported New Synopsis: [ath] Atheros card is not well supported Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Apr 14 04:17:09 UTC 2008 Responsible-Changed-Why: Reclassify. I'll note that the D-Link cards have the same label on things with different internals (I have one of these cards). http://www.freebsd.org/cgi/query-pr.cgi?pr=122697 From owner-freebsd-net@FreeBSD.ORG Mon Apr 14 09:02:15 2008 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 C07591065670 for ; Mon, 14 Apr 2008 09:02:15 +0000 (UTC) (envelope-from marc.loerner@hob.de) Received: from mailgate.hob.de (mailgate.hob.de [212.185.199.3]) by mx1.freebsd.org (Postfix) with ESMTP id 86D148FC16 for ; Mon, 14 Apr 2008 09:02:15 +0000 (UTC) (envelope-from marc.loerner@hob.de) Received: from imap.hob.de (mail2.hob.de [172.25.1.102]) by mailgate.hob.de (Postfix) with ESMTP id DBE8D164442 for ; Mon, 14 Apr 2008 10:33:44 +0200 (CEST) Received: from [172.22.0.190] (linux03.hob.de [172.22.0.190]) by imap.hob.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 84274FCBBE for ; Mon, 14 Apr 2008 10:33:44 +0200 (CEST) From: Marc =?iso-8859-1?q?L=F6rner?= Organization: hob Date: Mon, 14 Apr 2008 10:33:35 +0200 User-Agent: KMail/1.6.2 To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200804141033.35918.marc.loerner@hob.de> Subject: problem in if_tap.c 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 Apr 2008 09:02:15 -0000 Hello, I found the following problem in the if_tap-device code in function tapcreate when used on 64-bit systems: TAPDEBUG("tapcreate(%s%d). minor = %#x\n", name, unit, minor(dev)); /* generate fake MAC address: 00 bd xx xx xx unit_no */ macaddr_hi = htons(0x00bd); bcopy(&macaddr_hi, eaddr, sizeof(short)); ----> bcopy(&ticks, &eaddr[2], sizeof(long)); eaddr[5] = (u_char)unit; /* fill the rest and attach interface */ sizeof(long) is not always 4 on any system (e.g. on ia64 it's 8) => bytes are copied from undefined memory into undefined memory Regards, Marc P.S.: On replies please cc me because I'm not on the list. From owner-freebsd-net@FreeBSD.ORG Mon Apr 14 11:06:53 2008 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 9D130106566B for ; Mon, 14 Apr 2008 11:06:53 +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 8C7228FC1E for ; Mon, 14 Apr 2008 11:06:53 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3EB6rRC072309 for ; Mon, 14 Apr 2008 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3EB6rbC072305 for freebsd-net@FreeBSD.org; Mon, 14 Apr 2008 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 14 Apr 2008 11:06:53 GMT Message-Id: <200804141106.m3EB6rbC072305@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 Apr 2008 11:06:53 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/81147 net [net] [patch] em0 reinitialization while adding aliase s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument (regress o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ipv6] PF_INET6 proto domain state can't be cleared wi o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast f kern/116172 net [tun] [panic] Network / ipv6 recursive mutex panic o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash (regression) o kern/118880 net [ipv6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card (regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time f kern/120725 net [bce] On board second lan port 'bce1' with Broadcom Ne f kern/120966 net [rum]: kernel panic with if_rum and WPA encryption o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net Fatal trap 12: current process = 12 (swi1: net) o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] Lock order reversal in ral0 at bootup (regressio o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi 52 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o bin/79228 net [patch] extend /sbin/arp to be able to create blackhol o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/112179 net [sis] [patch] sis driver for natsemi DP83815D autonego o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [ng] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118975 net [bge] [patch] Broadcom 5906 not handled by FreeBSD o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120958 net no response to ICMP traffic on interface configured wi o kern/121242 net [ate] [patch] Promiscuous mode of if_ate (arm) doesn't o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122145 net error while compiling with device ath_rate_amrr o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) (regression) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported 40 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Apr 14 16:15:56 2008 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 184BB106566B for ; Mon, 14 Apr 2008 16:15:56 +0000 (UTC) (envelope-from mgaron@pleora.com) Received: from mail-05.primus.ca (mail6.primus.ca [216.254.141.173]) by mx1.freebsd.org (Postfix) with ESMTP id A04188FC2A for ; Mon, 14 Apr 2008 16:15:55 +0000 (UTC) (envelope-from mgaron@pleora.com) Received: from qubcpq14-1279665222.sdsl.bell.ca ([76.70.36.70] helo=argon) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JlQkN-0001PO-2e for freebsd-net@freebsd.org; Mon, 14 Apr 2008 11:37:32 -0400 From: "Martin Garon" To: Date: Mon, 14 Apr 2008 11:38:38 -0400 Organization: Pleora Technologies Inc. Message-ID: <000d01c89e45$9c5ece10$6e01a8c0@argon> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcieRZu/bPZjaDzbTHKcdykcbi6yGg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Authenticated: pleora036 - qubcpq14-1279665222.sdsl.bell.ca (argon) [76.70.36.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: IGMPv3 support 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 Apr 2008 16:15:56 -0000 Hi, I am looking for a FreeBSD release with IGMPv3 and was surprised to find none. I know the KAME project added support for IGMPv3. Anyone knows why this was not imported back into the current sources? I was wondering if it had anything to do with reliability or rather with business mumbo-jumbo. Anyone knows other who did this successfully? Regards, --Martin From owner-freebsd-net@FreeBSD.ORG Mon Apr 14 17:10:39 2008 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 9E7731065678 for ; Mon, 14 Apr 2008 17:10:39 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id 26FC38FC1B for ; Mon, 14 Apr 2008 17:10:38 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so1849756fgg.35 for ; Mon, 14 Apr 2008 10:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=dOyCmYXoUykjMcqXpyMorhl/qbyJpX6v/l6ql67wNl8=; b=MqWPARlexBjJBcLUFq7AAQWEWxjT5T21EKPEnpa8GB2cHgucEbAM5nYQiX2ewTGPYLRuHkwpfzDJBsC50q5EKVAYsfREF7LDaejkSAEV5W8IZH7NPUFg23EK9Ing8T9tHkphKuRmkXxKicXZNQF0NnyC5C71KtnpvM8EpSq9HmI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jMmeFhaPuBMjM/i/4QWAu1OSf5KRpIQ2rbdziSJTy1m43lpDRQzSoeoDX4lyoay2wTY9IQwtNqBYIHTGzWQHmQV0Dou2DzbE0jOdlMDtElbxb2YYvMjpJeVChXoIAyKJKbEN2aspzr/2v7OxlSlxg7M81bD4fezZuUJktddCoVc= Received: by 10.86.27.9 with SMTP id a9mr13804140fga.62.1208191535920; Mon, 14 Apr 2008 09:45:35 -0700 (PDT) Received: by 10.86.71.15 with HTTP; Mon, 14 Apr 2008 09:45:33 -0700 (PDT) Message-ID: Date: Mon, 14 Apr 2008 09:45:33 -0700 From: "Maksim Yevmenkin" To: "=?ISO-8859-1?Q?Marc_L=F6rner?=" In-Reply-To: <200804141033.35918.marc.loerner@hob.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200804141033.35918.marc.loerner@hob.de> Cc: freebsd-net@freebsd.org Subject: Re: problem in if_tap.c 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 Apr 2008 17:10:39 -0000 On Mon, Apr 14, 2008 at 1:33 AM, Marc L=F6rner wrote: > Hello, > I found the following problem in the if_tap-device code in function tapc= reate > when used on 64-bit systems: > > TAPDEBUG("tapcreate(%s%d). minor =3D %#x\n", name, unit, minor(dev= )); > > /* generate fake MAC address: 00 bd xx xx xx unit_no */ > macaddr_hi =3D htons(0x00bd); > bcopy(&macaddr_hi, eaddr, sizeof(short)); > > ----> > bcopy(&ticks, &eaddr[2], sizeof(long)); > eaddr[5] =3D (u_char)unit; > > /* fill the rest and attach interface */ > > sizeof(long) is not always 4 on any system (e.g. on ia64 it's 8) > =3D> bytes are copied from undefined memory into undefined memory please try the following patch. if there is no objections, i will commit it beetle# diff -u if_tap.c.orig if_tap.c --- if_tap.c.orig 2007-04-05 10:58:39.000000000 -0700 +++ if_tap.c 2008-04-14 09:42:42.000000000 -0700 @@ -404,6 +404,7 @@ struct ifnet *ifp =3D NULL; struct tap_softc *tp =3D NULL; unsigned short macaddr_hi; + uint32_t macaddr_mid; int unit, s; char *name =3D NULL; u_char eaddr[6]; @@ -432,8 +433,9 @@ /* generate fake MAC address: 00 bd xx xx xx unit_no */ macaddr_hi =3D htons(0x00bd); + macaddr_mid =3D (uint32_t) ticks; bcopy(&macaddr_hi, eaddr, sizeof(short)); - bcopy(&ticks, &eaddr[2], sizeof(long)); + bcopy(&macaddr_mid, &eaddr[2], sizeof(uint32_t)); eaddr[5] =3D (u_char)unit; /* fill the rest and attach interface */ thanks, max From owner-freebsd-net@FreeBSD.ORG Mon Apr 14 18:40:07 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 2CD7B106564A; Mon, 14 Apr 2008 18:40:06 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-net@FreeBSD.org Date: Mon, 14 Apr 2008 14:39:48 -0400 User-Agent: KMail/1.6.2 References: <20080412062251.GA2199@svzserv.kemerovo.su> In-Reply-To: <20080412062251.GA2199@svzserv.kemerovo.su> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_4T6AI2V2Lk3dFXI" Message-Id: <200804141439.52231.jkim@FreeBSD.org> Cc: Eugene Grosbein Subject: Re: bpf does not see packets forwarded with ipfw fwd 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 Apr 2008 18:40:07 -0000 --Boundary-00=_4T6AI2V2Lk3dFXI Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Saturday 12 April 2008 02:22 am, Eugene Grosbein wrote: > Hi! > > One of 7.0 users has reported in some cyrillic newsgroup > a problem that I have reproduced in my 7.0-STABLE system. > That is: tcpdump does not show locally originated outgoing IP > packets that were processed by 'ipfw fwd' rule. The same > configuration presents no problems with 6.3-STABLE. > > Consider simple schema: two FreeBSD boxes (A and B) directly > connected with ethernet intefaces. The box A has another ethernet > interface and uses "ipfw fwd" as its very first ipfw rule to > forward some packets to B, while these packets would normally go > out trough mentioned another interface. Now, tcpdump does NOT show > outgoing packets but host B also runs tcpdump on its incoming > interface and does see them. > > I double-checked all paramerets for tcpdump, all routing tables. > I even connected A and B with cross-over ethernet cable, without a > switch. Still, B sees incoming packets coming over the cable and A > does not see them leaving. This bothers me a bit :-) Can you try the attached patch? Thanks! Jung-uk Kim --Boundary-00=_4T6AI2V2Lk3dFXI Content-Type: text/plain; charset="iso-8859-1"; name="bpf.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="bpf.diff" Index: sys/net/bpf.c =================================================================== RCS file: /home/ncvs/src/sys/net/bpf.c,v retrieving revision 1.191 diff -u -r1.191 bpf.c --- sys/net/bpf.c 7 Apr 2008 02:51:00 -0000 1.191 +++ sys/net/bpf.c 14 Apr 2008 18:37:07 -0000 @@ -88,8 +88,6 @@ #define PRINET 26 /* interruptible */ -#define M_SKIP_BPF M_SKIP_FIREWALL - /* * bpf_iflist is a list of BPF interface structures, each corresponding to a * specific DLT. The same network interface might have several BPF interface @@ -843,9 +841,9 @@ mc = m_dup(m, M_DONTWAIT); if (mc != NULL) mc->m_pkthdr.rcvif = ifp; - /* XXX Do not return the same packet twice. */ + /* Set M_PROMISC as it is seen already. */ if (d->bd_direction == BPF_D_INOUT) - m->m_flags |= M_SKIP_BPF; + m->m_flags |= M_PROMISC; } else mc = NULL; @@ -1588,8 +1586,9 @@ int gottime; struct timeval tv; - if (m->m_flags & M_SKIP_BPF) { - m->m_flags &= ~M_SKIP_BPF; + /* Clear M_PROMISC if it is re-entered. */ + if (m->m_flags & M_PROMISC) { + m->m_flags &= ~M_PROMISC; return; } @@ -1642,8 +1641,9 @@ int gottime; struct timeval tv; - if (m->m_flags & M_SKIP_BPF) { - m->m_flags &= ~M_SKIP_BPF; + /* Clear M_PROMISC if it is re-entered. */ + if (m->m_flags & M_PROMISC) { + m->m_flags &= ~M_PROMISC; return; } --Boundary-00=_4T6AI2V2Lk3dFXI-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 14 20:30:10 2008 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 2AD6B1065672; Mon, 14 Apr 2008 20:30:10 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 035218FC17; Mon, 14 Apr 2008 20:30:10 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (vwe@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3EKU9Xn031425; Mon, 14 Apr 2008 20:30:09 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3EKU9vo031419; Mon, 14 Apr 2008 20:30:09 GMT (envelope-from vwe) Date: Mon, 14 Apr 2008 20:30:09 GMT Message-Id: <200804142030.m3EKU9vo031419@freefall.freebsd.org> To: vwe@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: kern/122743: [panic] vm_page_unwire: invalid wire count: 0 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 Apr 2008 20:30:10 -0000 Old Synopsis: panic: vm_page_unwire: invalid wire count: 0 New Synopsis: [panic] vm_page_unwire: invalid wire count: 0 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Mon Apr 14 20:27:51 UTC 2008 Responsible-Changed-Why: while this is looking like a vm fault, it seems to be caused by the network subsystem having a problem in mbuf handling. Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=122743 From owner-freebsd-net@FreeBSD.ORG Mon Apr 14 23:50:50 2008 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 44621106564A; Mon, 14 Apr 2008 23:50:50 +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 1C1658FC2D; Mon, 14 Apr 2008 23:50:50 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3ENonfO049384; Mon, 14 Apr 2008 23:50:49 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3ENonpm049380; Mon, 14 Apr 2008 23:50:49 GMT (envelope-from linimon) Date: Mon, 14 Apr 2008 23:50:49 GMT Message-Id: <200804142350.m3ENonpm049380@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/122744: [tcp] [panic] [patch] hostcache: supervisor read, page not present 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 Apr 2008 23:50:50 -0000 Old Synopsis: [panic] hostcache: supervisor read, page not present New Synopsis: [tcp] [panic] [patch] hostcache: supervisor read, page not present Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Apr 14 23:49:46 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=122744 From owner-freebsd-net@FreeBSD.ORG Mon Apr 14 23:51:21 2008 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 6DDE81065683; Mon, 14 Apr 2008 23:51:21 +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 456508FC2D; Mon, 14 Apr 2008 23:51:21 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3ENpL76049460; Mon, 14 Apr 2008 23:51:21 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3ENpL9l049456; Mon, 14 Apr 2008 23:51:21 GMT (envelope-from linimon) Date: Mon, 14 Apr 2008 23:51:21 GMT Message-Id: <200804142351.m3ENpL9l049456@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/122772: [em] em0 taskq panic, tcp reassembly bug causes radix tree corruption? 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 Apr 2008 23:51:21 -0000 Synopsis: [em] em0 taskq panic, tcp reassembly bug causes radix tree corruption? Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Apr 14 23:51:14 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=122772 From owner-freebsd-net@FreeBSD.ORG Tue Apr 15 02:47:54 2008 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 8C222106564A; Tue, 15 Apr 2008 02:47:54 +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 622748FC1A; Tue, 15 Apr 2008 02:47:54 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3F2lsiF065124; Tue, 15 Apr 2008 02:47:54 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3F2lshc065120; Tue, 15 Apr 2008 02:47:54 GMT (envelope-from linimon) Date: Tue, 15 Apr 2008 02:47:54 GMT Message-Id: <200804150247.m3F2lshc065120@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: amd64/122780: [lagg] tcpdump on lagg interface during high pps wedges netcode 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 Apr 2008 02:47:54 -0000 Old Synopsis: tcpdump on lagg interface during high pps wedges netcode New Synopsis: [lagg] tcpdump on lagg interface during high pps wedges netcode Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Apr 15 02:47:08 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=122780 From owner-freebsd-net@FreeBSD.ORG Tue Apr 15 03:44:07 2008 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 4190D106566B for ; Tue, 15 Apr 2008 03:44:07 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 7DF6F8FC14 for ; Tue, 15 Apr 2008 03:44:06 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m3F3i3c5020589; Tue, 15 Apr 2008 11:44:03 +0800 (KRAST) (envelope-from eugen@kuzbass.ru) Message-ID: <48042484.635960FE@kuzbass.ru> Date: Tue, 15 Apr 2008 11:44:04 +0800 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: Jung-uk Kim References: <20080412062251.GA2199@svzserv.kemerovo.su> <200804141439.52231.jkim@FreeBSD.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: bpf does not see packets forwarded with ipfw fwd 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 Apr 2008 03:44:07 -0000 Jung-uk Kim wrote: > Can you try the attached patch? I will this evening when get to my 7.0 home system. From owner-freebsd-net@FreeBSD.ORG Tue Apr 15 06:38:31 2008 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 4F83A1065671 for ; Tue, 15 Apr 2008 06:38:31 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 24A398FC18 for ; Tue, 15 Apr 2008 06:38:31 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id A2BD1EE918; Tue, 15 Apr 2008 02:38:30 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 15 Apr 2008 02:38:30 -0400 X-Sasl-enc: YpJ6z+cPmDdUoLiXn1yYYKkA0V+Q3YFZK8heX4zw05t/ 1208241510 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 27FCF190F1; Tue, 15 Apr 2008 02:38:30 -0400 (EDT) Message-ID: <48044D65.4040600@FreeBSD.org> Date: Tue, 15 Apr 2008 07:38:29 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.12 (X11/20080405) MIME-Version: 1.0 To: Martin Garon References: <000d01c89e45$9c5ece10$6e01a8c0@argon> In-Reply-To: <000d01c89e45$9c5ece10$6e01a8c0@argon> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: IGMPv3 support 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 Apr 2008 06:38:31 -0000 Martin Garon wrote: > I am looking for a FreeBSD release with IGMPv3 and was surprised to find > none. > > I know the KAME project added support for IGMPv3. Anyone knows why this was > not imported back into the current sources? I was wondering if it had > anything to do with reliability or rather with business mumbo-jumbo. > I am actively working on this right now. Please see the bms_netdev branch in p4 for progress. The code there must be considered pre-alpha, it's a development branch. At the moment I am constructing baseline regression tests to make sure that everything works according to spec. It's harder than it looks as there are a few places where the delta-based vs the SSM API can lead to inconsistency and the specs are not completely unambiguous. cheers BMS From owner-freebsd-net@FreeBSD.ORG Tue Apr 15 06:40:40 2008 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 AFCD9106564A for ; Tue, 15 Apr 2008 06:40:40 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 82D608FC20 for ; Tue, 15 Apr 2008 06:40:40 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 3471FEDDEA; Tue, 15 Apr 2008 02:40:40 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 15 Apr 2008 02:40:40 -0400 X-Sasl-enc: 2mW1NyC4SIRUU84Hb8a3lFYW3jCody75c9d5wi7551ER 1208241639 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id A130D1B898; Tue, 15 Apr 2008 02:40:39 -0400 (EDT) Message-ID: <48044DE6.8070600@FreeBSD.org> Date: Tue, 15 Apr 2008 07:40:38 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.12 (X11/20080405) MIME-Version: 1.0 To: Maksim Yevmenkin References: <200804141033.35918.marc.loerner@hob.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, =?ISO-8859-1?Q?Marc_L=F6rner?= Subject: Re: problem in if_tap.c 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 Apr 2008 06:40:40 -0000 Maksim Yevmenkin wrote: > please try the following patch. if there is no objections, i will commit it > > beetle# diff -u if_tap.c.orig if_tap.c > --- if_tap.c.orig 2007-04-05 10:58:39.000000000 -0700 > +++ if_tap.c 2008-04-14 09:42:42.000000000 -0700 > @@ -404,6 +404,7 @@ > struct ifnet *ifp = NULL; > struct tap_softc *tp = NULL; > unsigned short macaddr_hi; > + uint32_t macaddr_mid; > int unit, s; > char *name = NULL; > u_char eaddr[6]; > @@ -432,8 +433,9 @@ > > /* generate fake MAC address: 00 bd xx xx xx unit_no */ > macaddr_hi = htons(0x00bd); > + macaddr_mid = (uint32_t) ticks; > bcopy(&macaddr_hi, eaddr, sizeof(short)); > - bcopy(&ticks, &eaddr[2], sizeof(long)); > + bcopy(&macaddr_mid, &eaddr[2], sizeof(uint32_t)); > eaddr[5] = (u_char)unit; > > /* fill the rest and attach interface */ > This patch looks good, please commit. [Unless of course we want the autogenerated MAC to be deterministic for some reason, but given that it comes from a timer, there's not much point in fixing the endianness...] cheers BMS From owner-freebsd-net@FreeBSD.ORG Tue Apr 15 13:51:13 2008 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 5D786106566B for ; Tue, 15 Apr 2008 13:51:13 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (grgw.svzserv.kemerovo.su [213.184.64.166]) by mx1.freebsd.org (Postfix) with ESMTP id 860278FC0A for ; Tue, 15 Apr 2008 13:51:11 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (localhost [127.0.0.1]) by grosbein.pp.ru (8.14.2/8.14.2) with ESMTP id m3FDp6RV001697; Tue, 15 Apr 2008 21:51:06 +0800 (KRAST) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.14.2/8.14.2/Submit) id m3FDp6uL001696; Tue, 15 Apr 2008 21:51:06 +0800 (KRAST) (envelope-from eugen) Date: Tue, 15 Apr 2008 21:51:06 +0800 From: Eugene Grosbein To: net@freebsd.org Message-ID: <20080415135105.GA1683@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200804141439.52231.jkim@FreeBSD.org> User-Agent: Mutt/1.4.2.2i Cc: Jung-uk Kim Subject: Re: bpf does not see packets forwarded with ipfw fwd 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 Apr 2008 13:51:13 -0000 > Can you try the attached patch? Works for me :-) Thanks! Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Tue Apr 15 15:05:57 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 3D5B91065672; Tue, 15 Apr 2008 15:05:57 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-net@FreeBSD.org Date: Tue, 15 Apr 2008 11:05:46 -0400 User-Agent: KMail/1.6.2 References: <20080415135105.GA1683@grosbein.pp.ru> In-Reply-To: <20080415135105.GA1683@grosbein.pp.ru> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200804151105.47569.jkim@FreeBSD.org> Cc: Eugene Grosbein Subject: Re: bpf does not see packets forwarded with ipfw fwd 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 Apr 2008 15:05:57 -0000 On Tuesday 15 April 2008 09:51 am, Eugene Grosbein wrote: > > Can you try the attached patch? > > Works for me :-) Sorry, I committed a different version: http://docs.freebsd.org/cgi/mid.cgi?200804150050.m3F0o1aV091591 This patch does not touch m_flags any more. Can you test it again? Thanks! Jung-uk Kim From owner-freebsd-net@FreeBSD.ORG Tue Apr 15 15:08:04 2008 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 01730106566B; Tue, 15 Apr 2008 15:08:04 +0000 (UTC) (envelope-from andre@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CB1018FC18; Tue, 15 Apr 2008 15:08:03 +0000 (UTC) (envelope-from andre@FreeBSD.org) Received: from freefall.freebsd.org (andre@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3FF83jN043595; Tue, 15 Apr 2008 15:08:03 GMT (envelope-from andre@freefall.freebsd.org) Received: (from andre@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3FF8356043591; Tue, 15 Apr 2008 15:08:03 GMT (envelope-from andre) Date: Tue, 15 Apr 2008 15:08:03 GMT Message-Id: <200804151508.m3FF8356043591@freefall.freebsd.org> To: andre@FreeBSD.org, freebsd-net@FreeBSD.org, andre@FreeBSD.org From: andre@FreeBSD.org Cc: Subject: Re: kern/122744: [tcp] [panic] [patch] hostcache: supervisor read, page not present 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 Apr 2008 15:08:04 -0000 Synopsis: [tcp] [panic] [patch] hostcache: supervisor read, page not present Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Tue Apr 15 15:07:30 UTC 2008 Responsible-Changed-Why: Take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=122744 From owner-freebsd-net@FreeBSD.ORG Tue Apr 15 16:11:35 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id EBC8E1065675; Tue, 15 Apr 2008 16:11:34 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-net@FreeBSD.org Date: Tue, 15 Apr 2008 12:11:14 -0400 User-Agent: KMail/1.6.2 References: <20080415135105.GA1683@grosbein.pp.ru> <200804151105.47569.jkim@FreeBSD.org> In-Reply-To: <200804151105.47569.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200804151211.22763.jkim@FreeBSD.org> Cc: Eugene Grosbein Subject: Re: bpf does not see packets forwarded with ipfw fwd 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 Apr 2008 16:11:35 -0000 On Tuesday 15 April 2008 11:05 am, Jung-uk Kim wrote: > On Tuesday 15 April 2008 09:51 am, Eugene Grosbein wrote: > > > Can you try the attached patch? > > > > Works for me :-) > > Sorry, I committed a different version: > > http://docs.freebsd.org/cgi/mid.cgi?200804150050.m3F0o1aV091591 > > This patch does not touch m_flags any more. Can you test it again? Grrr... Never mind. This patch broke feedback mode. I will fix it soon and let you know. Sorry for the noise. Jung-uk Kim From owner-freebsd-net@FreeBSD.ORG Tue Apr 15 17:08:56 2008 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 DB0AE106566B for ; Tue, 15 Apr 2008 17:08:56 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id DD0D78FC22 for ; Tue, 15 Apr 2008 17:08:55 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so617461nfb.33 for ; Tue, 15 Apr 2008 10:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=lclKPUeiHYr1MUtu0G0DZEGpsCoDeWaL2b+HwTVoBdc=; b=tp8JLeIIfRcse/68w/ioAsIoeZsF38mlrRnqTSdd3G5CIMbf/ZcByhlwkkBJ2vehVxsgANkctVjko0ALvSyIVaSLaAJKnq0vmHNUvEvhpNh/6pA7FUqeG5ottTxb7bvqEvR+86Bzc3Cpjd0GO1nFShPouAz/oGhw7l2LZv8f0MM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=l5EeK/A94XeuC8D+fW2cTwz5c5nebHR40FXjbr6Dlis7DTWSIbYX8cKrgLeaRdDp5lTfUl2gpQ1nz7gUMuVpOXWCjBOU7tqV+kjMhbko7lOyBmFr5uJ5PPh7nRsyb7cjB1hBIy/yTQpD6on1kBK1ftrih4bNyyNnPoWJdBsX11Y= Received: by 10.86.89.4 with SMTP id m4mr16526140fgb.12.1208279333213; Tue, 15 Apr 2008 10:08:53 -0700 (PDT) Received: by 10.86.71.15 with HTTP; Tue, 15 Apr 2008 10:08:53 -0700 (PDT) Message-ID: Date: Tue, 15 Apr 2008 10:08:53 -0700 From: "Maksim Yevmenkin" To: "Bruce M. Simpson" In-Reply-To: <48044DE6.8070600@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200804141033.35918.marc.loerner@hob.de> <48044DE6.8070600@FreeBSD.org> Cc: freebsd-net@freebsd.org, =?ISO-8859-1?Q?Marc_L=F6rner?= Subject: Re: problem in if_tap.c 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 Apr 2008 17:08:56 -0000 On 4/14/08, Bruce M. Simpson wrote: > Maksim Yevmenkin wrote: > > > please try the following patch. if there is no objections, i will commit > it [...] > > This patch looks good, please commit. committed. thanks for the report and review. thanks, max From owner-freebsd-net@FreeBSD.ORG Tue Apr 15 17:16:35 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id F0E7C106566C; Tue, 15 Apr 2008 17:16:34 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-net@FreeBSD.org Date: Tue, 15 Apr 2008 13:16:23 -0400 User-Agent: KMail/1.6.2 References: <20080415135105.GA1683@grosbein.pp.ru> <200804151105.47569.jkim@FreeBSD.org> <200804151211.22763.jkim@FreeBSD.org> In-Reply-To: <200804151211.22763.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200804151316.25622.jkim@FreeBSD.org> Cc: Eugene Grosbein Subject: Re: bpf does not see packets forwarded with ipfw fwd 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 Apr 2008 17:16:35 -0000 On Tuesday 15 April 2008 12:11 pm, Jung-uk Kim wrote: > On Tuesday 15 April 2008 11:05 am, Jung-uk Kim wrote: > > On Tuesday 15 April 2008 09:51 am, Eugene Grosbein wrote: > > > > Can you try the attached patch? > > > > > > Works for me :-) > > > > Sorry, I committed a different version: > > > > http://docs.freebsd.org/cgi/mid.cgi?200804150050.m3F0o1aV091591 > > > > This patch does not touch m_flags any more. Can you test it > > again? > > Grrr... Never mind. This patch broke feedback mode. I will fix > it soon and let you know. Okay, it is fixed now as I promised. :-) http://docs.freebsd.org/cgi/mid.cgi?200804151708.m3FH8OXG001024 The cumulative patch to fix the problem: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/bpf.c.diff?r1=1.191&r2=1.193 Jung-uk Kim From owner-freebsd-net@FreeBSD.ORG Tue Apr 15 18:20:10 2008 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 A62CE106564A for ; Tue, 15 Apr 2008 18:20:10 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: from hal.rescomp.berkeley.edu (hal.Rescomp.Berkeley.EDU [169.229.70.150]) by mx1.freebsd.org (Postfix) with ESMTP id 9146A8FC16 for ; Tue, 15 Apr 2008 18:20:10 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: by hal.rescomp.berkeley.edu (Postfix, from userid 1225) id 797463C04F0; Tue, 15 Apr 2008 11:20:10 -0700 (PDT) Date: Tue, 15 Apr 2008 11:20:04 -0700 From: Christopher Cowart To: net@freebsd.org Message-ID: <20080415182004.GB27135@hal.rescomp.berkeley.edu> References: <20080412223645.GN81568@hal.rescomp.berkeley.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K8nIJk4ghYZn606h" Content-Disposition: inline In-Reply-To: <20080412223645.GN81568@hal.rescomp.berkeley.edu> Organization: RSSP-IT, UC Berkeley User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: Redirect functionality in ng_nat 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 Apr 2008 18:20:10 -0000 --K8nIJk4ghYZn606h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Christopher Cowart wrote: > I'm a little confused on exactly how to pass a struct as a message to a > netgraph node via ngctl. What am I missing here? I found my answer in the comments of src/sys/netgraph/ng_parse.h: | Structures: | | '{' [ =3D ... ] '}' | | Omitted fields have their default values by implication. | The order in which the fields are specified does not matter. So the command I was looking for was: $ ngctl msg NatNode10: redirectaddr '{ local_addr=3D10.9.128.19=20 alias_addr=3D169.229.127.53 description=3D"StaticNat" }' I hope that helps the next person who can't figure out how to pass a struct in a netgraph message. --=20 Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley --K8nIJk4ghYZn606h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iQIVAwUBSATx1CPHEDszU3zYAQIWKw//RRjINTSvO+kxTu+nsDV6xZ4RYOpvWX1y mofqp07nwbd/MJx3RqSs+8cKQk66J2NWO6mlXwPW46s1RRSddLtZBmhuiHBMx5n1 20H+1fe0WXeh1uW0oSrVq86uK0AmQQMXsAH4lQbGYpYxbxdkHFjHol9w4QpXvIic OLKzzZ0S0GAphMVRywTDgRQBwQPET8I67uQts0tvoskW2/SP6uYRlEZC5r0RGyFF M42eu+OEQ5p0DMST9/fZ1d8TI916zQt9YFJbo6Wr8GcG470VexK+Xnv35J8yEkOu YSuQrouInL6QiqOMhOUKuUS5DiQjSCYgrLMyDFhB14rjSoArA65wI5XHWD0Dz1pS UevnL5XvzV6GvY4sMgKnjZK3QaY+rs83jhIh2Wq3cNUpfk0l6PWBFcR1NO/LMLbZ Ltwuqqq7XMe28LWDY4KyKh0BR/rNSnwfwEb/ww3YY2J9G8TS4xQmgnoFk2sQPEsQ FvmrDaMM3pd+h6SyPiT+nWSJ6ohmmWJLAjEu2vMvlBEx+L47t+xjo8Z88rBYC7lL HVl8UZuAf/HUwaq4+7qB1EqpDxskI4nnPziA2TaaiCFMfZpp7WHtm+HS/4mVJeNG nx9n5x8REuaZy38DKbPPDDGyb8IT5g6vvTM8qkdhX9rMfMUL0LBEkz0tRsk2mK/G 1yzIqeYKY7g= =pzP7 -----END PGP SIGNATURE----- --K8nIJk4ghYZn606h-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 15 19:52:47 2008 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 65CED106566B; Tue, 15 Apr 2008 19:52:47 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3CA1A8FC1B; Tue, 15 Apr 2008 19:52:47 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (vwe@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3FJqlZ9067909; Tue, 15 Apr 2008 19:52:47 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3FJqlXk067905; Tue, 15 Apr 2008 19:52:47 GMT (envelope-from vwe) Date: Tue, 15 Apr 2008 19:52:47 GMT Message-Id: <200804151952.m3FJqlXk067905@freefall.freebsd.org> To: vwe@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: kern/122195: [ed] Alignment problems in if_ed 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 Apr 2008 19:52:47 -0000 Synopsis: [ed] Alignment problems in if_ed Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Tue Apr 15 19:52:28 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=122195 From owner-freebsd-net@FreeBSD.ORG Wed Apr 16 05:54:20 2008 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 273FD106564A for ; Wed, 16 Apr 2008 05:54:20 +0000 (UTC) (envelope-from berlowin@yahoo.com) Received: from web52503.mail.re2.yahoo.com (web52503.mail.re2.yahoo.com [206.190.48.186]) by mx1.freebsd.org (Postfix) with SMTP id C8B058FC15 for ; Wed, 16 Apr 2008 05:54:19 +0000 (UTC) (envelope-from berlowin@yahoo.com) Received: (qmail 34380 invoked by uid 60001); 16 Apr 2008 05:27:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=KFAmJezeW0/wpYfDxWQAzgHNPN7CCSKiDRLXrGmUGlqCuthG/g8RkVNB1TSwQN1GaRm9GtAsEbW8LXEEZCVA0DeXfUwUificjE4bnkaLOGydUw2TQIE6ZdDr2DD/7hZOkysYSd1/D2w5oBo/bF7jq1DS3iNgbAAYQxGUHCscoLc=; X-YMail-OSG: NTGrpOcVM1nC1GMn0oxenksMLjsjA6YKAPepIiseCJ1fR.jgoqNH8amlViaxf9Re6g-- Received: from [122.200.6.109] by web52503.mail.re2.yahoo.com via HTTP; Tue, 15 Apr 2008 22:27:38 PDT Date: Tue, 15 Apr 2008 22:27:38 -0700 (PDT) From: Edwin Sanjoto To: freebsd-net@freebsd.org MIME-Version: 1.0 Message-ID: <59319.33967.qm@web52503.mail.re2.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: about DNS server 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 Apr 2008 05:54:20 -0000 Hi Guyz, I want to gain access to the internet via IPv4 (with the public IP) as my Gateway and I am using pure IPv6 (not dual stack)... I just want to know how to make a DNS server in freeBSD so i can gain access to the internet via IPv4... Sorry my English is bad and i am newbie in FreeBSD...anyway i am using FreeBSD 6.3 and have already implement FAITH (Translator IPv6 to IPv4)... Help me... Thank you so much... Regards, EDWIN Sanyoto (berlowin@yahoo.com) --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. From owner-freebsd-net@FreeBSD.ORG Wed Apr 16 13:08:54 2008 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 805FA106566B for ; Wed, 16 Apr 2008 13:08:54 +0000 (UTC) (envelope-from iaccounts@ibctech.ca) Received: from pearl.ibctech.ca (pearl.ibctech.ca [208.70.104.210]) by mx1.freebsd.org (Postfix) with ESMTP id 17D498FC20 for ; Wed, 16 Apr 2008 13:08:53 +0000 (UTC) (envelope-from iaccounts@ibctech.ca) Received: (qmail 80646 invoked by uid 1002); 16 Apr 2008 12:42:12 -0000 Received: from iaccounts@ibctech.ca by pearl.ibctech.ca by uid 89 with qmail-scanner-1.22 (spamassassin: 2.64. Clear:RC:1(208.70.104.100):. Processed in 0.071541 secs); 16 Apr 2008 12:42:12 -0000 Received: from unknown (HELO ?192.168.30.110?) (steve@ibctech.ca@208.70.104.100) by pearl.ibctech.ca with (DHE-RSA-AES256-SHA encrypted) SMTP; 16 Apr 2008 12:42:11 -0000 Message-ID: <4805F428.8030103@ibctech.ca> Date: Wed, 16 Apr 2008 08:42:16 -0400 From: Steve Bertrand User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Edwin Sanjoto References: <59319.33967.qm@web52503.mail.re2.yahoo.com> In-Reply-To: <59319.33967.qm@web52503.mail.re2.yahoo.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: about DNS server 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 Apr 2008 13:08:54 -0000 Edwin Sanjoto wrote: > Hi Guyz, > > I want to gain access to the internet via IPv4 (with the public IP) as my Gateway and I am using pure IPv6 (not dual stack)... > > I just want to know how to make a DNS server in freeBSD so i can gain access to the internet via IPv4... I've never used the faith driver before, so I don't know how it works. Are you looking to have a DNS server that speaks IPv6 or IPv4? Will this DNS service reside on your local machine, or on another machine on the network? One more thing...do you need this to be an authoritative name server, or simply a caching name server? I'm in the process today of implementing an IPv6 only DNS server, so depending on what you are trying to achieve, I may be able to help either way. Regards, Steve From owner-freebsd-net@FreeBSD.ORG Wed Apr 16 14:13:12 2008 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 6B39A1065678 for ; Wed, 16 Apr 2008 14:13:12 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.freebsd.org (Postfix) with ESMTP id ECF5D8FC18 for ; Wed, 16 Apr 2008 14:13:11 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 16 Apr 2008 07:03:54 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m3GE3sEI019455; Wed, 16 Apr 2008 07:03:54 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m3GE3srT002244; Wed, 16 Apr 2008 14:03:54 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Apr 2008 07:03:53 -0700 Received: from rrs.local ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Apr 2008 07:03:53 -0700 Message-ID: <48060748.1090807@cisco.com> Date: Wed, 16 Apr 2008 10:03:52 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.12) Gecko/20080201 SeaMonkey/1.1.8 MIME-Version: 1.0 To: "Rahman, Md Sazzadur" References: <7059EA19D7837E44A3BA7DAB464944B37FDA715193@XMAIL5.sooner.net.ou.edu> In-Reply-To: <7059EA19D7837E44A3BA7DAB464944B37FDA715193@XMAIL5.sooner.net.ou.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Apr 2008 14:03:53.0687 (UTC) FILETIME=[B447BE70:01C89FCA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1703; t=1208354634; x=1209218634; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20A=20query=20regarding=20SCTP=20congesti on=20control |Sender:=20; bh=2Y8lG9BWQt0ZNvmE/V6yU6FT6taAvsLxNk0B3wXmE5M=; b=Z7nxZWhmFZbh30kN2xqty6jzVaAZwkC64rb5TjRwV0vYY3nABcdZ59Gq6C +qTMjOWEgtE6s3KiE4SqD243Pj2QxSFGXyF6ALGe6cWN/dZVOT1FNe8H5XqE /U4sgqrz7+; Authentication-Results: sj-dkim-4; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: "freebsd-net@freebsd.org" Subject: Re: A query regarding SCTP congestion control 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 Apr 2008 14:13:12 -0000 Rahman, Md Sazzadur wrote: > Hi, I would like to get the values of SCTP congestion control > algorithm variables (cwnd, ssthresh, flightsize and pba) from any > SCTP based application in runtime for research purpose. Does any API > exist in SCTP for that? Do I need to dig the SCTP code in kernel to > get the values? There is a socket option to get the cwnd. However, I think what you really want is some of the researchish tracing stuff that SCTP provides. You can actually get a real time trace of the cwnd/flight etc via the various logging functions. You basically must compile this as an option.. have to go look at the options.. And then you can either use ktrace (which I don't recommend since it turns on to much overhead in the kernel) or you can use SCTP_LOCAL_TRACE_BUF This will put it into a piece of memory only for SCTP and not turn on all the other ktrace points. After you enable the logging in your compile you must turn on the logging level.. SCTP_CWND_LOGGING_ENABLE woudl be my recommendation. It gives you a real time up/down growth of the cwnd/flight/rwnd I think I wrote a "how to" somewhere.. let me go look.. R > > I will appreciate any help in this regard. > > Best Regards, Md Sazzadur Rahman Graduate Student, School of Computer > Science, University of Oklahoma, Norman, Oklahoma, USA > > _______________________________________________ > 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" > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Wed Apr 16 14:26:29 2008 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 BF0F91065673 for ; Wed, 16 Apr 2008 14:26:29 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.freebsd.org (Postfix) with ESMTP id 725B38FC12 for ; Wed, 16 Apr 2008 14:26:29 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 16 Apr 2008 06:58:29 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m3GDwSc6007957; Wed, 16 Apr 2008 06:58:28 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3GDwRPm022498; Wed, 16 Apr 2008 13:58:28 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Apr 2008 06:58:02 -0700 Received: from rrs.local ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Apr 2008 06:58:01 -0700 Message-ID: <480605E8.7020805@cisco.com> Date: Wed, 16 Apr 2008 09:58:00 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.12) Gecko/20080201 SeaMonkey/1.1.8 MIME-Version: 1.0 To: vadim_nuclight@mail.ru References: <58141B67-8B7F-49FE-BC20-2A0B94A589A0@lurchi.franken.de> <645A930A-F67E-465E-8DBB-59FBA4C8593B@lurchi.franken.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Apr 2008 13:58:01.0892 (UTC) FILETIME=[E2981640:01C89FC9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11444; t=1208354308; x=1209218308; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20SCTP=20using=20questions=20(API=20etc.) |Sender:=20; bh=9gO6En6hpeNDhNrGh6qww7uhoKnnZ4HyFbTUO9Q00sA=; b=FSCd9P0RiYfl7lRl7dmPm2BDcQGJjoFvmhJDDuR97SoFXgZlbLNcxNYUE7 rnw9VXi5QQJthSQx0HpIguzM/shu6zXybSla7xm8i8W8/4pbnj3osI7GCcwu dlIZ1BYk9N; Authentication-Results: sj-dkim-4; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: freebsd-net@freebsd.org Subject: Re: SCTP using questions (API etc.) 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 Apr 2008 14:26:29 -0000 Vadim: Sorry I have not chimed in earlier.. I tend to "not look" often at some of my boxes :-) Glad Michael helped out here .. thanks Michael Vadim Goncharov wrote: > Hi Michael Tuexen! > > On Thu, 6 Mar 2008 09:34:13 +0100; Michael Tuexen wrote about 'Re: SCTP using questions (API etc.)': > >>>>> "substreams". SCTP can do it for me, it's wonderful, but in practice >>>>> there >>>>> are some questions. >>>>> >>>>> How long can be one particular SCTP message? Can I rely on the fact >>>>> that it >>>>> can be unbounded, e.g. I want to emulate a stream with transfer of >>>>> 6 Gig-sized file? >>>> Protocol wise there is no limitation of the message size. API wise, >>>> for >>>> this size of a message you need to use the explicit EOR mode to be >>>> able >>>> to pass this large message using multiple sequential send() calls. >>> And how should I determine from my/remote stack an optimal size for >>> message >>> parts when entire message is guaranteed to not fit into buffers/ >>> windows of >>> both peers? >> If the sendbuffer is too small for the message to fit, the send call >> will return -1 and errno being set to EMSGSIZE. Or you do it in the >> application >> by inspecting the sendbuffer size. You do not have to deal with the >> recv buffer >> of the peer. > > So this means I need no subscription to unsent messages and simply can try > to resend message in several steps without EOR, after getting EMSGSIZE ? So, if you have put your socket int EEOR mode, then you could send multiple sends down the socket (to the same stream) until you get back a EWOULDBLOCK. You would only get a EMSGSIZE if the value you are sending is larger than the entire size of the send socket buffer.. So lets say the send buffer for the socket is 100k You could do while(ok) { send(1k[index]); if(ret == -1) && error == EWOULDBLOCK) hit full buffer (100k is inqueue) go do wait or other thing resume send(1k[index] else index++; Either all of the buffer or none of the buffer will be sent. > >>>>> Can a message be of zero-length data (only headers) ? >>>> Empty user messages, i.e. a DATA chunk without payload is not >>>> allowed. >>>> An empty SCTP message, i.e. only the common header without any chunks >>>> is allowed and processed by FreeBSD when received, but ever send >>>> (well, >>>> I do not know a way to force the FreeBSD implementation to send it). >>> OK, understood. So I should include at least 1 byte of my own >>> headers into >>> data and do receive into *iov with at least to parts to ensure good >>> align >>> for non-header part? >> What header are you talking about? An application header or any SCTP >> header? >> You will never receive any SCTP header as part of a user message via >> a recv() call. SCTP will give you as much of a message that fits into >> the buffer you provide or it has, if the partial delivery API has been >> invoked. > > My applicaion-protocol header, of course. Does this mean also that I should > always enable partial delivery on receiving? Or what will happen if received > msg is too big and don't fir into my buffers? Well, you have no control over this per.se. You can get partial delivery events.. there is only one. the partial delivery was aborted.. you probably need this if you are going to do EEOR mode. Basically the kernel will start a partial delivery when 1/2 of the recv buffer is in use. Note there is a socket option to control this value, so you can change it if you like... > >>>>> What is the relation between SCTP streams in both directions? Can >>>>> streams >>>>> be opened and closed on-demand, like SSH port forwarding (yet again >>>>> multiplexing example) or they are preallocated at connection setup >>>>> all >>>>> together? What is the minimum number of streams application can rely >>>>> upon >>>>> (or it just one stream 0 in general case) ? >>>> If you restrict to protocols being in RFC status, there is no way of >>>> modifying the number of streams during the lifetime of an >>>> association. >>>> The number of streams in each direction is negotiated during the >>>> association setup. The streams in bother directions are completely >>>> independent. There is always at least one stream in each direction, >>>> which >>>> is stream 0. >>>> However, there is an extension (currently specified in an Internet >>>> Draft) >>>> which allows the addition of streams during the lifetime of an >>>> association. >>>> The ID is at least partially supported by the FreeBSD implementation. >>>> https://datatracker.ietf.org/drafts/draft-stewart-sctpstrrst/ >>> OK. Are there recommended defaults for various stacks about how many >>> streams they are creating by default / what maximum of them >>> application >>> can ever request? >> The maximum number to request is 2^16 - 1. It is controllable by the >> applications via socket options. Defaults in OSes are in the order of >> 10, 16, 32... > > Can I be sure that every OS can give me maximum number of streams if I > request it? The ceiling for the number of streams is actually a defined contnsatn in the BSD stack (and in most). For bsd its defined in sctp_constants.h and is #define MAX_SCTP_STREAMS 2048 I probably should make this a configurable item ... hmm.. Each stream outbound costs about 16 bytes. Each stream inbound costs about 16 bytes... Thus my desire to limit to some extent resources used.. I think most kernels do this as well. You of course can twiddle the define, and I think for 8.x I will see about making it an option. > >>>>> How can I put request to kernel for a connect, for example, and then >>>>> sleep >>>>> until connect will complete or event in some another descriptor will >>>>> occur? >>>> If you use the 1-to-1 style API, it should be similar to using TCP. >>>> Put the socket in non-blocking mode, enable notifications, >>>> call connect() and wait until the fd becomes readable. You should >>>> get an >>>> indication that that association has been established or could not >>>> start. >>> Yes, that's possible, as I see after reading draft-ietf-tsvwg- >>> sctpsocket. >>> But several more questions arise. What notifications do I really need >>> on 1-to-1 non-blocking socket API mode? What use is 'context' in this >>> 1-to-1 context and why after a failed send I must receive entire >>> failed >>> sent message (which can be very long) instead of just an error code? >> The context is something you provide in the send call and is given >> back to you. So you can use it to find some state/buffer/whatever again. > > It was unclear from draft whether context is one per SCTP association or per > send call. And what the hell are all that unsent messages, why I must > retrieve entire unsent message - can I fire-and-forget a 2M msg and receive > only context of it instead of all 2 megs? And on which condition such event > can ever occur - with TCP it's simple, I either do write() a number of bytes > successfully or receive an error from write() - be that EAGAIN for just > blocking of peer's recv() or connection termination error. What concept is > under unsent msgs? The idea is that you can see the message that did not get sent. And you can know if it was every sent .. i.e. put on the wire but unack'd or never put on the wire. We don't currently have a way to not get the entire message up (sorry no one ever asked for that)... The context is kept per message if I remember right.. Its copied from the sinfo_context field and then carried with the queued data until its acked and freed. I believe you can set a default context as well.. > >>> In usual FSM I can use kqueue()/kevent() with arbitrary void* to my >>> data, also telling me how many bytes I can read from or write to >>> the socket (RCVLOWAT etc.), as well as indicating error/EOF conditions >>> so I don't need to do additional syscalls. Is this working with SCTP? >> Haven't tried it... Sounds like it would make sense to make sure that >> it works. > > Oh, can you please check it?.. Would be good to support all features > described in kqueue(2). I rather doubt this works, since we don't use socket buffers.. pe.se. I will have to go take a look at it and will proabably need to add that to my TODO list. Michael just finished getting it to work INET only.. (no v6).. good work Michael :-D > >>> If I can't write to TCP socket (due to window shortage from peer), >>> I leave data in my own application buffers, but SCTP tells something >>> about unsent messages delivered later, looks somewhat weird, do I >>> really >>> need this? Also, all that msg*/cmsg* staff is too complex, and I see >>> there are simplier sctp_send()/sctp_sendx() interfaces, will they be >>> enough and really simplier for me?.. >> sctp_sendx() purpose is to use the multiple addresses provided during >> the implicit setup of the association. So I think you are not looking >> for > > Ok. > >> this. sctp_send() can be used to provide the stream id, payload protocol >> identifier and to on with using the CMSG stuff. So you might be looking >> for this function. > > With CMSG? May be you wanted to say 'without' ?.. Yep, The sctp_xxx send calls are true function calls so they do not have the intense overhead of the app encoding ancillary data and the kernel un-encoding it.. much better :-) > >>>>> How can I put each client to it's fd and then do a kqueue()/kevent() >>>>> on a >>>>> set of those fd's (and other items) ? It is very handy to have this >>>>> architecture as kevent() allows to store an arbitrary void* in it's >>>>> structure which I can later use to quickly dispatch events. >>>>> >>>>> And, of course, all this usual C10K-problem-solving-TCP-server >>>>> tricks I want >>>>> with basic SCTP SEQPACKET benefits: multiple streams and message >>>>> record >>>>> separation (I don't need other SCTP features currently). Where can I >>>>> find >>>>> answers to these questions, like it was with W.R.Stevens books for >>>>> TCP ?.. >>>> Have you looked at the third edition of 'Unix Network Programming'? >>>> Randall Stewart wrote a couple of sections covering SCTP... >>> Unfortunately, I have only 2nd edition currently available here, >>> though >>> heard about 3rd, yes. May be several months later... >> It is really worth buying if you are interested in SCTP socket >> programming... > > I know, but in my province it is currently unavailable for some months... > you know, Siberia, bears walking on the streets :) but it is not critical > for actual SCTP programming (TCP version will be debugged first), but I need > to take architectural decisions now. > > Also, are there some examples of real-world SCTP applications with source > code available? May be something is getting to integrate into our base > system?.. I could probably find some of my test code and send it to you.. I have a pretty intesensive test app that we use sctp_test_app that does about every socket option etc.. its not pretty..(it grew organically).. but it does cover lots of stuff.. R > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Wed Apr 16 16:58:20 2008 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 6E347106564A for ; Wed, 16 Apr 2008 16:58:20 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 2B7798FC18 for ; Wed, 16 Apr 2008 16:58:19 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by yw-out-2324.google.com with SMTP id 2so1414945ywt.13 for ; Wed, 16 Apr 2008 09:58:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=cbeNwuoe5GWVXOURQKZVNT8I/2XRz4LBqBuN304PsOI=; b=E875QjB6tWXW0+CeEWuohnlR2k5uTQZdEdbp13sIyIkmqMiv8VgKmJge9ZEtZGxXOfJIzyeQZUn40xMg6okUxzTf/L081eAwlh2lVo9042Kr4Sat5PQ8NuWUssZD9SZ4oTrn+8+zMMK5NSihLfMu/JZYlxFkxq8ds9vWhKzUhkU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=dPuiWP3r7NmJPEdcBFsmbijz4s8uuEsprBI4jbNMjpUCFcUH9ci/bFblTaHQTklN1VCvzFDxnkdrh9bMO/PDJEOmLz+i1TPtjX593Rc2GDSVaZ/X8qNxWi6V3BI+lf4s/slwAcPbXYvCEBpOteqmcFhFjgf2W3ElziP6jMYUW2o= Received: by 10.150.49.15 with SMTP id w15mr361375ybw.101.1208363359508; Wed, 16 Apr 2008 09:29:19 -0700 (PDT) Received: by 10.151.15.21 with HTTP; Wed, 16 Apr 2008 09:29:19 -0700 (PDT) Message-ID: <3c0b01820804160929i76cc04fdy975929e2a04c0368@mail.gmail.com> Date: Wed, 16 Apr 2008 12:29:19 -0400 From: "Alexander Sack" To: freebsd-drivers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: bge dropping packets 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: Wed, 16 Apr 2008 16:58:20 -0000 Hello: Sorry for cross posting but this seems to be both a driver and network/kernel issue so I figure I actually thought all lists seemed appropriate. I'm investigating an issue we are seeing with 6.1-RELEASE and the bge driver dropping packets sporadically at 100MBps speed. The machine is a 2-way Intel dual-core running 64-bit FreeBSD-6.1 Release with SMP/8GB RAM. I would post dmesg but currently I'm running a test and has a lot of instrumentation in it. Anyway, what I'm seeing with a SmartBit traffic generator connected to 4 bge cards (all BCOM_DEVICEID_BCM5704C) is sporadic packet drops as recorded by the firmware in its statistics structure (as pulled out by bge_tick()), i.e. this isn't malloc starvation of allocating mbuf clusters, etc. The firmware seems to just drop packets occasionally (depending on workload). Its get mainly aggravated when heavy disk I/O occurs from generating a network report which entails gzip'ing a very large dumpfile in /tmp and then anonymously ftping it via another interface (em). DEVICE_POLLING is being used: # sysctl -a | grep kern.polling kern.polling.idlepoll_sleeping: 1 kern.polling.stalled: 3 kern.polling.suspect: 1023 kern.polling.phase: 0 kern.polling.enable: 1 kern.polling.handlers: 6 kern.polling.residual_burst: 0 kern.polling.pending_polls: 0 kern.polling.lost_polls: 24436 kern.polling.short_ticks: 592 kern.polling.reg_frac: 20 kern.polling.user_frac: 50 kern.polling.idle_poll: 0 kern.polling.each_burst: 32 kern.polling.burst_max: 1000 kern.polling.burst: 1000 After looking at the driver for a bit, I believe the issue maybe from RX chain starvation which causes the firmware to drop packets when bge_rxeof() can not keep up. The driver uses a global locking scheme which may contribute to some of these robustness issues (this is a generalization on my part without hard facts so take it with a grain of salt, I just notice things like bge_tick() being called every cycle and competing with the ISR when it may not have too or may not have too for its entire duration, updating stats for example). My main question is currently the RX chain slots are set to a global define BGE_SSLOTS (if_bgedevreg.h) which is 256. Technically this card I believe can do up to 512 slots and the comment above said these are tunable yet not exposed via SYSCTL. Does anyone know why its not 512 by default? Is there any harm in setting it to 512 instead of 256? Why not make it tunable (512 as max)? I've increased the SSLOTS to 512 so there are more RX chain slots available (as I currently understand it, I don't have specs) and the kern.polling.each_burst to 150 (max) in an effort to try to keep the BGE driver in bge_rxeof() and to experiment a bit! This is the first exposure to this code so be gentle! :D! Has anyone seen this problem before with bge? Am I barking up the wrong tree with my initial investigation? Does anyone know if its even possible to achieve 100% packet capture with bge at its supported speeds (10/100/1000)? Thanks! -aps From owner-freebsd-net@FreeBSD.ORG Wed Apr 16 18:07:11 2008 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 3E1D9106566C; Wed, 16 Apr 2008 18:07:11 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: from parsely.rain.com (parsely.rain.com [199.26.172.196]) by mx1.freebsd.org (Postfix) with ESMTP id 9ABD98FC1D; Wed, 16 Apr 2008 18:07:10 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: from sopwith.solgatos.com (uucp@localhost) by parsely.rain.com (8.11.4/8.11.4) with UUCP id m3GHfDl56312; Wed, 16 Apr 2008 10:41:13 -0700 (PDT) (envelope-from freebsd@sopwith.solgatos.com) Received: from localhost by sopwith.solgatos.com (8.8.8/6.24) id RAA23071; Wed, 16 Apr 2008 17:32:50 GMT Message-Id: <200804161732.RAA23071@sopwith.solgatos.com> To: "Alexander Sack" In-reply-to: Your message of "Wed, 16 Apr 2008 12:29:19 EDT." <3c0b01820804160929i76cc04fdy975929e2a04c0368@mail.gmail.com> Date: Wed, 16 Apr 2008 10:32:50 +0100 From: Dieter Cc: freebsd-net@freebsd.org, freebsd-drivers@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: bge dropping packets 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: Wed, 16 Apr 2008 18:07:11 -0000 > I'm investigating an issue we are seeing with 6.1-RELEASE and the bge > driver dropping packets sporadically at 100MBps speed. > Its get mainly aggravated when heavy disk I/O occurs > Has anyone seen this problem before with bge? Am I barking up the > wrong tree with my initial investigation? Does anyone know if its > even possible to achieve 100% packet capture with bge at its supported > speeds (10/100/1000)? I had a similar problem with bge and 6.0-RELEASE. Bge works great for me in 6.2-RELEASE. So far 7.0-RELEASE looks good as well (bge-wise, I do have unresolved issues with 7). My app is TCP, cranking the TCP receive buffer way up helped, as did turning off Nagle. My bge is 1000, but connected at 100 since that is what the other end is. I saw problems at less than 20 Mbps. There is still a problem that other drivers can lock out bge for too long. For example kern/118093: firewire bus reset. From owner-freebsd-net@FreeBSD.ORG Wed Apr 16 18:20:35 2008 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 A46471065677 for ; Wed, 16 Apr 2008 18:20:35 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 4E10A8FC16 for ; Wed, 16 Apr 2008 18:20:35 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by yw-out-2324.google.com with SMTP id 2so1436585ywt.13 for ; Wed, 16 Apr 2008 11:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=gWce5972bEgiQU0Qe0OxMbA8rvfNAm3oVFyxzVaPFIs=; b=iAUmo1iSjg/sFIwharPCZkD4hVnlne4H5qYV9arouVxiFWL/Ohe/PWCgl/r+eshjoPzaaYoNRwsT1wgVJ1KCuRpbRmmWk0O7xpCYhx1AetU7DHoX9rUPqEjWjbY6IiJ+lTDrLNlIHXhLp0apTJzaDIs+qsUoPNf0AQH4d0BxJ54= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UKKeh78Hy0q3aWAULJgqcdI/fvsKtw/151AmO4oV/EvssU+tcxhdpLXZ9onS0Bu+fE/ByyRznmIsZP3w8YsQA3ewwLcsX8GDmE2OLwYy1Pi1k2lG0w2wX5Y2lvp0Mst4YnbKQdtYSIEU9/GTCWMIUqrKo+70CKn/89J5H9OcYuQ= Received: by 10.151.85.20 with SMTP id n20mr553514ybl.28.1208370027256; Wed, 16 Apr 2008 11:20:27 -0700 (PDT) Received: by 10.151.15.21 with HTTP; Wed, 16 Apr 2008 11:20:27 -0700 (PDT) Message-ID: <3c0b01820804161120udb54ab3tea4bf7baade0061f@mail.gmail.com> Date: Wed, 16 Apr 2008 14:20:27 -0400 From: "Alexander Sack" To: Dieter In-Reply-To: <200804161732.RAA23071@sopwith.solgatos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3c0b01820804160929i76cc04fdy975929e2a04c0368@mail.gmail.com> <200804161732.RAA23071@sopwith.solgatos.com> Cc: freebsd-net@freebsd.org, freebsd-drivers@freebsd.org, Jung-uk Kim , freebsd-hackers@freebsd.org Subject: Re: bge dropping packets 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: Wed, 16 Apr 2008 18:20:35 -0000 Dieter: Thanks, at 20Mbps! That's pretty aweful. JK: Thanks again. Wow, I searched the list and didn't see much discussion with respect to bge and packet loss! I will try the rest of that patch including pushing the TCP receive buffer up (though I don't think that's going to help in this case). The above is based on just looking at code.... I guess some follow-up questions would be: 1) Why isn't BGE_SSLOTS tunable (to a point)? Why can't that be added the driver? I noticed that CURRENT has added a lot more SYSCTL information. Moreover it seems the Linux driver can set it up to 1024. 2) bge_tick() uses the same global mutex for its callout as the rest of the driver. Moreover, it really doesn't have to hold it while updating statistics, they are reads of volatile registers anyway (blocking the ISR doesn't prevent the firmware from updating its stat struct). Would there be any interest in using a separate mutex for the callout itself and then just hold the lock for the other small calls (bge_asf_driver_up(), bge_watchdog())? I'm experimenting with right now just dropping the BGE mutex around the bge_stats_update() calls to give more time to bge_rxeof() to drain rx_bd's. I admit that bge_tick doesn't do a whole lot but it seems this driver is very sensitive to resource starvation and I'm trying to get the BGE driver to drain as much rx_bd's as possible to avoid drops due to the firmware having no place to put them! 3) How does interrupt non-DEVICE_POLLING perform? Thanks guys! -aps On Wed, Apr 16, 2008 at 5:32 AM, Dieter wrote: > > I'm investigating an issue we are seeing with 6.1-RELEASE and the bge > > driver dropping packets sporadically at 100MBps speed. > > > > Its get mainly aggravated when heavy disk I/O occurs > > > > Has anyone seen this problem before with bge? Am I barking up the > > wrong tree with my initial investigation? Does anyone know if its > > even possible to achieve 100% packet capture with bge at its supported > > speeds (10/100/1000)? > > I had a similar problem with bge and 6.0-RELEASE. Bge works great for > me in 6.2-RELEASE. So far 7.0-RELEASE looks good as well (bge-wise, > I do have unresolved issues with 7). > > My app is TCP, cranking the TCP receive buffer way up helped, as did > turning off Nagle. > > My bge is 1000, but connected at 100 since that is what the other end is. > I saw problems at less than 20 Mbps. > > There is still a problem that other drivers can lock out bge for too long. > For example kern/118093: firewire bus reset. > From owner-freebsd-net@FreeBSD.ORG Wed Apr 16 18:56:28 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 68782106566B; Wed, 16 Apr 2008 18:56:28 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: "Alexander Sack" Date: Wed, 16 Apr 2008 14:56:18 -0400 User-Agent: KMail/1.6.2 References: <3c0b01820804160929i76cc04fdy975929e2a04c0368@mail.gmail.com> <200804161732.RAA23071@sopwith.solgatos.com> <3c0b01820804161120udb54ab3tea4bf7baade0061f@mail.gmail.com> In-Reply-To: <3c0b01820804161120udb54ab3tea4bf7baade0061f@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200804161456.20823.jkim@FreeBSD.org> Cc: freebsd-net@FreeBSD.org, Dieter Subject: Re: bge dropping packets 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: Wed, 16 Apr 2008 18:56:28 -0000 [CC trimmed] On Wednesday 16 April 2008 02:20 pm, Alexander Sack wrote: > Dieter: Thanks, at 20Mbps! That's pretty aweful. > > JK: Thanks again. Wow, I searched the list and didn't see much > discussion with respect to bge and packet loss! I will try the > rest of that patch including pushing the TCP receive buffer up > (though I don't think that's going to help in this case). The > above is based on just looking at code.... > > I guess some follow-up questions would be: > > 1) Why isn't BGE_SSLOTS tunable (to a point)? Why can't that be > added the driver? I noticed that CURRENT has added a lot more > SYSCTL information. Moreover it seems the Linux driver can set it > up to 1024. IIRC, Linux tg3 uses one ring for both standard and jumbo. > 2) bge_tick() uses the same global mutex for its callout as the > rest of the driver. Moreover, it really doesn't have to hold it > while updating statistics, they are reads of volatile registers > anyway (blocking the ISR doesn't prevent the firmware from updating > its stat struct). Would there be any interest in using a separate > mutex for the callout itself and then just hold the lock for the > other small calls (bge_asf_driver_up(), bge_watchdog())? I'm > experimenting with right now just dropping the BGE mutex around the > bge_stats_update() calls to give more time to bge_rxeof() to drain > rx_bd's. I admit that bge_tick doesn't do a whole lot but it seems > this driver is very sensitive to resource starvation and I'm trying > to get the BGE driver to drain as much rx_bd's as possible to avoid > drops due to the firmware having no place to put them! > > 3) How does interrupt non-DEVICE_POLLING perform? If you just use default values, it won't perform very well. There are some patches around the net to automatically adjust these numbers, e.g., http://docs.freebsd.org/cgi/mid.cgi?20071117194615.L67319 http://mail-index.netbsd.org/tech-kern/2004/03/16/0000.html Jung-uk Kim > Thanks guys! > > -aps > > On Wed, Apr 16, 2008 at 5:32 AM, Dieter wrote: > > > I'm investigating an issue we are seeing with 6.1-RELEASE and > > > the bge > > > > > > driver dropping packets sporadically at 100MBps speed. > > > > > > Its get mainly aggravated when heavy disk I/O occurs > > > > > > > > > Has anyone seen this problem before with bge? Am I barking up > > > the > > > > > > wrong tree with my initial investigation? Does anyone know if > > > its even possible to achieve 100% packet capture with bge at > > > its supported speeds (10/100/1000)? > > > > I had a similar problem with bge and 6.0-RELEASE. Bge works > > great for me in 6.2-RELEASE. So far 7.0-RELEASE looks good as > > well (bge-wise, I do have unresolved issues with 7). > > > > My app is TCP, cranking the TCP receive buffer way up helped, as > > did turning off Nagle. > > > > My bge is 1000, but connected at 100 since that is what the > > other end is. I saw problems at less than 20 Mbps. > > > > There is still a problem that other drivers can lock out bge for > > too long. For example kern/118093: firewire bus reset. From owner-freebsd-net@FreeBSD.ORG Wed Apr 16 19:08:35 2008 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 B6E121065673 for ; Wed, 16 Apr 2008 19:08:35 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id 90B848FC1C for ; Wed, 16 Apr 2008 19:08:35 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1436501rvf.43 for ; Wed, 16 Apr 2008 12:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=3auZE6egHMzl9Z9IOKVm+q5SXaqpBEI2FoOWLPlg+Xc=; b=lW+suftq3h1ml0SxYfmIUyfpoOyq59V+qP4+ftV6mmpU7EkjcJ9FkLjDJ08MJSuzDjI487nuA2zcykpvQykDvSlZQaYlshgY+XeeftEYPWM3VXpTPstRRmx54DxSJEG9aOOAm1Au/Yfud+zrI/aD1z99Ap43L5lPY2NoOfTvqp4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=q6MMdcKvJ5+NVoZcSb9F1+aU8oPakUZ1GNhFeIQ+/IoaOVlVhshZOoIvBRpyP03GYGcWjNCQjqhntuxI5HGvLvjLuM7P1UO6TYNXSaxFgeeJIZhz8FeymmqspFdrtUIDi4q9mt89SxTWdptZjfl3EV2KYbXfDFlzW43p5PA44ZA= Received: by 10.141.136.19 with SMTP id o19mr187769rvn.250.1208371469486; Wed, 16 Apr 2008 11:44:29 -0700 (PDT) Received: by 10.140.135.3 with HTTP; Wed, 16 Apr 2008 11:44:29 -0700 (PDT) Message-ID: <9a542da30804161144s3f90b9daq44966f5a449273bb@mail.gmail.com> Date: Wed, 16 Apr 2008 14:44:29 -0400 From: "=?ISO-8859-1?Q?Ermal_Lu=E7i?=" To: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: [patch] ng_iface(4) and ports/net/mpd4 allow renaming of interfaces. 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 Apr 2008 19:08:35 -0000 Hello, the patches inlined give the ng_iface(4) and the mpd4 port the ability to rename its interfaces. IE if you create a new pppoe connection instead of the line new -i ng0 pppoe pppoe you can enter new -i pppoe0 pppoe pppoe so when mpd starts it will create an ngX interface with a ngX: hook after that it will rename ngX to pppoe0 and the corresponding hook to pppoe0: The ng_iface(4) patch adds a new message NGM_IFACE_SET_IFNAME: usable through ngctl msg $path: setifname $name it is just a copy of the ioctl in if.c SIFNAME without the routing adevertising cause mostly you will do renaming before bringing the interface up. Alghotu you are not allowed to rename it after the interface is up. I wonder if it can be polished and integrated in future versions of FreeBSD?! If it is needed to patch even mpd5 i will do even that. Regards, Ermal --- src/ngfunc.c.orig 2008-04-16 13:29:08.000000000 -0400 +++ src/ngfunc.c 2008-04-16 13:29:16.000000000 -0400 @@ -249,6 +249,7 @@ struct ng_mesg reply; } u; char path[NG_PATHLEN + 1]; +#if 0 char *eptr; int ifnum; @@ -258,9 +259,10 @@ ifnum = (int)strtoul(ifname + strlen(NG_IFACE_IFACE_NAME), &eptr, 10); if (ifnum < 0 || *eptr != '\0') return(-1); +#endif /* See if interface exists */ - snprintf(path, sizeof(path), "%s%d:", NG_IFACE_IFACE_NAME, ifnum); + snprintf(path, sizeof(path), "%s:", ifname); if (NgSendMsg(b->csock, path, NGM_GENERIC_COOKIE, NGM_NODEINFO, NULL, 0) < 0) return(0); if (NgRecvMsg(b->csock, &u.reply, sizeof(u), NULL) < 0) { @@ -270,7 +272,7 @@ /* It exists */ if (buf != NULL) - snprintf(buf, max, "%s%d", NG_IFACE_IFACE_NAME, ifnum); + snprintf(buf, max, "%s", ifname); return(1); } @@ -294,30 +296,10 @@ struct nodeinfo *const ni = (struct nodeinfo *)(void *)u.reply.data; struct ngm_rmhook rm; struct ngm_mkpeer mp; + struct ngm_name nm; + char path[NG_PATHLEN + 1]; int rtn = 0; - /* If ifname is not null, create interfaces until it gets created */ - if (ifname != NULL) { - int count; - - for (count = 0; count < MAX_IFACE_CREATE; count++) { - switch (NgFuncIfaceExists(b, ifname, buf, max)) { - case 1: /* ok now it exists */ - return(0); - case 0: /* nope, create another one */ - NgFuncCreateIface(b, NULL, NULL, 0); - break; - case -1: /* something weird happened */ - return(-1); - default: - assert(0); - } - } - Log(LG_ERR, ("[%s] created %d interfaces, that's too many!", - b->name, count)); - return(-1); - } - /* Create iface node (as a temporary peer of the socket node) */ snprintf(mp.type, sizeof(mp.type), "%s", NG_IFACE_NODE_TYPE); snprintf(mp.ourhook, sizeof(mp.ourhook), "%s", TEMPHOOK); @@ -328,7 +310,6 @@ b->name, NG_IFACE_NODE_TYPE, ".", mp.ourhook, strerror(errno))); return(-1); } - /* Get the new node's name */ if (NgSendMsg(b->csock, TEMPHOOK, NGM_GENERIC_COOKIE, NGM_NODEINFO, NULL, 0) < 0) { @@ -342,6 +323,28 @@ rtn = -1; goto done; } + +if (ifname != NULL) { + /* Set the new node's name */ + bzero(path, sizeof(path)); + snprintf(path, sizeof(path), "%s:", ni->name); +snprintf(nm.name, sizeof(nm.name), "%s", ifname); + if (NgSendMsg(b->csock, path, + NGM_IFACE_COOKIE, NGM_IFACE_SET_IFNAME, nm.name, sizeof(nm.name)) < 0) { + Log(LG_ERR, ("[%s] %s: %s", b->name, "NGM_NODEINFO", strerror(errno))); + rtn = -1; + goto done; + } + + /* Set the new node's name */ + if (NgSendMsg(b->csock, path, + NGM_GENERIC_COOKIE, NGM_NAME, &nm, sizeof(nm)) < 0) { + Log(LG_ERR, ("[%s] %s: %s", b->name, "NGM_NODEINFO", strerror(errno))); + rtn = -1; + goto done; + } + snprintf(buf, max, "%s", ifname); +} else snprintf(buf, max, "%s", ni->name); done: @@ -355,7 +358,7 @@ } /* Done */ - return(rtn); + return (rtn); } /* Index: ng_iface.c =================================================================== RCS file: /home/ncvs/src/sys/netgraph/ng_iface.c,v retrieving revision 1.47 diff -u -r1.47 ng_iface.c --- ng_iface.c 2 Jun 2006 23:14:40 -0000 1.47 +++ ng_iface.c 16 Apr 2008 17:03:47 -0000 @@ -69,9 +69,11 @@ #include #include #include +#include #include #include +#include #include #include @@ -163,6 +165,13 @@ }, { NGM_IFACE_COOKIE, + NGM_IFACE_SET_IFNAME, + "setifname", + &ng_parse_string_type, + NULL + }, + { + NGM_IFACE_COOKIE, NGM_IFACE_POINT2POINT, "point2point", NULL, @@ -587,6 +596,10 @@ struct ng_mesg *resp = NULL; int error = 0; struct ng_mesg *msg; + char *new_name; + size_t namelen, onamelen; + struct sockaddr_dl *sdl = NULL; + struct ifaddr *ifa = NULL; NGI_GET_MSG(item, msg); switch (msg->header.typecookie) { @@ -601,6 +614,49 @@ strlcpy(resp->data, ifp->if_xname, IFNAMSIZ); break; + case NGM_IFACE_SET_IFNAME: + + new_name = (char *)msg->data; + /* Announce the departure of the interface. */ + //new_name[strlen(new_name)] = '\0'; + + /* Deny request if interface is UP */ + if ((ifp->if_flags & IFF_UP) != 0) { + error = EBUSY; + break; + } + + //rt_ifannouncemsg(ifp, IFAN_DEPARTURE); + EVENTHANDLER_INVOKE(ifnet_departure_event, ifp); + + strlcpy(ifp->if_xname, new_name, sizeof(ifp->if_xname)); + ifa = ifp->if_addr; + IFA_LOCK(ifa); + sdl = (struct sockaddr_dl *)ifa->ifa_addr; + namelen = strlen(new_name) + 1; + onamelen = sdl->sdl_nlen; + /* + * Move the address if needed. This is safe because we + * allocate space for a name of length IFNAMSIZ when we + * create this in if_attach(). + */ + if (namelen != onamelen) { + bcopy(sdl->sdl_data + onamelen, + sdl->sdl_data + namelen, sdl->sdl_alen); + } + bcopy(new_name, sdl->sdl_data, namelen); + sdl->sdl_nlen = namelen; + sdl = (struct sockaddr_dl *)ifa->ifa_netmask; + bzero(sdl->sdl_data, onamelen); + while (namelen != 0) + sdl->sdl_data[--namelen] = 0xff; + IFA_UNLOCK(ifa); + + EVENTHANDLER_INVOKE(ifnet_arrival_event, ifp); + /* Announce the return of the interface. */ + //rt_ifannouncemsg(ifp, IFAN_ARRIVAL); + break; + case NGM_IFACE_POINT2POINT: case NGM_IFACE_BROADCAST: { Index: ng_iface.h =================================================================== RCS file: /home/ncvs/src/sys/netgraph/ng_iface.h,v retrieving revision 1.9 diff -u -r1.9 ng_iface.h --- ng_iface.h 13 Feb 2005 16:36:41 -0000 1.9 +++ ng_iface.h 16 Apr 2008 17:03:48 -0000 @@ -70,6 +70,7 @@ NGM_IFACE_POINT2POINT, NGM_IFACE_BROADCAST, NGM_IFACE_GET_IFINDEX, + NGM_IFACE_SET_IFNAME, }; #endif /* _NETGRAPH_NG_IFACE_H_ */ From owner-freebsd-net@FreeBSD.ORG Wed Apr 16 20:28:57 2008 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 724261065670 for ; Wed, 16 Apr 2008 20:28:57 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id 2433B8FC20 for ; Wed, 16 Apr 2008 20:28:56 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by yw-out-2324.google.com with SMTP id 2so1469933ywt.13 for ; Wed, 16 Apr 2008 13:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Z+kIlDQp9tvFwmNbjAFvjddunSM3Uo71Lp238hKe7tc=; b=xeqT2uzmlSNdG1E9ZK5gYvbDPQrhsnnUGRRG9TsT3OlrSyH+dzW9lAn6EnKRsYMY/YJ5SpilDJ0xUPJCNSy8zJFocUFSX8jeMGzKs8eyQEb8ergnTMYERfFoTsrTmzZHCy0H+DfF9iVuc/x1N3hCqUWzYtxV2xovb47MMIshku0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LYKcY0pM1HFHRwxoEBTRW3ufpBuqiS1jV3cHNd/O3QCr2f25GtDFqFp23Pv9S1Xo4ESZWAxS0IQvO8BIwDdUfMAxd8hPIZ01U5IM9+Exf452/KMupa+iS48NSd5+XlWLzVp1sCe2y9+qfZh0OUj7WOW7E8codpsTujb9gK4VYaY= Received: by 10.151.43.19 with SMTP id v19mr678488ybj.195.1208377719528; Wed, 16 Apr 2008 13:28:39 -0700 (PDT) Received: by 10.151.15.21 with HTTP; Wed, 16 Apr 2008 13:28:39 -0700 (PDT) Message-ID: <3c0b01820804161328m77704ca0g43077a9718d446d4@mail.gmail.com> Date: Wed, 16 Apr 2008 16:28:39 -0400 From: "Alexander Sack" To: "Jung-uk Kim" In-Reply-To: <200804161456.20823.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3c0b01820804160929i76cc04fdy975929e2a04c0368@mail.gmail.com> <200804161732.RAA23071@sopwith.solgatos.com> <3c0b01820804161120udb54ab3tea4bf7baade0061f@mail.gmail.com> <200804161456.20823.jkim@FreeBSD.org> Cc: freebsd-net@freebsd.org, Dieter Subject: Re: bge dropping packets 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: Wed, 16 Apr 2008 20:28:57 -0000 On Wed, Apr 16, 2008 at 2:56 PM, Jung-uk Kim wrote: > [CC trimmed] > > > On Wednesday 16 April 2008 02:20 pm, Alexander Sack wrote: > > Dieter: Thanks, at 20Mbps! That's pretty aweful. > > > > JK: Thanks again. Wow, I searched the list and didn't see much > > discussion with respect to bge and packet loss! I will try the > > rest of that patch including pushing the TCP receive buffer up > > (though I don't think that's going to help in this case). The > > above is based on just looking at code.... > > > > I guess some follow-up questions would be: > > > > 1) Why isn't BGE_SSLOTS tunable (to a point)? Why can't that be > > added the driver? I noticed that CURRENT has added a lot more > > SYSCTL information. Moreover it seems the Linux driver can set it > > up to 1024. > > IIRC, Linux tg3 uses one ring for both standard and jumbo. I'm talking about the number of slots within the ring not the number of RX queues. I believe the bnx4 driver (thought the tg stuff was deprecated??) uses 4 rings (one for each port perhaps) and reads hardware register at ISR time to flip between them. The BGE_SLLOTS define I think could be a tunable which would allow someone to tune the driver to use more or less RX slots. I still feel that is a good idea instead of forcing someone to recompile! :(! > > 2) bge_tick() uses the same global mutex for its callout as the > > rest of the driver. Moreover, it really doesn't have to hold it > > while updating statistics, they are reads of volatile registers > > anyway (blocking the ISR doesn't prevent the firmware from updating > > its stat struct). Would there be any interest in using a separate > > mutex for the callout itself and then just hold the lock for the > > other small calls (bge_asf_driver_up(), bge_watchdog())? I'm > > experimenting with right now just dropping the BGE mutex around the > > bge_stats_update() calls to give more time to bge_rxeof() to drain > > rx_bd's. I admit that bge_tick doesn't do a whole lot but it seems > > this driver is very sensitive to resource starvation and I'm trying > > to get the BGE driver to drain as much rx_bd's as possible to avoid > > drops due to the firmware having no place to put them! I'd like to experiment some more with this to see if I can get 100MBps 100% non-dropping (may not be possible with small changes but it'll be a character building experience none the less). > > 3) How does interrupt non-DEVICE_POLLING perform? > > If you just use default values, it won't perform very well. There are > some patches around the net to automatically adjust these numbers, > e.g., > > http://docs.freebsd.org/cgi/mid.cgi?20071117194615.L67319 > http://mail-index.netbsd.org/tech-kern/2004/03/16/0000.html Thanks will take a look! This really sucks... :D! -aps From owner-freebsd-net@FreeBSD.ORG Wed Apr 16 20:54:30 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 817B01065676; Wed, 16 Apr 2008 20:54:30 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-net@FreeBSD.org Date: Wed, 16 Apr 2008 16:54:20 -0400 User-Agent: KMail/1.6.2 References: <3c0b01820804160929i76cc04fdy975929e2a04c0368@mail.gmail.com> <200804161456.20823.jkim@FreeBSD.org> <3c0b01820804161328m77704ca0g43077a9718d446d4@mail.gmail.com> In-Reply-To: <3c0b01820804161328m77704ca0g43077a9718d446d4@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200804161654.22452.jkim@FreeBSD.org> Cc: Alexander Sack , Dieter Subject: Re: bge dropping packets 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: Wed, 16 Apr 2008 20:54:30 -0000 On Wednesday 16 April 2008 04:28 pm, Alexander Sack wrote: > On Wed, Apr 16, 2008 at 2:56 PM, Jung-uk Kim wrote: > > [CC trimmed] > > > > On Wednesday 16 April 2008 02:20 pm, Alexander Sack wrote: > > > Dieter: Thanks, at 20Mbps! That's pretty aweful. > > > > > > JK: Thanks again. Wow, I searched the list and didn't see > > > much discussion with respect to bge and packet loss! I will > > > try the rest of that patch including pushing the TCP receive > > > buffer up (though I don't think that's going to help in this > > > case). The above is based on just looking at code.... > > > > > > I guess some follow-up questions would be: > > > > > > 1) Why isn't BGE_SSLOTS tunable (to a point)? Why can't that > > > be added the driver? I noticed that CURRENT has added a lot > > > more SYSCTL information. Moreover it seems the Linux driver > > > can set it up to 1024. > > > > IIRC, Linux tg3 uses one ring for both standard and jumbo. > > I'm talking about the number of slots within the ring not the > number of RX queues. > > I believe the bnx4 driver (thought the tg stuff was deprecated??) > uses 4 rings (one for each port perhaps) and reads hardware > register at ISR time to flip between them. I guess you are reading wrong source, i.e., bnx4(?) is NetXtreme II driver, which totally different family. We support them with bce(4). tg3 is still official Linux driver. Jung-uk Kim From owner-freebsd-net@FreeBSD.ORG Wed Apr 16 21:02:51 2008 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 204381065672 for ; Wed, 16 Apr 2008 21:02:51 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id C50328FC1C for ; Wed, 16 Apr 2008 21:02:50 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by yw-out-2324.google.com with SMTP id 2so1478664ywt.13 for ; Wed, 16 Apr 2008 14:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=lhVYVm/nOf67r1ycOYqufFvL7lLRXK5Mn4GnJ2BZqUU=; b=DVLlLcgOzknaEnQKPpTqjCgxEeJYvLokeweM6jUy3lqRhiYBIBzMEsqn3PcndE6BzzD4PbHCa/nez0QPQWz+xDfAoB7Xevd0mtJgec5YBSY22i5wTGT072JfpPMoAH5A1I0UHe6WUEGQ+JeG93GxQy+1GS5GYR8V3AnVt89Cae8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=H3zT6RpB0XkcgFsywoOz/WCTIsb6J1QE/AW1t6M95vNrv7rnwjwOZPGgQ8GwsfhaSP8I1P5rqepYeTanEcpCwJTijoDF4gZyWVM4XIB6C/nNFWvHxf9HOpbqX8wIOcigPvTKL4HtvWxprR2l7H8rcgAfLkOEKtcqEAXZuJsSttQ= Received: by 10.151.114.9 with SMTP id r9mr714069ybm.238.1208379761398; Wed, 16 Apr 2008 14:02:41 -0700 (PDT) Received: by 10.151.15.21 with HTTP; Wed, 16 Apr 2008 14:02:41 -0700 (PDT) Message-ID: <3c0b01820804161402u3aac4425n41172294ad33a667@mail.gmail.com> Date: Wed, 16 Apr 2008 17:02:41 -0400 From: "Alexander Sack" To: "Jung-uk Kim" In-Reply-To: <200804161654.22452.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3c0b01820804160929i76cc04fdy975929e2a04c0368@mail.gmail.com> <200804161456.20823.jkim@FreeBSD.org> <3c0b01820804161328m77704ca0g43077a9718d446d4@mail.gmail.com> <200804161654.22452.jkim@FreeBSD.org> Cc: freebsd-net@freebsd.org, Dieter Subject: Re: bge dropping packets 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: Wed, 16 Apr 2008 21:02:51 -0000 On Wed, Apr 16, 2008 at 4:54 PM, Jung-uk Kim wrote: > On Wednesday 16 April 2008 04:28 pm, Alexander Sack wrote: > > On Wed, Apr 16, 2008 at 2:56 PM, Jung-uk Kim > wrote: > > > [CC trimmed] > > > > > > On Wednesday 16 April 2008 02:20 pm, Alexander Sack wrote: > > > > Dieter: Thanks, at 20Mbps! That's pretty aweful. > > > > > > > > JK: Thanks again. Wow, I searched the list and didn't see > > > > much discussion with respect to bge and packet loss! I will > > > > try the rest of that patch including pushing the TCP receive > > > > buffer up (though I don't think that's going to help in this > > > > case). The above is based on just looking at code.... > > > > > > > > I guess some follow-up questions would be: > > > > > > > > 1) Why isn't BGE_SSLOTS tunable (to a point)? Why can't that > > > > be added the driver? I noticed that CURRENT has added a lot > > > > more SYSCTL information. Moreover it seems the Linux driver > > > > can set it up to 1024. > > > > > > IIRC, Linux tg3 uses one ring for both standard and jumbo. > > > > I'm talking about the number of slots within the ring not the > > number of RX queues. > > > > I believe the bnx4 driver (thought the tg stuff was deprecated??) > > uses 4 rings (one for each port perhaps) and reads hardware > > register at ISR time to flip between them. > > I guess you are reading wrong source, i.e., bnx4(?) is NetXtreme II > driver, which totally different family. We support them with bce(4). > tg3 is still official Linux driver. You are correct, I got the names confused (this problem really stinks)! However, my point still stands: #define TG3_RX_RCB_RING_SIZE(tp) ((tp->tg3_flags2 & TG3_FLG2_5705_PLUS) ? 512 : 1024) Even the Linux driver uses higher number of RX descriptors than FreeBSD's static 256. I think minimally making this tunable is a fair approach. If not, no biggie, but I think its worth it. -aps From owner-freebsd-net@FreeBSD.ORG Wed Apr 16 21:24:29 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 13BFF1065678; Wed, 16 Apr 2008 21:24:29 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: "Alexander Sack" Date: Wed, 16 Apr 2008 17:24:11 -0400 User-Agent: KMail/1.6.2 References: <3c0b01820804160929i76cc04fdy975929e2a04c0368@mail.gmail.com> <200804161654.22452.jkim@FreeBSD.org> <3c0b01820804161402u3aac4425n41172294ad33a667@mail.gmail.com> In-Reply-To: <3c0b01820804161402u3aac4425n41172294ad33a667@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200804161724.21507.jkim@FreeBSD.org> Cc: freebsd-net@freebsd.org, Dieter Subject: Re: bge dropping packets 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: Wed, 16 Apr 2008 21:24:30 -0000 On Wednesday 16 April 2008 05:02 pm, Alexander Sack wrote: > On Wed, Apr 16, 2008 at 4:54 PM, Jung-uk Kim wrote: > > On Wednesday 16 April 2008 04:28 pm, Alexander Sack wrote: > > > On Wed, Apr 16, 2008 at 2:56 PM, Jung-uk Kim > > > > > > > wrote: > > > > [CC trimmed] > > > > > > > > On Wednesday 16 April 2008 02:20 pm, Alexander Sack wrote: > > > > > Dieter: Thanks, at 20Mbps! That's pretty aweful. > > > > > > > > > > JK: Thanks again. Wow, I searched the list and didn't > > > > > see much discussion with respect to bge and packet loss! > > > > > I will try the rest of that patch including pushing the > > > > > TCP receive buffer up (though I don't think that's going > > > > > to help in this case). The above is based on just > > > > > looking at code.... > > > > > > > > > > I guess some follow-up questions would be: > > > > > > > > > > 1) Why isn't BGE_SSLOTS tunable (to a point)? Why can't > > > > > that be added the driver? I noticed that CURRENT has > > > > > added a lot more SYSCTL information. Moreover it seems > > > > > the Linux driver can set it up to 1024. > > > > > > > > IIRC, Linux tg3 uses one ring for both standard and jumbo. > > > > > > I'm talking about the number of slots within the ring not the > > > number of RX queues. > > > > > > I believe the bnx4 driver (thought the tg stuff was > > > deprecated??) uses 4 rings (one for each port perhaps) and > > > reads hardware register at ISR time to flip between them. > > > > I guess you are reading wrong source, i.e., bnx4(?) is NetXtreme > > II driver, which totally different family. We support them with > > bce(4). tg3 is still official Linux driver. > > You are correct, I got the names confused (this problem really > stinks)! > > However, my point still stands: > > #define TG3_RX_RCB_RING_SIZE(tp) ((tp->tg3_flags2 & > TG3_FLG2_5705_PLUS) ? 512 : 1024) > > Even the Linux driver uses higher number of RX descriptors than > FreeBSD's static 256. I think minimally making this tunable is a > fair approach. AFAIK, BCM5705+ does not support jumbo frames and it has one bigger receive ring. > If not, no biggie, but I think its worth it. I think 512 is okay for modern hardware but I have no hard feeling about adding a tunable. Jung-uk Kim From owner-freebsd-net@FreeBSD.ORG Wed Apr 16 22:08:42 2008 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 43CEB106567A for ; Wed, 16 Apr 2008 22:08:42 +0000 (UTC) (envelope-from agile.quad@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 019838FC23 for ; Wed, 16 Apr 2008 22:08:22 +0000 (UTC) (envelope-from agile.quad@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so2846223fgg.35 for ; Wed, 16 Apr 2008 15:08:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:x-mailer:reply-to:x-priority:message-id:to:subject:mime-version:content-type; bh=dXS5w6Xi5Nv75dTF9GHKP/z31lf46gf4s+XRDFe53gk=; b=oZOHqXceVX92s6xzkb9vxtkVNON/hin+bv6M9HWA3iY3KGbwOTnMWAhsjVxdPjShh37CC6UDMoLi6HRAfaYUqz5n+FOyTMyDo+n+rN1V9z+MJi/S0MMOQXHpE7S64op3IKo9bF1JRkxdDyHEkH7dthxC/AM/bnv/EVomUvupwfQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:x-mailer:reply-to:x-priority:message-id:to:subject:mime-version:content-type; b=ZDIp0zppQcQ3Yh+w8MpMXDducOUkbYL6lyGNCVUZ7dOifDtmILcao2Rvl0vCmm7lPCGtNkVjXLcHDs2++3RnH2g/D2f42e8yWmWuoNId36IFnkGz+Foy7aDvXt3K71smIOkr49rIbQ4moqTjVibb+uXGrS/S3bpjfkXo6p3SKxk= Received: by 10.86.50.8 with SMTP id x8mr1015846fgx.30.1208382237158; Wed, 16 Apr 2008 14:43:57 -0700 (PDT) Received: from AEONXP ( [87.238.159.51]) by mx.google.com with ESMTPS id o11sm15226400fkf.9.2008.04.16.14.43.54 (version=SSLv3 cipher=OTHER); Wed, 16 Apr 2008 14:43:56 -0700 (PDT) Date: Thu, 17 Apr 2008 00:43:53 +0300 From: quad X-Mailer: The Bat! (v3.60.07) Professional X-Priority: 3 (Normal) Message-ID: <1733112647.20080417004353@gmail.com> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------108F5841BDFF1DB" Subject: [bfe] [panic] Serious error: bfe failed to map RX buffer X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: quad List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2008 22:08:42 -0000 ------------108F5841BDFF1DB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, FreeBSD amd64 7.0-RELEASE, ULE, SMP. On heavy loads bfe network driver after few messages Serious error: bfe failed to map RX buffer Serious error: bfe failed to map RX buffer Serious error: bfe failed to map RX buffer ... make kernel panic. Here patch. -- Best regards, Oleg Dolgov mailto:agile.quad@gmail.com ------------108F5841BDFF1DB Content-Type: application/octet-stream; name="if_bfe.diff" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="if_bfe.diff" LS0tIGlmX2JmZV9vcmlnLmMJMjAwOC0wNC0xNyAwMDoyNjo0My41NTkzNzUwMDAgKzAzMDAN CisrKyBpZl9iZmUuYwkyMDA4LTA0LTE3IDAwOjMzOjAzLjEyMTg3NTAwMCArMDMwMA0KQEAg LTY0OCwxMCArNjQ4LDEyIEBADQogCXN0cnVjdCBiZmVfZGF0YSAqcjsNCiAJdV9pbnQzMl90 IGN0cmw7DQogCWludCBlcnJvcjsNCisJaW50IGFsbG9jYXRlZDsNCiANCiAJaWYgKChjIDwg MCkgfHwgKGMgPj0gQkZFX1JYX0xJU1RfQ05UKSkNCiAJCXJldHVybiAoRUlOVkFMKTsNCiAN CisJYWxsb2NhdGVkID0gKG0gPT0gTlVMTCk7DQogCWlmKG0gPT0gTlVMTCkgew0KIAkJbSA9 IG1fZ2V0Y2woTV9ET05UV0FJVCwgTVRfREFUQSwgTV9QS1RIRFIpOw0KIAkJaWYobSA9PSBO VUxMKQ0KQEAgLTY3MSw4ICs2NzMsMTEgQEANCiAJciA9ICZzYy0+YmZlX3J4X3JpbmdbY107 DQogCWVycm9yID0gYnVzX2RtYW1hcF9sb2FkKHNjLT5iZmVfdGFnLCByLT5iZmVfbWFwLCBt dG9kKG0sIHZvaWQgKiksDQogCQkJTUNMQllURVMsIGJmZV9kbWFfbWFwX2Rlc2MsIGQsIEJV U19ETUFfTk9XQUlUKTsNCi0JaWYgKGVycm9yKQ0KLQkJcHJpbnRmKCJTZXJpb3VzIGVycm9y OiBiZmUgZmFpbGVkIHRvIG1hcCBSWCBidWZmZXJcbiIpOw0KKwlpZiAoZXJyb3IpIHsNCisJ CWlmIChhbGxvY2F0ZWQpDQorCQkJbV9mcmVlKG0pOw0KKwkJcmV0dXJuIChlcnJvcik7DQor CX0NCiAJYnVzX2RtYW1hcF9zeW5jKHNjLT5iZmVfdGFnLCByLT5iZmVfbWFwLCBCVVNfRE1B U1lOQ19QUkVXUklURSk7DQogDQogCWN0cmwgPSBFVEhFUl9NQVhfTEVOICsgMzI7DQo= ------------108F5841BDFF1DB-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 16 23:20:03 2008 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 160631065670 for ; Wed, 16 Apr 2008 23:20:03 +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 049D18FC1C for ; Wed, 16 Apr 2008 23:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3GNK27V023657 for ; Wed, 16 Apr 2008 23:20:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3GNK2hx023656; Wed, 16 Apr 2008 23:20:02 GMT (envelope-from gnats) Date: Wed, 16 Apr 2008 23:20:02 GMT Message-Id: <200804162320.m3GNK2hx023656@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Paul Cc: Subject: Re: amd64/122780: [lagg] tcpdump on lagg interface during high pps wedges netcode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Paul List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2008 23:20:03 -0000 The following reply was made to PR amd64/122780; it has been noted by GNATS. From: Paul To: bug-followup@FreeBSD.org, paul@gtcomm.net Cc: Subject: Re: amd64/122780: [lagg] tcpdump on lagg interface during high pps wedges netcode Date: Wed, 16 Apr 2008 18:40:53 -0400 It seems to happen while attaching the BPF to the interface. I ran a tcpdump first, and then started the traffic and I saw the traffic in tcpdump, but after traffic is going and then issuing tcpdump command, instantly locks. I also just had a lockup with adding and removing ospf networks in quagga ospfd where the entire machine froze when I removed a network (from a lagg interface) , I could not repeat this problem. :/ From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 00:37:22 2008 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 3CAC1106566C for ; Thu, 17 Apr 2008 00:37:22 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.227]) by mx1.freebsd.org (Postfix) with ESMTP id D7BFF8FC14 for ; Thu, 17 Apr 2008 00:37:21 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wr-out-0506.google.com with SMTP id 50so2312wra.13 for ; Wed, 16 Apr 2008 17:37:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=LOUOwTqA7z2z3rBselUrnRke7UkYx8Y1iKsgokTwhG4=; b=g3UPipHm3uF5UOrmH6QHuz9g0i5p5Ub2oUqBTAGgm+IL3xi4zY0cgddPfIEWH3DvJ55whavZA8xJlJtCS/ZwJQI21YzieWFfKf4RimYYw8v3MKKk8Ls+lQ3DG5sP6skWIs7UJDszbysuZWOFyP8gKlZSmJbnSGOPuGjJwWeTbY8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=v4itIZV0+k/pNzHcGHsMhrUrtUObEXhky5mcMuR5oz82zkK619SOWtRR4Tl0blHTHnE0x3AD7bp2m8b1iKN6lac4tRao+JMrNVDIcy6xxmSasdgbFJA44ogYB+cLkpP9Jm6greKpKBZPwLpZqF5qgdbj2ivctibVI9ftcGmK0/4= Received: by 10.142.162.5 with SMTP id k5mr212589wfe.53.1208392640133; Wed, 16 Apr 2008 17:37:20 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 22sm18966758wfg.15.2008.04.16.17.37.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Apr 2008 17:37:19 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m3H0bDk3028596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Apr 2008 09:37:13 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m3H0bDTH028595; Thu, 17 Apr 2008 09:37:13 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 17 Apr 2008 09:37:13 +0900 From: Pyun YongHyeon To: quad Message-ID: <20080417003713.GA28522@cdnetworks.co.kr> References: <1733112647.20080417004353@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1733112647.20080417004353@gmail.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: [bfe] [panic] Serious error: bfe failed to map RX buffer 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 Apr 2008 00:37:22 -0000 On Thu, Apr 17, 2008 at 12:43:53AM +0300, quad wrote: > Hi, > > FreeBSD amd64 7.0-RELEASE, ULE, SMP. > > On heavy loads bfe network driver after few messages > > Serious error: bfe failed to map RX buffer > Serious error: bfe failed to map RX buffer > Serious error: bfe failed to map RX buffer > ... > > make kernel panic. > > Here patch. > It would be even better if you can show me the return code of bus_dmamap_load(9). If the error code is not ENOMEM it requires more bus_dma(9) clean up(bfe(4) needs lots of bus_dma(9) fixing and I had no time so far.) Since the caller of bfe_list_newbuf() expects 0 or ENOBUFS it would be even better to return ENOBUFS for failure case instead of returning error code of bus_dmamap_load(9). -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 00:48:00 2008 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 37192106567B for ; Thu, 17 Apr 2008 00:48:00 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mx1.freebsd.org (Postfix) with ESMTP id 0E18D8FC19 for ; Thu, 17 Apr 2008 00:47:59 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so3880585waf.3 for ; Wed, 16 Apr 2008 17:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=735CjFw5havZnog6GEqJBCx6srAdLDLmlsW+1F0V9bc=; b=Xdzgpp1avBtGwR7Rp6nuSEHEi5ylWywpMH/jAcKaggFrVRcMsTwddvCc3PjMSVtEcHPKCDcN0yMLy50Kg/Lb90hfHhiEdLNZEJRc4bWyEDomrR6qYzwFFESeUdP7lsBgzDaDQnhZOlYfq6ZihLe7ZD7iNO6+TW1bz2eFJq51WWU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=wmoVX30fzX+JLJdrel8X003HqUU/WO6CRPPYL4Oro/64QiaQadWkmSBk1MxMClRqviv+YASezwk5MiUG+NG7fpMmi4hs7O3in1KRWw8jg62StppwrLsYgT/NgLt0owi4qF2mcptjHlsSNMdkNZSYrEJJJN0yfGMiA9rTfAQpzGk= Received: by 10.114.157.1 with SMTP id f1mr767033wae.10.1208393247356; Wed, 16 Apr 2008 17:47:27 -0700 (PDT) Received: by 10.114.255.16 with HTTP; Wed, 16 Apr 2008 17:47:27 -0700 (PDT) Message-ID: Date: Wed, 16 Apr 2008 17:47:27 -0700 From: "Kip Macy" To: "freebsd-net@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Planned contrib/rdma import 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 Apr 2008 00:48:00 -0000 I plan on committing the generic kernel level rdma verb and iwarp infrastructure from OFED as well as the Chelsio iwarp driver to HEAD next week. The RDMA infrastructure doesn't require any kernel changes so I don't foresee any need for a lengthy discussion. For the most part this does not include IB support. Nonetheless, for users that want to add IB support this would be a good starting point. To optimally support user level RDMA would require some extension to the mmap interface but this only supports rdma from the kernel at this time. The code in question that I plan to commit is at: http://157.22.130.171/svn/branches/projects/iwarp/sys/contrib/rdma/ -Kip From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 02:47:52 2008 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 7AAB8106566C for ; Thu, 17 Apr 2008 02:47:52 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outK.internet-mail-service.net (outk.internet-mail-service.net [216.240.47.234]) by mx1.freebsd.org (Postfix) with ESMTP id 6154A8FC16 for ; Thu, 17 Apr 2008 02:47:52 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Thu, 17 Apr 2008 06:51:40 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 973E92D6016; Wed, 16 Apr 2008 19:47:49 -0700 (PDT) Message-ID: <4806BA59.4030106@elischer.org> Date: Wed, 16 Apr 2008 19:47:53 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: FreeBSD Net , Luigi Rizzo , ipfw@freebsd.org Content-Type: multipart/mixed; boundary="------------090907080703050903020505" Cc: Subject: addition to ipfw table.. 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 Apr 2008 02:47:52 -0000 This is a multi-part message in MIME format. --------------090907080703050903020505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit this change allows one to type ipfw table 2 add 1.1.1.1:255.255.255.0 0 in addition to the currently acceptable 1.1.1.1/24 0 The reason is that some programs supply the netmask in that (mask) form and a shell script trying to add it to a table has a hard time converting it to the currently acceptable form (the latter). I do know it won't handle non contiguous masks well but as the ipfw ABI code only accepts a network mask length instead of a mask, there's not much that can be done. I may suggest a later fix for that but it will break the ABI. comments? --------------090907080703050903020505 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="ipfw.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ipfw.diff" Index: ipfw2.c =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sbin/ipfw/ipfw2.c,v retrieving revision 1.118 diff -d -u -r1.118 ipfw2.c --- ipfw2.c 27 Feb 2008 13:52:33 -0000 1.118 +++ ipfw2.c 17 Apr 2008 02:46:34 -0000 @@ -5856,8 +5856,22 @@ ent.masklen = atoi(p); if (ent.masklen > 32) errx(EX_DATAERR, "bad width ``%s''", p); - } else - ent.masklen = 32; + } else { + p = strchr(*av, ':'); + if (p) { + u_int32_t tempint; + *p++ = '\0'; + if (!inet_aton(p, (struct in_addr *)&tempint )) + errx(EX_DATAERR, + "bad netmask ``%s''", p); + if (tempint) + ent.masklen = + 33 - ffs((~ntohl(tempint)) + 1); + else + ent.masklen = 0; + } else + ent.masklen = 32; + } if (lookup_host(*av, (struct in_addr *)&ent.addr) != 0) errx(EX_NOHOST, "hostname ``%s'' unknown", *av); ac--; av++; --------------090907080703050903020505-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 04:57:21 2008 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 53178106564A for ; Thu, 17 Apr 2008 04:57:21 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by mx1.freebsd.org (Postfix) with ESMTP id 24DA38FC17 for ; Thu, 17 Apr 2008 04:57:21 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so4005568waf.3 for ; Wed, 16 Apr 2008 21:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=kj0z5es3Wi4gu/K1/cGkDBWu7cKaGXdwTjgzjnDOTs4=; b=HdLp6AP/73FbQg/65duLmCjST6wQZR2PPxn5WpRJxizGHF/7LHieWLaOtBfaX+/6o6mwy3erXHhzcvXC55S52XRqD6YRhPltNwXkqjsqTlFR1FC1gsV+h24yMKCFd37/LuUfEd9MolZ8cJDGrXGE9e6+g0u/tMcTBdu0Rp74cXo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Pm7v9B3DcIWZWlQe3rmeJ4Bvz60WOfjOp7ehSHnE0lTES/C1UT+nFysnKiFjj39iAhLIzNimhN15yk8pnXH4xnHSzvzX3ox9/UpvHt94ue5jhC17WAYHbBm5F2ikZfg3y/KQOMn718I6tQNPpTmAqYrpyw6/EbxryYWNPuFpCJ4= Received: by 10.115.58.18 with SMTP id l18mr906313wak.177.1208408239971; Wed, 16 Apr 2008 21:57:19 -0700 (PDT) Received: by 10.114.255.16 with HTTP; Wed, 16 Apr 2008 21:57:19 -0700 (PDT) Message-ID: Date: Wed, 16 Apr 2008 21:57:19 -0700 From: "Kip Macy" To: "freebsd-net@freebsd.org" In-Reply-To: <20080417043131.GB1237@stlux503.dsto.defence.gov.au> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080417043131.GB1237@stlux503.dsto.defence.gov.au> Subject: Re: Planned contrib/rdma import 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 Apr 2008 04:57:21 -0000 I received the following question in a private e-mail that I think others might be asking. > what is RDMA and ipwarp ? google didn't help much here :( RDMA in general is the ability to directly DMA to and from the memory of a remote host. In this particular context it is the ability to do so with authentication and access checking and thus does *not* cover firewire or countless other means by which one could trivially do memory to memory transfers. The two transports that allow this are infiniband and iwarp. Infiniband is a link layer transport. Iwarp uses TCP as the underlying transport. For more details you can see the RFCs and the consortium website. 4296 The Architecture of Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) on Internet Protocols. S. Bailey, T. Talpey. December 2005. (Format: TXT=43907 bytes) (Status: INFORMATIONAL) 4297 Remote Direct Memory Access (RDMA) over IP Problem Statement. A. Romanow, J. Mogul, T. Talpey, S. Bailey. December 2005. (Format: TXT=48514 bytes) (Status: INFORMATIONAL) 5040 A Remote Direct Memory Access Protocol Specification. R. Recio, B. Metzler, P. Culley, J. Hilland, D. Garcia. October 2007. (Format: TXT=142247 bytes) (Status: PROPOSED STANDARD) http://www.rdmaconsortium.org/home From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 05:46:03 2008 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 A1A5F106566B; Thu, 17 Apr 2008 05:46:03 +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 766458FC1A; Thu, 17 Apr 2008 05:46:03 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3H5k3oi078142; Thu, 17 Apr 2008 05:46:03 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3H5k3xA078138; Thu, 17 Apr 2008 05:46:03 GMT (envelope-from linimon) Date: Thu, 17 Apr 2008 05:46:03 GMT Message-Id: <200804170546.m3H5k3xA078138@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem 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 Apr 2008 05:46:03 -0000 Old Synopsis: FreeBSD 7 multicast routing problem New Synopsis: [multicast] FreeBSD 7 multicast routing problem Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Apr 17 05:45:46 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=122839 From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 06:03:16 2008 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 00409106566C for ; Thu, 17 Apr 2008 06:03:15 +0000 (UTC) (envelope-from ericlin@tamama.org) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by mx1.freebsd.org (Postfix) with ESMTP id D57BD8FC15 for ; Thu, 17 Apr 2008 06:03:15 +0000 (UTC) (envelope-from ericlin@tamama.org) Received: by rv-out-0506.google.com with SMTP id b25so1569985rvf.43 for ; Wed, 16 Apr 2008 23:03:15 -0700 (PDT) Received: by 10.140.136.6 with SMTP id j6mr515439rvd.56.1208410648344; Wed, 16 Apr 2008 22:37:28 -0700 (PDT) Received: by 10.141.152.4 with HTTP; Wed, 16 Apr 2008 22:37:28 -0700 (PDT) Message-ID: <47713ee10804162237h7223f8c0jf44c8211ffb36269@mail.gmail.com> Date: Thu, 17 Apr 2008 13:37:28 +0800 From: "Lin Jui-Nan Eric" To: freebsd-stable@freebsd.org, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Lots of FIN_WAIT_1 TCP Connections and deadlock in zoneli state 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 Apr 2008 06:03:16 -0000 Hi All, I am running squid as reverse proxy on FreeBSD 7.0-R amd64. After running for a while (~ 8 hours), the throughput degrades to very very low rate. I found the squid is in "zoneli" state and is already a bug report on http://www.freebsd.org/cgi/query-pr.cgi?pr=106317 But after more investigation, I found there are lots of TCP Connections in FIN_WAIT_1 and never close. # netstat -an | grep FIN_WAIT_1 | wc -l 823 # netstat -an | grep FIN_WAIT_1 | head tcp4 0 273 192.168.1.1.80 61.62.121.195.64739 FIN_WAIT_1 tcp4 0 13448 192.168.1.1.80 163.22.44.102.58775 FIN_WAIT_1 tcp4 0 33304 192.168.1.1.80 163.32.61.253.2273 FIN_WAIT_1 tcp4 0 48416 192.168.1.1.80 24.78.35.230.61059 FIN_WAIT_1 tcp4 0 33580 192.168.1.1.80 140.130.102.8.24673 FIN_WAIT_1 tcp4 0 32009 192.168.1.1.80 163.23.57.133.38863 FIN_WAIT_1 tcp4 0 78112 192.168.1.1.80 122.146.0.210.21639 FIN_WAIT_1 tcp4 0 32046 192.168.1.1.80 140.130.102.8.23723 FIN_WAIT_1 tcp4 0 32120 192.168.1.1.80 140.128.194.130.56875 FIN_WAIT_1 tcp4 0 33580 192.168.1.1.80 163.21.235.230.33900 FIN_WAIT_1 Is there a timeout timer for the FIN_WAIT_1 state? Thank you for any suggestions! From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 06:10:17 2008 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 C4AF6106567C; Thu, 17 Apr 2008 06:10:17 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp11.yandex.ru (smtp11.yandex.ru [213.180.223.93]) by mx1.freebsd.org (Postfix) with ESMTP id 9380C8FC38; Thu, 17 Apr 2008 06:10:16 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from ns.kirov.so-cdu.ru ([77.72.136.145]:22991 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S1246489AbYDQFrX (ORCPT + 1 other); Thu, 17 Apr 2008 09:47:23 +0400 X-Yandex-Spam: 1 X-Yandex-Front: smtp11 X-Yandex-TimeMark: 1208411243 X-MsgDayCount: 4 X-Comment: RFC 2476 MSA function at smtp11.yandex.ru logged sender identity as: bu7cher Message-ID: <4806E468.5030906@yandex.ru> Date: Thu, 17 Apr 2008 09:47:20 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Julian Elischer References: <4806BA59.4030106@elischer.org> In-Reply-To: <4806BA59.4030106@elischer.org> Content-Type: multipart/mixed; boundary="------------090204050606090409040801" Cc: FreeBSD Net , ipfw@freebsd.org, Luigi Rizzo Subject: Re: addition to ipfw table.. 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 Apr 2008 06:10:18 -0000 This is a multi-part message in MIME format. --------------090204050606090409040801 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Julian Elischer wrote: > I do know it won't handle non contiguous masks well but as the > ipfw ABI code only accepts a network mask length instead of a > mask, there's not much that can be done. > I may suggest a later fix for that but it will break the ABI. > > comments? What you think about my patch? -- WBR, Andrey V. Elsukov --------------090204050606090409040801 Content-Type: text/plain; name="ipfw_table_mask.diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ipfw_table_mask.diff.txt" Index: src/sbin/ipfw/ipfw2.c =================================================================== RCS file: /ncvs/src/sbin/ipfw/ipfw2.c,v retrieving revision 1.118 diff -u -p -r1.118 ipfw2.c --- src/sbin/ipfw/ipfw2.c 27 Feb 2008 13:52:33 -0000 1.118 +++ src/sbin/ipfw/ipfw2.c 17 Apr 2008 05:45:27 -0000 @@ -5833,7 +5833,7 @@ table_handler(int ac, char *av[]) ipfw_table_entry ent; ipfw_table *tbl; int do_add; - char *p; + char *p, md; socklen_t l; uint32_t a; @@ -5850,10 +5850,22 @@ table_handler(int ac, char *av[]) ac--; av++; if (!ac) errx(EX_USAGE, "IP address required"); - p = strchr(*av, '/'); + p = strpbrk(*av, "/:"); if (p) { + md = *p; *p++ = '\0'; - ent.masklen = atoi(p); + switch (md) { + case ':': + if (!inet_aton(p, (struct in_addr *)&a)) + errx(EX_DATAERR, "bad netmask ``%s''", p); + ent.masklen = contigmask((uint8_t *)&a, 32); + if (ent.masklen > 32) + errx(EX_DATAERR, + "netmask ``%s'' is not contiguous", p); + break; + case '/': + ent.masklen = atoi(p); + } if (ent.masklen > 32) errx(EX_DATAERR, "bad width ``%s''", p); } else --------------090204050606090409040801-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 08:56:00 2008 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 129DF1065672; Thu, 17 Apr 2008 08:56:00 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 02C488FC17; Thu, 17 Apr 2008 08:56:00 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (bms@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3H8txa4094074; Thu, 17 Apr 2008 08:55:59 GMT (envelope-from bms@freefall.freebsd.org) Received: (from bms@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3H8twoK094070; Thu, 17 Apr 2008 08:55:58 GMT (envelope-from bms) Date: Thu, 17 Apr 2008 08:55:58 GMT Message-Id: <200804170855.m3H8twoK094070@freefall.freebsd.org> To: 4pr@legis.krsn.ru, bms@FreeBSD.org, freebsd-net@FreeBSD.org From: bms@FreeBSD.org Cc: Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem 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 Apr 2008 08:56:00 -0000 Synopsis: [multicast] FreeBSD 7 multicast routing problem State-Changed-From-To: open->feedback State-Changed-By: bms State-Changed-When: Thu 17 Apr 2008 08:49:01 UTC State-Changed-Why: The symptoms you describe do not sound like a multicast routing issue. Given your description it sounds like the ethernet drivers are not implementing ALLMULTI correctly. If the ALLMULTI flag is appearing in the ifconfig output for the interfaces involved, that is the correct behaviour. The multicast forwarding code *requires* that the card supports ALLMULTI correctly. However ALLMULTI has historically been known not to work correctly with certain network adapters, and in this case it could be a firmware issue. For example I saw an issue with fxp last week whereby the card wouldn't send multicast traffic unless the group had also been joined, which violates POLA. Can you ping Pyun YongHyeon and/or Jack Vogel about this? Both have been working on the msk and em drivers recently so they can better advise you about possible driver problems. Thanks. http://www.freebsd.org/cgi/query-pr.cgi?pr=122839 From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 09:50:12 2008 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 11774106566C; Thu, 17 Apr 2008 09:50:12 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id C44E18FC25; Thu, 17 Apr 2008 09:50:10 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m3H2rbAh029099; Thu, 17 Apr 2008 12:53:37 +1000 Received: from c220-239-252-11.carlnfd3.nsw.optusnet.com.au (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m3H2rOjs030342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Apr 2008 12:53:28 +1000 Date: Thu, 17 Apr 2008 12:53:24 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Alexander Sack In-Reply-To: <3c0b01820804161402u3aac4425n41172294ad33a667@mail.gmail.com> Message-ID: <20080417112329.G47027@delplex.bde.org> References: <3c0b01820804160929i76cc04fdy975929e2a04c0368@mail.gmail.com> <200804161456.20823.jkim@FreeBSD.org> <3c0b01820804161328m77704ca0g43077a9718d446d4@mail.gmail.com> <200804161654.22452.jkim@FreeBSD.org> <3c0b01820804161402u3aac4425n41172294ad33a667@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org, Dieter , Jung-uk Kim Subject: Re: bge dropping packets 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: Thu, 17 Apr 2008 09:50:12 -0000 On Wed, 16 Apr 2008, Alexander Sack wrote: > On Wed, Apr 16, 2008 at 4:54 PM, Jung-uk Kim wrote: >> On Wednesday 16 April 2008 04:28 pm, Alexander Sack wrote: >> > On Wed, Apr 16, 2008 at 2:56 PM, Jung-uk Kim >> wrote: >> >> [CC trimmed] >> >> >> >> On Wednesday 16 April 2008 02:20 pm, Alexander Sack wrote: >> >> > Dieter: Thanks, at 20Mbps! That's pretty aweful. >> >> > >> >> > JK: Thanks again. Wow, I searched the list and didn't see >> >> > much discussion with respect to bge and packet loss! I will >> >> > try the rest of that patch including pushing the TCP receive >> >> > buffer up (though I don't think that's going to help in this >> >> > case). The above is based on just looking at code.... First stop using the DEVICE_POLLING packet lossage service... >> >> > I guess some follow-up questions would be: >> >> > >> >> > 1) Why isn't BGE_SSLOTS tunable (to a point)? Why can't that >> >> > be added the driver? I noticed that CURRENT has added a lot >> >> > more SYSCTL information. Moreover it seems the Linux driver >> >> > can set it up to 1024. >> >> >> >> IIRC, Linux tg3 uses one ring for both standard and jumbo. >> > >> > I'm talking about the number of slots within the ring not the >> > number of RX queues. >> > >> > I believe the bnx4 driver (thought the tg stuff was deprecated??) >> > uses 4 rings (one for each port perhaps) and reads hardware >> > register at ISR time to flip between them. >> >> I guess you are reading wrong source, i.e., bnx4(?) is NetXtreme II >> driver, which totally different family. We support them with bce(4). >> tg3 is still official Linux driver. > > You are correct, I got the names confused (this problem really stinks)! > > However, my point still stands: > > #define TG3_RX_RCB_RING_SIZE(tp) ((tp->tg3_flags2 & > TG3_FLG2_5705_PLUS) ? 512 : 1024) > > Even the Linux driver uses higher number of RX descriptors than > FreeBSD's static 256. I think minimally making this tunable is a fair > approach. > > If not, no biggie, but I think its worth it. I use a fixed value of 512 (jkim gave a pointer to old mail containing a fairly up to date version of my patches for this and more important things). This should only make a difference with DEVICE_POLLING. Without DEVICE_POLLING, device interrupts normally occur every 150 usec or even more frequently (too frequently if the average is much lower than 150 usec), so 512 descriptors is more than enough for 1Gbps ethernet (the minimum possible inter-descriptor time for tiny packets is about 0.6 usec, so the minimum number of descriptors is 150 / 0.6 = 250. The minimum possible inter-descriptor time is rarely achieved, so 250 is enough even with some additional latency. See below for more numbers). With DEVICE_POLLING at HZ = 1000, the corresponding minimum number of descriptors is 1000 / 0.6 = 1667. No tuning can give this number. You can increase HZ to 4000 and then the fixed value of 512 is large enough. However, HZ = 4000 is wasteful, and might not actually deliver 4000 polls per second -- missed polls are more likely at higher frequencies. For timeouts instead of device polls, at least on old systems it was quite common for timeouts at a frequency of HZ not actually being delivered, even when HZ was only 100, because some timeouts run for too long (several msec each, possibly combining to > 10 msec occasionally). Device polls are at a lower level, so they have a better chance of actually keeping up with HZ. Now the main source of timeouts that run for too long is probably mii tick routines. These won't combine, at least for MPSAFE drivers, but they will block both interrupts and device polls for their own device. So the rx ring size needs to be large enough to cover max(150 usec or whatever interrupt moderation time, mii tick time) of latency plus any other latencies due to interrupt handling or polling of for other devices. Latencies due to interrupts on other devices is only certain to be significant if the other devices have higher or the same priority. I don't understand how 1024 can be useful for 5705_PLUS. PLUS really means MINUS -- at pleast my plain 5705 device has about 1/4 of the performance of my older 5701 device. The data sheet gives a limit of 512 normal rx descriptors for both. Non-MINUS devices also support jumbo buffers. These are in a separate ring and not affected by the limit of 256 in FreeBSD. Some numbers for [1 Gbps] ethernet: minimum frame size = 64 bytes = 512 bits minimum inter-frame gap = 96 bits minimum total frame time = 608 nsec (may be off by 64) bge descriptors per tiny frame = 1 (1 for mbuf) buffering provided by 256 descriptors = 256 * 608 = 155.648 usec (marginal) normal frame size = 1518 bytes = 12144 bits normal total frame time = 12240 nsec bge descriptors per normal frame = 2 (1 for mbuf and 1 for mbuf cluster) buffering provided by 256 descriptors = 256/2 * 12240 = 1556.720 usec (plenty) The only tuning that I've found useful since writing my old mail (with the patches) is: sysctl kern.random.sys.harvest.ethernet=0 sysctl kern.random.sys.harvest.interrupt=0 sysctl net.inet.ip.intr_queue_maxlen=1024 Killing the entropy harvester isn't very important, and IIRC the default intr_queue_maxlen of 50 is only a problem with net.isr.direct=0 (not the default in -current). With an rx ring size of just 256 and small packets so that there is only 1 descriptor per packet, a single bge interrupt or poll can produces 5 times as many packets as will fit in the default intr_queue. IIRC, net.isr.direct=1 has the side affect of completely bypassing the intr_queue_maxlen limit, so floods cause extra damage before they are detected. However, the old limit of 50 is nonsense for all not so old NICs. Another problem with the intr_queue_maxlen limit is that packets dropped because of it don't show up in any networking statistics utility. They only show up in sysctl output and cannot be associated with individual interfaces. Bruce From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 10:43:50 2008 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 B39B31065671; Thu, 17 Apr 2008 10:43:50 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7A91A8FC15; Thu, 17 Apr 2008 10:43:50 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 888C946B13; Thu, 17 Apr 2008 06:43:49 -0400 (EDT) Date: Thu, 17 Apr 2008 11:43:49 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: <20080417112757.M1046@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: net@FreeBSD.org Subject: Moving pcbinfo and inpcb locks from mutexes to rwlocks 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 Apr 2008 10:43:50 -0000 Dear all, In the next couple of days (exact schedule depends on how testing goes), I'll merge a portion of the rwlock lock patch that I've developed and that Kris has been testing. This opens the door to increased parallelism in the network stack by facilitating UDP and TCP moves to read-locking of certain data structures under certain conditions. These patches were originally developed to address known high lock contention when running the BIND9 and nsd name servers, which employ a single UDP socket from many threads simultaneously. In the first pass, the changes simply substitute an rwlock for a mutex, and convert the accessor macros to explicit write-locking for inpcbs; for pcbinfo, we allow read locking to be used in certain restricted situations, and generalize certain lock assertions to allow read locks to be held. However, in practice, this pass should make little functional difference, as all key paths will remain protected by exclusive locking. This will then settle for a bit to attempt to show up any problems that didn't turn up in testing so far, and then... In the second pass, write locking is replaced with read locking of the pcbinfo lock in input paths for UDP, and write locking of the inpcb is replaced with read locking in many cases in the output paths, elimating one source of high lock contention for BIND/nsd. TCP continues to use exclusive locking in all cases with this set of changes. It is my understanding, and I need to confirm this, that struct rwlock is the same size as struct mutex, meaning that (a) they don't require monitoring tools to be rebuilt, and (b) these are potential MFC candidates. If you run into ABI problems with monitoring tools after the merge, please let me know (including architecture information, etc). Thanks, Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 12:53:47 2008 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 ADA4C1065672; Thu, 17 Apr 2008 12:53:47 +0000 (UTC) (envelope-from gnn@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8A7E08FC1D; Thu, 17 Apr 2008 12:53:47 +0000 (UTC) (envelope-from gnn@FreeBSD.org) Received: from freefall.freebsd.org (gnn@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3HCrlSQ014011; Thu, 17 Apr 2008 12:53:47 GMT (envelope-from gnn@freefall.freebsd.org) Received: (from gnn@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3HCrlZv014007; Thu, 17 Apr 2008 12:53:47 GMT (envelope-from gnn) Date: Thu, 17 Apr 2008 12:53:47 GMT Message-Id: <200804171253.m3HCrlZv014007@freefall.freebsd.org> To: snow@teardrop.org, gnn@FreeBSD.org, freebsd-net@FreeBSD.org, gnn@FreeBSD.org From: gnn@FreeBSD.org Cc: Subject: Re: kern/120958: no response to ICMP traffic on interface configured with a link-local address 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 Apr 2008 12:53:47 -0000 Synopsis: no response to ICMP traffic on interface configured with a link-local address State-Changed-From-To: open->patched State-Changed-By: gnn State-Changed-When: Thu Apr 17 12:51:46 UTC 2008 State-Changed-Why: User submitted a patch which is now applied and tested. Take over bug until closed. Responsible-Changed-From-To: freebsd-net->gnn Responsible-Changed-By: gnn Responsible-Changed-When: Thu Apr 17 12:51:46 UTC 2008 Responsible-Changed-Why: The user's suggested patch has been applied. Take the bug over until its closed. http://www.freebsd.org/cgi/query-pr.cgi?pr=120958 From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 13:44:09 2008 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 51EF21065684 for ; Thu, 17 Apr 2008 13:44:09 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id E459B8FC14 for ; Thu, 17 Apr 2008 13:44:08 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by yw-out-2324.google.com with SMTP id 2so45020ywt.13 for ; Thu, 17 Apr 2008 06:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=h5pTrpFLBAIh+rsbWr4oXjOedcCVBcsXNte4aqwW9xo=; b=KcLVWcR+fFQHBs8eXNyksRPUrD4PBLlyj2m1digN7TD4hcaiHiwGYDaVsIpFmqYl37Q49Iod9wZHBrovQs5DwnEV29vYtVh4emU0LwHvCzEAx6txvZTxf4YEk6ZmxOXDqVeqfgwZW2txLM0DWSDyGADw4KkUEgiB9mCbjDEq2WI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tSgapjwC53Wp5M9ddRsFyXRbD8cLRysWYZBlg0BKKbYGcPvrm4nyGukO4gKWxZNEIg7YTDIYwJmEzLjUPwZXC1sf51UoO9kMEYOJiSTjOaDWh+COVnucfBgf8lyMx0uatXdPVDKEfKwVG4e1fwz5PKvIYLMoUWsWZ3347Iv3CJw= Received: by 10.151.84.12 with SMTP id m12mr1650863ybl.169.1208439837204; Thu, 17 Apr 2008 06:43:57 -0700 (PDT) Received: by 10.151.15.21 with HTTP; Thu, 17 Apr 2008 06:43:57 -0700 (PDT) Message-ID: <3c0b01820804170643w6b771ce9jdfc2dc5b240922b@mail.gmail.com> Date: Thu, 17 Apr 2008 09:43:57 -0400 From: "Alexander Sack" To: "Bruce Evans" In-Reply-To: <20080417112329.G47027@delplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3c0b01820804160929i76cc04fdy975929e2a04c0368@mail.gmail.com> <200804161456.20823.jkim@FreeBSD.org> <3c0b01820804161328m77704ca0g43077a9718d446d4@mail.gmail.com> <200804161654.22452.jkim@FreeBSD.org> <3c0b01820804161402u3aac4425n41172294ad33a667@mail.gmail.com> <20080417112329.G47027@delplex.bde.org> Cc: freebsd-net@freebsd.org, Dieter , Jung-uk Kim Subject: Re: bge dropping packets 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: Thu, 17 Apr 2008 13:44:09 -0000 First off thanks for the detailed reply Bruce. I have some follow-up questions in my quest to learn more about BGE/networking etc. On Wed, Apr 16, 2008 at 10:53 PM, Bruce Evans wrote: > On Wed, 16 Apr 2008, Alexander Sack wrote: > > On Wed, Apr 16, 2008 at 4:54 PM, Jung-uk Kim wrote: > > First stop using the DEVICE_POLLING packet lossage service... > For my own edification, when do you want use DEVICE_POLLING versus interrupt driven network I/O? With all question like these I suppose the answer depends on the workload and the interrupt bandwidth of the machine (which depends on the type of hardware)... But why was it added to begin with if standard interrupt driven I/O is faster? (was it the fact that historically hardware didn't do interrupt coalescing initially) This was my next step so it sounds like I'm in the right direction. > > You are correct, I got the names confused (this problem really stinks)! > > > > However, my point still stands: > > > > #define TG3_RX_RCB_RING_SIZE(tp) ((tp->tg3_flags2 & > > TG3_FLG2_5705_PLUS) ? 512 : 1024) > > > > Even the Linux driver uses higher number of RX descriptors than > > FreeBSD's static 256. I think minimally making this tunable is a fair > > approach. > > > > If not, no biggie, but I think its worth it. > > > > I use a fixed value of 512 (jkim gave a pointer to old mail containing > a fairly up to date version of my patches for this and more important > things). This should only make a difference with DEVICE_POLLING. Then minimally 512 could be used if DEVICE_POLLING is enabled and my point still stands. Though in light of the other statistics you cited I understand now that this may not make that big of an impact. > Without DEVICE_POLLING, device interrupts normally occur every 150 usec Is that the coal ticks value you are referring too? Sorry this is my first time looking at this driver! > or even more frequently (too frequently if the average is much lower > than 150 usec), so 512 descriptors is more than enough for 1Gbps ethernet > (the minimum possible inter-descriptor time for tiny packets is about 0.6 > usec, How do you measure this number? I'm assuming when you say "inter-descriptor time" you mean the time it takes the card to fill a RX descriptor on receipt of a packet (really the firmware latency?). > so the minimum number of descriptors is 150 / 0.6 = 250. The > minimum possible inter-descriptor time is rarely achieved, so 250 is > enough even with some additional latency. See below for more numbers). > With DEVICE_POLLING at HZ = 1000, the corresponding minimum number of > descriptors is 1000 / 0.6 = 1667. No tuning can give this number. You > can increase HZ to 4000 and then the fixed value of 512 is large enough. > However, HZ = 4000 is wasteful, and might not actually deliver 4000 polls > per second -- missed polls are more likely at higher frequencies. Understood makes sense. > For timeouts instead of device polls, at least on old systems it was > quite common for timeouts at a frequency of HZ not actually being > delivered, even when HZ was only 100, because some timeouts run for > too long (several msec each, possibly combining to > 10 msec occasionally). > Device polls are at a lower level, so they have a better chance of > actually keeping up with HZ. Now the main source of timeouts that run > for too long is probably mii tick routines. These won't combine, at > least for MPSAFE drivers, but they will block both interrupts and > device polls for their own device. So the rx ring size needs to be > large enough to cover max(150 usec or whatever interrupt moderation time, > mii tick time) of latency plus any other latencies due to interrupt > handling > or polling of for other devices. Latencies due to interrupts on other > devices is only certain to be significant if the other devices have higher > or the same priority. You described what I'm seeing. Couple this with the fact that the driver uses one mtx for everything doesn't help. I'm pretty sure I'm running into RX descriptor starvation despite the fact that statistically speaking, 256 descriptors is enough for 1Gbps (I'm talking 100MBps the firmware is dropping packets). The problem gets worse if I add some kind of I/O workload on the system (my load happens to be a gzip of a large log file in /tmp). I noticed that if I put ANY kind of debugging messages in bge_tick() the drop gets much worse (for example just printing out the number of dropped packets read from bge_stats_update() when a drop occurs causes EVEN more drops to incur and if I had to guess its the printf just uses up more cycles which delays the drain of RX chain and causes a longer time to recover - this is a constant stream from a traffic generator). > I don't understand how 1024 can be useful for 5705_PLUS. PLUS really > means MINUS -- at pleast my plain 5705 device has about 1/4 of the > performance of my older 5701 device. The data sheet gives a limit of > 512 normal rx descriptors for both. Non-MINUS devices also support > jumbo buffers. These are in a separate ring and not affected by the > limit of 256 in FreeBSD. Well it seems that the 5714, 5715, and 5780 when configured to use jumbo frames and extended buffer descriptors falls to 256 so it seems 256 is generally a safe number for all cards (but I still submit that the fact that you yourself bump it to 512 for std frames means this should be optionally tunable). > Some numbers for [1 Gbps] ethernet: > > minimum frame size = 64 bytes = 512 bits > minimum inter-frame gap = 96 bits > minimum total frame time = 608 nsec (may be off by 64) > bge descriptors per tiny frame = 1 (1 for mbuf) > buffering provided by 256 descriptors = 256 * 608 = 155.648 usec (marginal) So as I read this, its takes 155 usec to fill up the entre RX chain of rx_bd's if its just small packets, correct? > normal frame size = 1518 bytes = 12144 bits > normal total frame time = 12240 nsec > bge descriptors per normal frame = 2 (1 for mbuf and 1 for mbuf cluster) > buffering provided by 256 descriptors = 256/2 * 12240 = 1556.720 usec > (plenty) Is this based again on your own instrumentation based on the last patch? (just curious, I believe you, I just wanted to know if this was an artifact of you doing some tuning research or something else) > The only tuning that I've found useful since writing my old mail (with > the patches) is: > > sysctl kern.random.sys.harvest.ethernet=0 > sysctl kern.random.sys.harvest.interrupt=0 > sysctl net.inet.ip.intr_queue_maxlen=1024 > > Killing the entropy harvester isn't very important, and IIRC the default > intr_queue_maxlen of 50 is only a problem with net.isr.direct=0 (not the > default in -current). With an rx ring size of just 256 and small packets > so that there is only 1 descriptor per packet, a single bge interrupt or > poll can produces 5 times as many packets as will fit in the default > intr_queue. IIRC, net.isr.direct=1 has the side affect of completely > bypassing the intr_queue_maxlen limit, so floods cause extra damage before > they are detected. However, the old limit of 50 is nonsense for all > not so old NICs. Another problem with the intr_queue_maxlen limit is that > packets dropped because of it don't show up in any networking statistics > utility. They only show up in sysctl output and cannot be associated with > individual interfaces. Interesting, though the packet loss I'm describing is indeed reported by the card and not drops due to hitting intr_queue_mexlen (honestly I haven't looked at this aspect of the system yet so I can't comment). Bruce, again thank you for your in depth email. So the million dollar question: Do you believe that if I disable DEVICE_POLLING and use interrupt driven I/O, I could achieve zero packet loss over a 1Gbps link? This is the main issue I need to solve (solve means either no its not really achievable without a heavy rewrite of the driver OR yes it is with some tuning). If the answer is yes, then I have to understand the impact on the system in general. I just want to be sure I'm on a viable path through the BGE maze! :D! Thanks! -aps From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 13:59:53 2008 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 B00101065670 for ; Thu, 17 Apr 2008 13:59:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 850DC8FC17 for ; Thu, 17 Apr 2008 13:59:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 1C88746B37; Thu, 17 Apr 2008 09:59:53 -0400 (EDT) Date: Thu, 17 Apr 2008 14:59:53 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexander Sack In-Reply-To: <3c0b01820804170643w6b771ce9jdfc2dc5b240922b@mail.gmail.com> Message-ID: <20080417145652.J71628@fledge.watson.org> References: <3c0b01820804160929i76cc04fdy975929e2a04c0368@mail.gmail.com> <200804161456.20823.jkim@FreeBSD.org> <3c0b01820804161328m77704ca0g43077a9718d446d4@mail.gmail.com> <200804161654.22452.jkim@FreeBSD.org> <3c0b01820804161402u3aac4425n41172294ad33a667@mail.gmail.com> <20080417112329.G47027@delplex.bde.org> <3c0b01820804170643w6b771ce9jdfc2dc5b240922b@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Dieter , Jung-uk Kim Subject: Re: bge dropping packets 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: Thu, 17 Apr 2008 13:59:53 -0000 On Thu, 17 Apr 2008, Alexander Sack wrote: > First off thanks for the detailed reply Bruce. I have some follow-up > questions in my quest to learn more about BGE/networking etc. > > On Wed, Apr 16, 2008 at 10:53 PM, Bruce Evans wrote: >> On Wed, 16 Apr 2008, Alexander Sack wrote: >>> On Wed, Apr 16, 2008 at 4:54 PM, Jung-uk Kim wrote: >> >> First stop using the DEVICE_POLLING packet lossage service... > > For my own edification, when do you want use DEVICE_POLLING versus interrupt > driven network I/O? With all question like these I suppose the answer > depends on the workload and the interrupt bandwidth of the machine (which > depends on the type of hardware)... > > But why was it added to begin with if standard interrupt driven I/O is > faster? (was it the fact that historically hardware didn't do interrupt > coalescing initially) There are serious functional limitations to the current DEVICE_POLLING code in the new world order of device drivers, ithread, SMP, etc. Leaving this aside, here are two reasons why it exists: (1) Historically, devices did not support interrupt moderation. (2) Even with interrupt moderation, livelock can occur because there is no facility to limit the CPU use assigned to sources of network load. Something interrupt moderation does *not* provide is the ability to schedule network stack processing at idle priority, or limit CPU use to a percentage of total CPU in order to leave CPU resources for other activity (such as fixing the load problem, getting work done, etc). Our device polling infrastructure needs serious work, and I think quite a bit of it could usefully move to the interrupt infrastructure layer, but we should be careful to consider some of the functional aspects to DEVICE_POLLING that do differentiate it (load management, not just interrupt moderation). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 14:11:40 2008 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 236D8106566B for ; Thu, 17 Apr 2008 14:11:40 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id D30348FC1E for ; Thu, 17 Apr 2008 14:11:39 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by yw-out-2324.google.com with SMTP id 2so51781ywt.13 for ; Thu, 17 Apr 2008 07:11:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ucHv7AyvzekaOW0EmDaadcH6StHH1DKvg1owYdT+YOQ=; b=nUDw28HFfMDf5d9MTWVByaiY+/91n7hRV4g+QPrNaOL20Vxu0nLIKsQIVSLzNoC1M55gx9fHgWukrKpqE0UhYbw4cbDUO9HT9Pqq4+QrEwniL0ZRcUf7zqzdRPmUMTYu1wDFThJEEnL9jFG2hEuLtIzLAhL+k7AVWjqSHyYpv9U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=V+LCoC9OvMS96P66om88RZe8Ey0oZ5/VN0Cye4go0ChBEcXRNNQht7h+pPJyDoEhqabXwH/XhwmQs0qZTlIHYFJ1YKjdwG+DiBwpMehY0Oli8COBc5iYWn7yU7z6E5eU1cWM1ealT9lrIDSSyL8UZp7j1djZ5z7xfR7em4sGfxY= Received: by 10.151.108.19 with SMTP id k19mr1670105ybm.191.1208441137232; Thu, 17 Apr 2008 07:05:37 -0700 (PDT) Received: by 10.151.15.21 with HTTP; Thu, 17 Apr 2008 07:05:37 -0700 (PDT) Message-ID: <3c0b01820804170705l9c196d9rff45fa4919ace8c@mail.gmail.com> Date: Thu, 17 Apr 2008 10:05:37 -0400 From: "Alexander Sack" To: "Robert Watson" In-Reply-To: <20080417145652.J71628@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3c0b01820804160929i76cc04fdy975929e2a04c0368@mail.gmail.com> <200804161456.20823.jkim@FreeBSD.org> <3c0b01820804161328m77704ca0g43077a9718d446d4@mail.gmail.com> <200804161654.22452.jkim@FreeBSD.org> <3c0b01820804161402u3aac4425n41172294ad33a667@mail.gmail.com> <20080417112329.G47027@delplex.bde.org> <3c0b01820804170643w6b771ce9jdfc2dc5b240922b@mail.gmail.com> <20080417145652.J71628@fledge.watson.org> Cc: freebsd-net@freebsd.org, Dieter , Jung-uk Kim Subject: Re: bge dropping packets 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: Thu, 17 Apr 2008 14:11:40 -0000 On Thu, Apr 17, 2008 at 9:59 AM, Robert Watson wrote: > On Thu, 17 Apr 2008, Alexander Sack wrote: > > First off thanks for the detailed reply Bruce. I have some follow-up > > questions in my quest to learn more about BGE/networking etc. > > > > On Wed, Apr 16, 2008 at 10:53 PM, Bruce Evans > wrote: > > > > > On Wed, 16 Apr 2008, Alexander Sack wrote: > > > > > > > On Wed, Apr 16, 2008 at 4:54 PM, Jung-uk Kim wrote: > > > > > > > > > > First stop using the DEVICE_POLLING packet lossage service... > > > > > > > For my own edification, when do you want use DEVICE_POLLING versus > interrupt driven network I/O? With all question like these I suppose the > answer depends on the workload and the interrupt bandwidth of the machine > (which depends on the type of hardware)... > > > > But why was it added to begin with if standard interrupt driven I/O is > faster? (was it the fact that historically hardware didn't do interrupt > coalescing initially) > > > > There are serious functional limitations to the current DEVICE_POLLING code > in the new world order of device drivers, ithread, SMP, etc. Leaving this > aside, here are two reasons why it exists: > > (1) Historically, devices did not support interrupt moderation. That was my original guess! :D! > (2) Even with interrupt moderation, livelock can occur because there is no > facility to limit the CPU use assigned to sources of network load. So this provides the OS to optionally throttle heavy network load in order to ensure liveliness as I understand you. > Something interrupt moderation does *not* provide is the ability to > schedule network stack processing at idle priority, or limit CPU use to a > percentage of total CPU in order to leave CPU resources for other activity > (such as fixing the load problem, getting work done, etc). Our device > polling infrastructure needs serious work, and I think quite a bit of it > could usefully move to the interrupt infrastructure layer, but we should be > careful to consider some of the functional aspects to DEVICE_POLLING that do > differentiate it (load management, not just interrupt moderation). Robert, alright, this all makes sense. So it seems to me that the first step to salvation in my world is to turn off DEVICE_POLLING and rely on the interrupt coalescing that exists on the card. My only concern if this does work is what impact this has on the overall system. -aps From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 14:31:37 2008 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 4433C1065677; Thu, 17 Apr 2008 14:31:37 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id E1EA48FC2B; Thu, 17 Apr 2008 14:31:36 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 518E546B66; Thu, 17 Apr 2008 10:31:35 -0400 (EDT) Date: Thu, 17 Apr 2008 15:31:35 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexander Sack In-Reply-To: <3c0b01820804170705l9c196d9rff45fa4919ace8c@mail.gmail.com> Message-ID: <20080417152837.E71628@fledge.watson.org> References: <3c0b01820804160929i76cc04fdy975929e2a04c0368@mail.gmail.com> <200804161456.20823.jkim@FreeBSD.org> <3c0b01820804161328m77704ca0g43077a9718d446d4@mail.gmail.com> <200804161654.22452.jkim@FreeBSD.org> <3c0b01820804161402u3aac4425n41172294ad33a667@mail.gmail.com> <20080417112329.G47027@delplex.bde.org> <3c0b01820804170643w6b771ce9jdfc2dc5b240922b@mail.gmail.com> <20080417145652.J71628@fledge.watson.org> <3c0b01820804170705l9c196d9rff45fa4919ace8c@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Dieter , Jung-uk Kim Subject: Re: bge dropping packets 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: Thu, 17 Apr 2008 14:31:37 -0000 On Thu, 17 Apr 2008, Alexander Sack wrote: > Robert, alright, this all makes sense. So it seems to me that the first > step to salvation in my world is to turn off DEVICE_POLLING and rely on the > interrupt coalescing that exists on the card. My only concern if this does > work is what impact this has on the overall system. I would generally discourage use of our current DEVICE_POLLING code using modern network devices, as the polling rate as compared to buffer size has changed significantly, meaning that polling rates have to be set ridiculously high. Also, I suspect strongly that it interacts badly with our ithread/scheduling/etc parts, which might lead to difficult to diagnose problems. Interrupt moderation is not as featureful as DEVICE_POLLING, but it is better supported; I'd like to see further work done to allow us to pick up some of the scheduling features for ithreads as well in the future. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 14:34:01 2008 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 0E9BB106564A for ; Thu, 17 Apr 2008 14:34:01 +0000 (UTC) (envelope-from chris@arnold.se) Received: from mailstore.infotropic.com (mailstore.infotropic.com [213.136.34.3]) by mx1.freebsd.org (Postfix) with ESMTP id 595658FC29 for ; Thu, 17 Apr 2008 14:34:00 +0000 (UTC) (envelope-from chris@arnold.se) Received: (qmail 94302 invoked by uid 89); 17 Apr 2008 14:07:18 -0000 Received: by simscan 1.2.0 ppid: 94297, pid: 94299, t: 0.1395s scanners: attach: 1.2.0 clamav: 0.90/m:42 Received: from unknown (HELO ?192.168.123.123?) (chris@arnold.se@212.71.168.45) by mailstore.infotropic.com with ESMTPA; 17 Apr 2008 14:07:18 -0000 Date: Thu, 17 Apr 2008 16:07:16 +0200 (CEST) From: Christopher Arnold X-X-Sender: chris@localhost To: Alexander Sack In-Reply-To: <3c0b01820804170643w6b771ce9jdfc2dc5b240922b@mail.gmail.com> Message-ID: <20080417160712.S5510@localhost> References: <3c0b01820804160929i76cc04fdy975929e2a04c0368@mail.gmail.com> <200804161456.20823.jkim@FreeBSD.org> <3c0b01820804161328m77704ca0g43077a9718d446d4@mail.gmail.com> <200804161654.22452.jkim@FreeBSD.org> <3c0b01820804161402u3aac4425n41172294ad33a667@mail.gmail.com> <20080417112329.G47027@delplex.bde.org> <3c0b01820804170643w6b771ce9jdfc2dc5b240922b@mail.gmail.com> X-message-flag: =?ISO-8859-1?Q?Outlook_isn=B4t_compliant_with_current_standards?= =?ISO-8859-1?Q?_please_install_another_mail_client!?= MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: bge dropping packets 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: Thu, 17 Apr 2008 14:34:01 -0000 On Thu, 17 Apr 2008, Alexander Sack wrote: > For my own edification, when do you want use DEVICE_POLLING versus > interrupt driven network I/O? With all question like these I suppose > the answer depends on the workload and the interrupt bandwidth of the > machine (which depends on the type of hardware)... > > But why was it added to begin with if standard interrupt driven I/O is > faster? (was it the fact that historically hardware didn't do > interrupt coalescing initially) > The ability to reserve cpu is one of the great features. If your host is being DDOS'ed it is good to have a portion of the CPU reserved to applications so a) the machine dosn't die. and b) so you can continue to login and investigate and perhaps solve the problem. /Chris -- http://www.arnold.se/ http://www.mbit.us/ From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 14:52:13 2008 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 F3C1F106564A for ; Thu, 17 Apr 2008 14:52:12 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id AC3A58FC1D for ; Thu, 17 Apr 2008 14:52:07 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by yw-out-2324.google.com with SMTP id 2so61445ywt.13 for ; Thu, 17 Apr 2008 07:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Kg6WkPrg+Ub0Ik4Xcx+Zh5UPKsJWBFYz44iQqdS/8U4=; b=eWPO1prv10iq/YZe+HCEE67xXtOj+0ttuCfyW73wCbIKFnglCykMT60VY+CV++OoPpmrgWpYYHhczti3CxX5XuUo6Lmy7dQBxnz0ErbNZBPuYnz5ockOsEaKCOa1enO/Uhc1b8df2HH9dRyymhLUQ922qvSC2/Zs1A1K1GvuBqg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jhD/mB4dg1QojLmluQujeZWWvBXY4wkgEEsIX3UoUEPY++emPMRjhIQ7duk7dLkwEVE1nv45lTw3QP8EBvNThQv4STl4nQg8LqYcdFCg7uHbExFCpASwn3Hyyehb8g6zWz5Vz2BfkpoNfedAhnpvPB+ysYW/hGrXUEmOHbxv4Q4= Received: by 10.151.44.18 with SMTP id w18mr1747228ybj.184.1208443925714; Thu, 17 Apr 2008 07:52:05 -0700 (PDT) Received: by 10.151.15.21 with HTTP; Thu, 17 Apr 2008 07:52:05 -0700 (PDT) Message-ID: <3c0b01820804170752x68714a6cj10919e6cb7ffda16@mail.gmail.com> Date: Thu, 17 Apr 2008 10:52:05 -0400 From: "Alexander Sack" To: "Robert Watson" In-Reply-To: <20080417152837.E71628@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3c0b01820804160929i76cc04fdy975929e2a04c0368@mail.gmail.com> <200804161456.20823.jkim@FreeBSD.org> <3c0b01820804161328m77704ca0g43077a9718d446d4@mail.gmail.com> <200804161654.22452.jkim@FreeBSD.org> <3c0b01820804161402u3aac4425n41172294ad33a667@mail.gmail.com> <20080417112329.G47027@delplex.bde.org> <3c0b01820804170643w6b771ce9jdfc2dc5b240922b@mail.gmail.com> <20080417145652.J71628@fledge.watson.org> <3c0b01820804170705l9c196d9rff45fa4919ace8c@mail.gmail.com> <20080417152837.E71628@fledge.watson.org> Cc: freebsd-net@freebsd.org, Dieter , Jung-uk Kim Subject: Re: bge dropping packets 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: Thu, 17 Apr 2008 14:52:13 -0000 On Thu, Apr 17, 2008 at 10:31 AM, Robert Watson wrote: > > On Thu, 17 Apr 2008, Alexander Sack wrote: > > > > Robert, alright, this all makes sense. So it seems to me that the first > step to salvation in my world is to turn off DEVICE_POLLING and rely on the > interrupt coalescing that exists on the card. My only concern if this does > work is what impact this has on the overall system. > > > > I would generally discourage use of our current DEVICE_POLLING code using > modern network devices, as the polling rate as compared to buffer size has > changed significantly, meaning that polling rates have to be set > ridiculously high. Also, I suspect strongly that it interacts badly with > our ithread/scheduling/etc parts, which might lead to difficult to diagnose > problems. Interrupt moderation is not as featureful as DEVICE_POLLING, but > it is better supported; I'd like to see further work done to allow us to > pick up some of the scheduling features for ithreads as well in the future. Gotcha, this is really good to know. FreeBSD is a new OS for me to work on but I'm learning so much everyday! I believe Solaris uses ithreads natively and I do know there are some drivers that forcefully create kernel threads to handle interrupts as way to scale (I have no idea the ramification of this on FreeBSD or if the overhead of creating a new kthread outweighs the benefits). Going to go turn off DEVICE_POLLING and see what happens... -aps From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 15:11:58 2008 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 F28DA106566C; Thu, 17 Apr 2008 15:11:58 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id A8AB58FC0C; Thu, 17 Apr 2008 15:11:58 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 36C1846C14; Thu, 17 Apr 2008 11:11:57 -0400 (EDT) Date: Thu, 17 Apr 2008 16:11:57 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexander Sack In-Reply-To: <3c0b01820804170752x68714a6cj10919e6cb7ffda16@mail.gmail.com> Message-ID: <20080417160922.X77343@fledge.watson.org> References: <3c0b01820804160929i76cc04fdy975929e2a04c0368@mail.gmail.com> <200804161456.20823.jkim@FreeBSD.org> <3c0b01820804161328m77704ca0g43077a9718d446d4@mail.gmail.com> <200804161654.22452.jkim@FreeBSD.org> <3c0b01820804161402u3aac4425n41172294ad33a667@mail.gmail.com> <20080417112329.G47027@delplex.bde.org> <3c0b01820804170643w6b771ce9jdfc2dc5b240922b@mail.gmail.com> <20080417145652.J71628@fledge.watson.org> <3c0b01820804170705l9c196d9rff45fa4919ace8c@mail.gmail.com> <20080417152837.E71628@fledge.watson.org> <3c0b01820804170752x68714a6cj10919e6cb7ffda16@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Dieter , Jung-uk Kim Subject: Re: bge dropping packets 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: Thu, 17 Apr 2008 15:11:59 -0000 On Thu, 17 Apr 2008, Alexander Sack wrote: > Gotcha, this is really good to know. FreeBSD is a new OS for me to work on > but I'm learning so much everyday! I believe Solaris uses ithreads natively > and I do know there are some drivers that forcefully create kernel threads > to handle interrupts as way to scale (I have no idea the ramification of > this on FreeBSD or if the overhead of creating a new kthread outweighs the > benefits). This is also true on FreeBSD -- on the whole, drivers up to 1gbps create one ithread per device (typically interface), but our 10gbps drivers [increasingly] instantiate multiple ithreads and direct traffic to multiple CPUs using different MSIX interrupts. So for 1gbps forwarding or bridging with if_em, we'll run the code in two ithreads. We direct dispatch our network stack by default in 7.x, meaning that we run everything up to local socket delivery in the ithread. If you're doing multi-interface forwarding, you might experiment with setting net.isr.direct=0 (via sysctl) to see how that affects performance -- this pushes network layer (and higher) processing to a separate netisr thread. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 15:48:54 2008 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 5473F1065674; Thu, 17 Apr 2008 15:48:54 +0000 (UTC) (envelope-from 4pr@legis.krsn.ru) Received: from legis.krsn.ru (legis.krsn.ru [217.74.160.149]) by mx1.freebsd.org (Postfix) with ESMTP id 956DE8FC1C; Thu, 17 Apr 2008 15:48:52 +0000 (UTC) (envelope-from 4pr@legis.krsn.ru) Received: from lawdb.legis.krsn.ru (lawdb.legis.krsn.ru [192.168.104.14]) by legis.krsn.ru (8.13.6/8.13.6) with ESMTP id m3HFNL11015603; Thu, 17 Apr 2008 23:23:22 +0800 (KRAST) (envelope-from 4pr@legis.krsn.ru) In-Reply-To: <200804170855.m3H8twoK094070@freefall.freebsd.org> To: bms@FreeBSD.org, freebsd-net@FreeBSD.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: 4pr@legis.krsn.ru Date: Thu, 17 Apr 2008 23:17:49 +0800 X-MIMETrack: Serialize by Router on lawdb/law/ru(Release 7.0.2|September 26, 2006) at 17.04.2008 11:17:50 PM, Serialize complete at 17.04.2008 11:17:50 PM Content-Type: text/plain; charset="US-ASCII" X-Kaspersky-Checking: Passed Cc: Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem 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 Apr 2008 15:48:54 -0000 Thank you very mach for your response! Yes, as i wrote before, if mrouted daemon, or pimdd daemon is running, then ALLMULTI flag appears on all interfaces (i can see it from ifconfig output). But multicast routing do not work. I have a machine with an old FreeBSD4.9 running, wich working as a router/multicast router with Intel gigabit desktop pci adapters (em) installed. That old installation do not have any problems with multicast routing role. So for testing i have installed completly equal to that old ones cards to my new installation of FreeBSD7.0 instead of new Intel's pcix server adapters (they also uses driver em) which i tryed to use before. And resault was absolutely the same. Mrouting do not work, until promiscious mode will be enabled (by mtest or tcpdump). So i fink, it is not a firmware bug, as card working correctly with 4.9 release. I desided to try to use that hardware with FreeBSD 6.3 installed into another hard drive with GENERIC kernel and ip_mroute loaded after boot time. And resault still the same. On 6.3 branch i have same problem. Is it possible, what on different drivers like "em" and "msk" existing the same bug, wich cousing them do not work with multicast routing code correctly? More infromation about problem, if it might help: then on receiveng machine on vlc player (adjasted to receive multicast from 239.0.2.1) i pressing PLAY button, mrouted -d do not show anything about that event. Then i pressing the STOP button i see on debug: 19:13:48.138 RECV V2 member report from 192.168.102.2 to 239.0.2.1 But, if promiscious mode enabled, then i pressing PLAY button on receiver i see: 19:13:48.138 RECV V2 member report from 192.168.102.2 to 239.0.2.1 19:13:48.138 group 239.0.2.1 joined on vif 1 19:13:48.138 update lclgrp (192.168.101/24 239.0.2.1) gm:2 19:13:48.270 RECV V2 member report from 192.168.102.2 to 239.0.2.1 19:13:52.344 aging forwarding cache entries and pressin the STOP buttong gives more debug print, then without promiscious mode enabled. So i'm shure, there was a lot code changing in em driver since 4.9, and somethng might be occasionally broken in the code. Please, cold you help me with contacting Pyun YongHyeon and/or Jack Vogel? Or where i can find theyr email addresses? Tommorow i will try another cards, like rtl8139 10/100 or similar for testing. Thank you again. From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 17:48:28 2008 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 A98FC106564A for ; Thu, 17 Apr 2008 17:48:28 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outP.internet-mail-service.net (outp.internet-mail-service.net [216.240.47.239]) by mx1.freebsd.org (Postfix) with ESMTP id 993E48FC0A for ; Thu, 17 Apr 2008 17:48:28 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Thu, 17 Apr 2008 21:52:31 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id D9F982D6011; Thu, 17 Apr 2008 10:48:27 -0700 (PDT) Message-ID: <48078D71.403@elischer.org> Date: Thu, 17 Apr 2008 10:48:33 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <4806BA59.4030106@elischer.org> <4806E468.5030906@yandex.ru> In-Reply-To: <4806E468.5030906@yandex.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , ipfw@freebsd.org, Luigi Rizzo Subject: Re: addition to ipfw table.. 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 Apr 2008 17:48:28 -0000 Andrey V. Elsukov wrote: > Julian Elischer wrote: >> I do know it won't handle non contiguous masks well but as the >> ipfw ABI code only accepts a network mask length instead of a >> mask, there's not much that can be done. >> I may suggest a later fix for that but it will break the ABI. >> >> comments? > > What you think about my patch? > I like it.. :-) I didn't know about contigmask() From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 01:13:45 2008 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 1C836106566B; Fri, 18 Apr 2008 01:13:45 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id 8F1128FC0C; Fri, 18 Apr 2008 01:13:44 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c220-239-252-11.carlnfd3.nsw.optusnet.com.au (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m3I1DdEu011849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Apr 2008 11:13:40 +1000 Date: Fri, 18 Apr 2008 11:13:39 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Alexander Sack In-Reply-To: <3c0b01820804170643w6b771ce9jdfc2dc5b240922b@mail.gmail.com> Message-ID: <20080418093328.B50187@delplex.bde.org> References: <3c0b01820804160929i76cc04fdy975929e2a04c0368@mail.gmail.com> <200804161456.20823.jkim@FreeBSD.org> <3c0b01820804161328m77704ca0g43077a9718d446d4@mail.gmail.com> <200804161654.22452.jkim@FreeBSD.org> <3c0b01820804161402u3aac4425n41172294ad33a667@mail.gmail.com> <20080417112329.G47027@delplex.bde.org> <3c0b01820804170643w6b771ce9jdfc2dc5b240922b@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Dieter , Jung-uk Kim Subject: Re: bge dropping packets 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: Fri, 18 Apr 2008 01:13:45 -0000 On Thu, 17 Apr 2008, Alexander Sack wrote: > On Wed, Apr 16, 2008 at 10:53 PM, Bruce Evans wrote: >> On Wed, 16 Apr 2008, Alexander Sack wrote: >[DEVICE_POLLING] > But why was it added to begin with if standard interrupt driven I/O is > faster? (was it the fact that historically hardware didn't do > interrupt coalescing initially) See Robert's reply. >>> However, my point still stands: >>> >>> #define TG3_RX_RCB_RING_SIZE(tp) ((tp->tg3_flags2 & >>> TG3_FLG2_5705_PLUS) ? 512 : 1024) >>> >>> Even the Linux driver uses higher number of RX descriptors than >>> FreeBSD's static 256. I think minimally making this tunable is a fair >>> approach. >>> >>> If not, no biggie, but I think its worth it. >> >> I use a fixed value of 512 (jkim gave a pointer to old mail containing >> a fairly up to date version of my patches for this and more important >> things). This should only make a difference with DEVICE_POLLING. > > Then minimally 512 could be used if DEVICE_POLLING is enabled and my > point still stands. Though in light of the other statistics you cited > I understand now that this may not make that big of an impact. em uses only 256 too (I misread it as using 2048). Someone reported that increasing this to 4096 reduced packet loss with polling. >> Without DEVICE_POLLING, device interrupts normally occur every 150 usec > > Is that the coal ticks value you are referring too? Sorry this is my > first time looking at this driver! Yes, the driver normally configures coal ticks as 150. This is a good default. >> or even more frequently (too frequently if the average is much lower >> than 150 usec), so 512 descriptors is more than enough for 1Gbps ethernet >> (the minimum possible inter-descriptor time for tiny packets is about 0.6 >> usec, > > How do you measure this number? 0.6 usec is the theoretical minimum. I actually measure a minumum of about 1.5 usec for my hardware (5701 PCI/X on plain PCI) by making timestamps in bge_rxeof() and bge_txeof(). (1.5 usec is the average for a ring full of descriptors.) > I'm assuming when you say "inter-descriptor time" you mean the time it > takes the card to fill a RX descriptor on receipt of a packet (really > the firmware latency?). No, it is part of the Ethernet spec (96 bit times for all speeds of Ethernet IIRC, so it is much shorter than it was for original Ethernet). At least my hardware takes significantly longer than this (1.5 - 0.6 usec = 900 nsec!). It is unclear where the extra time is spent, but presumably the hardware implements the Ethernet spec and is limited mainly by the bus speed (if the bus is plain PCI, otherwise DMA speed might be the limit), so if packets arrived every 0.6 usec then it would buffer many of them in fast device memory and then be forced to drop 9 in every 15 on average. >> For timeouts instead of device polls, at least on old systems it was >> quite common for timeouts at a frequency of HZ not actually being >> delivered, even when HZ was only 100, because some timeouts run for >> too long (several msec each, possibly combining to > 10 msec occasionally). >> Device polls are at a lower level, so they have a better chance of >> actually keeping up with HZ. Now the main source of timeouts that run >> for too long is probably mii tick routines. These won't combine, at >> least for MPSAFE drivers, but they will block both interrupts and >> device polls for their own device. So the rx ring size needs to be >> large enough to cover max(150 usec or whatever interrupt moderation time, >> mii tick time) of latency plus any other latencies due to interrupt >> handling >> or polling of for other devices. Latencies due to interrupts on other >> devices is only certain to be significant if the other devices have higher >> or the same priority. > > You described what I'm seeing. Couple this with the fact that the > driver uses one mtx for everything doesn't help. I'm pretty sure I'm > running into RX descriptor starvation despite the fact that > statistically speaking, 256 descriptors is enough for 1Gbps (I'm > talking 100MBps the firmware is dropping packets). The problem gets > worse if I add some kind of I/O workload on the system (my load > happens to be a gzip of a large log file in /tmp). I haven't found the mii tick latency to be a problem in practice, though I once suspected it. Oh, I just remembered that this requires working PREEMPTION so that lower-priority interrupt handlers like ata and sc get preempted. PREEMPTION wasn't the default and didn't work very well until relatively recently. But I think it works in 7.0. > I noticed that if I put ANY kind of debugging messages in bge_tick() > the drop gets much worse (for example just printing out the number of > dropped packets read from bge_stats_update() when a drop occurs causes > EVEN more drops to incur and if I had to guess its the printf just > uses up more cycles which delays the drain of RX chain and causes a > longer time to recover - this is a constant stream from a traffic > generator). Delays while holding the lock will cause problems of course. Hmm, bge_tick() is a callout, so it may itself be delayed or preempted. Delaying it shouldn't matter, and latency from preempting it is supposed to be handled by priority propagation: callout ithread runs calls bge_tick() acquires device mutex ... preempted by unrelated ithread ... preempted by bge ithread tries to acquire device mutex; blocks bge ithread priority is propagated to callout ithread preempted by callout ithread ... // now it is high priority; should be more careful not to take long releases device mutex; loses its propagated priority preempted by bge ithread acquires device mutex ... >> Some numbers for [1 Gbps] ethernet: >> >> minimum frame size = 64 bytes = 512 bits >> minimum inter-frame gap = 96 bits >> minimum total frame time = 608 nsec (may be off by 64) >> bge descriptors per tiny frame = 1 (1 for mbuf) >> buffering provided by 256 descriptors = 256 * 608 = 155.648 usec (marginal) > > So as I read this, its takes 155 usec to fill up the entre RX chain of > rx_bd's if its just small packets, correct? At least that long, depending on bus and DMA speeds. >> normal frame size = 1518 bytes = 12144 bits >> normal total frame time = 12240 nsec >> bge descriptors per normal frame = 2 (1 for mbuf and 1 for mbuf cluster) >> buffering provided by 256 descriptors = 256/2 * 12240 = 1556.720 usec >> (plenty) > > Is this based again on your own instrumentation based on the last > patch? (just curious, I believe you, I just wanted to know if this > was an artifact of you doing some tuning research or something else) This is a theoretical minimum too, but in practice even a PCI bus can almost keep up with 1Gbps ethernet in 1 direction, so I've measured average packet rates of > 81 kpps for normal frames (81 kpps = 12345 nsec per packet). Timestamps made in bge_rxeof() at a rate of only 62.7 kpps (since my em card can't go faster than this) look like this: %%% 97 1208479322.632804 13 0 7 1208479322.632804 6 104 1208479322.632908 11 0 6 1208479322.632908 5 105 1208479322.633013 9 1 5 1208479322.633014 4 64 1208479322.633078 10 0 4 1208479322.633078 6 95 1208479322.633173 11 1 6 1208479322.633174 5 %%% Here the columns give: 1st: time in usec between bge_rxeof() calls 4th: time in usec taken by this cal 5th: number of descriptors processed by this call other: raw timestamps and ring indexes The inter-rxeof time is ~100 usec since rx_coal_ticks is configured to 100. Thus there are only a few packets per interrupt at the "low" rate of 62.7 kpps. There are no latency problems in sight in this truncated output. This output is inconsistent with what I said above -- there is no sign of the factor of 2 for the mbuf+cluster split. I now think that that split only affects output. > So the million dollar question: Do you believe that if I disable > DEVICE_POLLING and use interrupt driven I/O, I could achieve zero > packet loss over a 1Gbps link? This is the main issue I need to solve > (solve means either no its not really achievable without a heavy > rewrite of the driver OR yes it is with some tuning). If the answer > is yes, then I have to understand the impact on the system in general. > I just want to be sure I'm on a viable path through the BGE maze! I think you can get close enough if the bus and memory and CPU(s) permit and you don't need to get too close to the theoretical limits. Bruce From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 02:02:03 2008 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 F0A6B106564A for ; Fri, 18 Apr 2008 02:02:03 +0000 (UTC) (envelope-from vijjus@rocketmail.com) Received: from web33501.mail.mud.yahoo.com (web33501.mail.mud.yahoo.com [68.142.206.150]) by mx1.freebsd.org (Postfix) with SMTP id 927588FC0C for ; Fri, 18 Apr 2008 02:02:03 +0000 (UTC) (envelope-from vijjus@rocketmail.com) Received: (qmail 95666 invoked by uid 60001); 18 Apr 2008 01:35:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rocketmail.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=VuAeeKRn4oX5bI5YqF6VEqx4kELbqNzOu1T7vzbYZhXhxUGdqD+dJTAqiiZnUbjZ3O/Xn0ieCgld1x5it4scPGDYftkOq1IL4SBLpfWKhAI05ml1Q1OVFYZw985Dy1cZTpPIoMoUpkL1Q/ho0yjDrZuZ9esbKbdy50A/BdXFKG0=; X-YMail-OSG: ItPtIScVM1kmCnNw5oxw363XlOOPPZGcRHqzHe.MUJHmU8cYkmbxiBVFrswPG.YRQGaH8V4BSMXa2MT2_ssaD2ZXMzoOV18Gq3zxA7KFFJy4Zt2Ob4MDDdfwCQ-- Received: from [198.95.226.230] by web33501.mail.mud.yahoo.com via HTTP; Thu, 17 Apr 2008 18:35:23 PDT X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.185 Date: Thu, 17 Apr 2008 18:35:23 -0700 (PDT) From: vijay singh To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <490341.95478.qm@web33501.mail.mud.yahoo.com> Subject: Regarding if_alloc() 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 Apr 2008 02:02:04 -0000 Hi all. How do we avoid a race in populating the ifindex_table? Id this is a TODO, as it seems from the code below, would it be acceptable if I wrote a patch and reused the ifnet_lock [IFNET_WLOCK, IFNET_WUNLOCK]? if_alloc(u_char type) { struct ifnet *ifp; ifp = malloc(sizeof(struct ifnet), M_IFNET, M_WAITOK|M_ZERO); /* * Try to find an empty slot below if_index. If we fail, take * the next slot. * * XXX: should be locked! */ for (ifp->if_index = 1; ifp->if_index <= if_index; ifp->if_index++) { if (ifnet_byindex(ifp->if_index) == NULL) break; } ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 04:00:05 2008 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 928A1106566C for ; Fri, 18 Apr 2008 04:00:05 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id 5F9108FC24 for ; Fri, 18 Apr 2008 04:00:05 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so544055waf.3 for ; Thu, 17 Apr 2008 21:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=PeWGwhiWyKyXsAJvDwbCComcyjua2YeIcmmYaGYjZwo=; b=htvGL+xPnOZiVQYF+XCbnyylkn1F4P7O3HH6cJ9bWHG7sG96teYfxC31/3YBFmFrMrEKYQJBLTFNGXKa38gNuMjZgsQvX2aiYr9DqeX/lCYolxQquKGtjz5Ewg1jwfSBxf+4VkAzU6DaT4tKwgyNdLQnhplZK/LsOqKeX5vaFIw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=TWwM0YZRfYuxKJR3K8yZr+WQajaJgfjK2BymEyIylM+exaFGXjVbdVD915T7/DYJaWoHTabHkzhWLwt4bBLzV+U0oWmVG13SKXVXf6hFIC6Eh5GcldKIaSpl4POHILB37qQCthRJV4fJtRU32xVeF7pErDdH7yG2PAe1e9TFdkc= Received: by 10.114.135.1 with SMTP id i1mr2227054wad.88.1208491205053; Thu, 17 Apr 2008 21:00:05 -0700 (PDT) Received: by 10.114.255.16 with HTTP; Thu, 17 Apr 2008 21:00:04 -0700 (PDT) Message-ID: Date: Thu, 17 Apr 2008 21:00:04 -0700 From: "Kip Macy" To: "freebsd-net@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: MFC of TOE support to RELENG_7 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 Apr 2008 04:00:05 -0000 I would like to MFC TOE and RDMA support in the last week of May / first week of June. My primary objective is that it be present in 7.1. The re team has not yet decided when the freeze date for 7.1 will be, so I may end up asking to do it earlier. The reason I'm bringing it up roughly 6 weeks in advance is that there is a certain amount of debate with regards to the ABI guarantees that FreeBSD network developers are willing to commit to for the remaining life of the RELENG_7 branch. I've made the following two simplifying assumptions: - struct tcpcb and struct sockbuf are append only - i.e. if members are added, they will be added to the end - lock ordering will not change, e.g. the inpcb lock will always be acquired before the sockbuf lock Is there any reason to believe that these simplifying assumptions are not acceptable? If so, why? I've added the following sets of accessor functions: - lock acquire/release for socket, sockbuf, inpcb - higher level functions for tcp shutdown and syncache to abstract away the tcbinfo lock - accessor functions for all the accessed fields in socket and inpcb so that none of the members are referenced as offsets from the base of the structure There is an open question as to whether similar abstractions should be added to the various firewalls to allow them to be similarly decoupled to ease future maintenance. I would be willing to take a little time if someone stepped forward to explain the needs of the firewalls. I still need to do the following: - document the api provided by netinet/toedev.h - provide more formal documentation for the api provided by netinet/tcp_offload.h The current state of the code can be seen at: http://157.22.130.171/svn/branches/projects/iwarp/sys/ From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 04:15:59 2008 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 7D484106566C for ; Fri, 18 Apr 2008 04:15:59 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (host-122-100-2-232.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 2E80F8FC27 for ; Fri, 18 Apr 2008 04:15:58 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id 7588B13F54; Fri, 18 Apr 2008 13:59:52 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from anzac.hos (132.169.233.220.exetel.com.au [220.233.169.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id E295713782 for ; Fri, 18 Apr 2008 13:59:46 +1000 (EST) Message-ID: <48081CB2.9000509@modulus.org> Date: Fri, 18 Apr 2008 13:59:46 +1000 From: Andrew Snow User-Agent: Thunderbird 2.0.0.0 (X11/20070426) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <3c0b01820804160929i76cc04fdy975929e2a04c0368@mail.gmail.com> <200804161456.20823.jkim@FreeBSD.org> <3c0b01820804161328m77704ca0g43077a9718d446d4@mail.gmail.com> <200804161654.22452.jkim@FreeBSD.org> <3c0b01820804161402u3aac4425n41172294ad33a667@mail.gmail.com> <20080417112329.G47027@delplex.bde.org> <3c0b01820804170643w6b771ce9jdfc2dc5b240922b@mail.gmail.com> <20080417145652.J71628@fledge.watson.org> <3c0b01820804170705l9c196d9rff45fa4919ace8c@mail.gmail.com> <20080417152837.E71628@fledge.watson.org> In-Reply-To: <20080417152837.E71628@fledge.watson.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: bge dropping packets 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: Fri, 18 Apr 2008 04:15:59 -0000 Robert Watson wrote: > I would generally discourage use of our current DEVICE_POLLING code > using modern network devices, as the polling rate as compared to buffer > size has changed significantly, meaning that polling rates have to be > set ridiculously high. I agree, from my playing around there's no point using polling on modern hardware. It uses *more* CPU time and doesn't seem to increase throughput. - Andrew From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 06:30:02 2008 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 C74561065673 for ; Fri, 18 Apr 2008 06:30:02 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from outbound0.mx.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.freebsd.org (Postfix) with ESMTP id 9FEB88FC18 for ; Fri, 18 Apr 2008 06:30:02 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.mx.meer.net (8.12.10/8.12.6) with ESMTP id m3I6U0hx096033; Thu, 17 Apr 2008 23:30:02 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m3I6TCM0095315; Thu, 17 Apr 2008 23:29:12 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (61.204.211.246.customerlink.pwd.ne.jp [61.204.211.246]) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m3I6TBwh094285; Thu, 17 Apr 2008 23:29:12 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Fri, 18 Apr 2008 15:29:10 +0900 Message-ID: From: gnn@freebsd.org To: vijay singh In-Reply-To: <490341.95478.qm@web33501.mail.mud.yahoo.com> References: <490341.95478.qm@web33501.mail.mud.yahoo.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.1.50 (i386-apple-darwin8.11.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: Regarding if_alloc() 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 Apr 2008 06:30:02 -0000 At Thu, 17 Apr 2008 18:35:23 -0700 (PDT), vijay singh wrote: > > Hi all. How do we avoid a race in populating the ifindex_table? Id > this is a TODO, as it seems from the code below, would it be > acceptable if I wrote a patch and reused the ifnet_lock > [IFNET_WLOCK, IFNET_WUNLOCK]? > It is almost always acceptable to submit a patch :-) > > if_alloc(u_char type) > { > struct ifnet *ifp; > > ifp = malloc(sizeof(struct ifnet), M_IFNET, M_WAITOK|M_ZERO); > > /* > * Try to find an empty slot below if_index. If we fail, take > * the next slot. > * > * XXX: should be locked! > */ > for (ifp->if_index = 1; ifp->if_index <= if_index; ifp->if_index++) { > if (ifnet_byindex(ifp->if_index) == NULL) > break; > } > > There are still parts of the network device infrastructure that need some locking, and it would seem that this is one of them. I know Brooks Davis was also looking at this stuff so he may comment as well. Best, George From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 06:33:07 2008 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 6C14F106564A for ; Fri, 18 Apr 2008 06:33:07 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from outbound0.mx.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.freebsd.org (Postfix) with ESMTP id 438338FC15 for ; Fri, 18 Apr 2008 06:33:07 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.mx.meer.net (8.12.10/8.12.6) with ESMTP id m3I6X0i1096077; Thu, 17 Apr 2008 23:33:07 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m3I6WVrB096162; Thu, 17 Apr 2008 23:32:31 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (61.204.211.246.customerlink.pwd.ne.jp [61.204.211.246]) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m3I6WUHi094771; Thu, 17 Apr 2008 23:32:31 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Fri, 18 Apr 2008 15:32:30 +0900 Message-ID: From: gnn@freebsd.org To: "Kip Macy" In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.1.50 (i386-apple-darwin8.11.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "freebsd-net@freebsd.org" Subject: Re: MFC of TOE support to RELENG_7 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 Apr 2008 06:33:07 -0000 At Thu, 17 Apr 2008 21:00:04 -0700, Kip Macy wrote: > > I would like to MFC TOE and RDMA support in the last week of May / > first week of June. My primary objective is that it be present in 7.1. > The re team has not yet decided when the freeze date for 7.1 will be, > so I may end up asking to do it earlier. > > The reason I'm bringing it up roughly 6 weeks in advance is that there > is a certain amount of debate with regards to the ABI guarantees that > FreeBSD network developers are willing to commit to for the remaining > life of the RELENG_7 branch. > > I've made the following two simplifying assumptions: > - struct tcpcb and struct sockbuf are append only - i.e. if members > are added, they will be added to the end > - lock ordering will not change, e.g. the inpcb lock will always be > acquired before the sockbuf lock > > Is there any reason to believe that these simplifying assumptions are > not acceptable? If so, why? > > > I've added the following sets of accessor functions: > - lock acquire/release for socket, sockbuf, inpcb > - higher level functions for tcp shutdown and syncache to abstract > away the tcbinfo lock > - accessor functions for all the accessed fields in socket and > inpcb so that none of the members are referenced as offsets from the > base of the structure I apologize for not yet reviewing all the code. I take that last bit to mean the drivers can reach up into sockets given those functions? I gather this is due to the work necessary to implement RDMA over TCP? > The current state of the code can be seen at: > http://157.22.130.171/svn/branches/projects/iwarp/sys/ Is there a simple way to get just that directory without doing a svn on your whole repo? And if not, what's the easiest way to just grab that stuff? Best, George From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 08:20:03 2008 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 8D3291065673 for ; Fri, 18 Apr 2008 08:20:03 +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 6F03B8FC22 for ; Fri, 18 Apr 2008 08:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3I8K3F8019124 for ; Fri, 18 Apr 2008 08:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3I8K3Kr019123; Fri, 18 Apr 2008 08:20:03 GMT (envelope-from gnats) Date: Fri, 18 Apr 2008 08:20:03 GMT Message-Id: <200804180820.m3I8K3Kr019123@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: 4pr@legis.krsn.ru Cc: Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: 4pr@legis.krsn.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2008 08:20:03 -0000 The following reply was made to PR kern/122839; it has been noted by GNATS. From: 4pr@legis.krsn.ru To: bug-followup@FreeBSD.org, 4pr@legis.krsn.ru Cc: Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem Date: Fri, 18 Apr 2008 15:50:02 +0800 Thank you very mach for your response! Yes, as i wrote before, if mrouted daemon, or pimdd daemon is running, then ALLMULTI flag appears on all interfaces (i can see it from ifconfig output). But multicast routing do not work. I have a machine with an old FreeBSD4.9 running, wich working as a router/multicast router with Intel gigabit desktop pci adapters (em) installed. That old installation do not have any problems with multicast routing role. So for testing i have installed completly equal to that old ones cards to my new installation of FreeBSD7.0 instead of new Intel's pcix server adapters (they also uses driver em) which i tryed to use before. And resault was absolutely the same. Mrouting do not work, until promiscious mode will be enabled (by mtest or tcpdump). So i fink, it is not a firmware bug, as card working correctly with 4.9 release. I desided to try to use that hardware with FreeBSD 6.3 installed into another hard drive with GENERIC kernel and ip_mroute loaded after boot time. And resault still the same. On 6.3 branch i have same problem. Is it possible, what on different drivers like "em" and "msk" existing the same bug, wich cousing them do not work with multicast routing code correctly? More infromation about problem, if it might help: then on receiveng machine on vlc player (adjasted to receive multicast from 239.0.2.1) i pressing PLAY button, mrouted -d do not show anything about that event. Then i pressing the STOP button i see on debug: 19:13:48.138 RECV V2 member report from 192.168.102.2 to 239.0.2.1 But, if promiscious mode enabled, then i pressing PLAY button on receiver i see: 19:13:48.138 RECV V2 member report from 192.168.102.2 to 239.0.2.1 19:13:48.138 group 239.0.2.1 joined on vif 1 19:13:48.138 update lclgrp (192.168.101/24 239.0.2.1) gm:2 19:13:48.270 RECV V2 member report from 192.168.102.2 to 239.0.2.1 19:13:52.344 aging forwarding cache entries and pressin the STOP buttong gives more debug print, then without promiscious mode enabled. So i'm shure, there was a lot code changing in em driver since 4.9, and somethng might be occasionally broken in the code. Please, cold you help me with contacting Pyun YongHyeon and/or Jack Vogel? Or where i can find theyr email addresses? Tommorow i will try another cards, like rtl8139 10/100 or similar for testing. Thank you again. From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 09:26:19 2008 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 969A3106564A for ; Fri, 18 Apr 2008 09:26:19 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 4FC458FC18 for ; Fri, 18 Apr 2008 09:26:19 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id E506CCCA0F for ; Fri, 18 Apr 2008 05:26:18 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 18 Apr 2008 05:26:18 -0400 X-Sasl-enc: skd3P3BCMd2gV40uJxVXP3PEGFP7yB9L3SD8n1oyTjZi 1208510778 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 631F0115B3 for ; Fri, 18 Apr 2008 05:26:18 -0400 (EDT) Message-ID: <48086939.1090403@incunabulum.net> Date: Fri, 18 Apr 2008 10:26:17 +0100 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.12 (X11/20080405) MIME-Version: 1.0 To: FreeBSD-Net mailing list X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Strange forwarding issue with tap(4) and if_bridge(4) 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 Apr 2008 09:26:19 -0000 Hi, I noticed a strange issue with tap(4) and if_bridge(4) where the bridge seems not to be forwarding frames. 6.3-RELEASE, btw. I have this setup where I use the two to bootstrap QEMU virtual machines. Up until now I've been using dhcpd for this. This has only ever worked right for me if I run dhcpd on the bridge interface. However I tried doing it on a second tap, and it worked OK for me. qemu -------- /dev/tap0 ---- tap0 ---------- bridge0 -------- tap1 ----- [bpf] ----- dhcpcd ------------> DHCP discovery broadcasts <------------- DHCP unicast replies OK If I run dhcpd on another tap interface, this works OK, but obviously only if I open the matching character device. dhcpd of course uses bpf for injection, not the character device. HOWEVER: If I try to run my own BOOTP server in userland, on the character device, what happens is this: If I tcpdump, I see the broadcast DHCP discover messages on the tap OK. bpf also sees the unicast replies my code generates. But if_bridge does not forward my traffic, even though the unicast addresses appear to be correct. qemu -------- /dev/tap0 ---- tap0 ---------- bridge0 -------- tap1 ----- /dev/tap1 ----- my_bootpd ------------> DHCP discovery broadcasts X <------------- BOOTP unicast replies NOT OK The BOOTP replies (written to /dev/tap1) do not appear on bridge0 or tap0. They do however appear on tap1. In the first setup, the DHCP replies appear on all interfaces in the bridge, including the bridge. What if anything could I be doing wrong? tcpdump and wireshark report that the BOOTP replies I am generating are well formed. The write semantics I use are identical to those of the QEMU client at the other end. I've ruled out pfil/firewall filters. Now, as tap1 has been added to a bridge, it is in promiscuous mode -- and because bpf shows the userland-generated frames being sent, I believe the check I added for the destination address in if_tap.c can be ruled out. The problem occurs even if I add static entries to the bridge's address cache and disable all learning. Both RSTP and STP are disabled. Thanks for any help you can provide. cheers BMS [P.S. I have noticed that in order to get frames from /dev/tapX, non-blocking reads are necessary. My code is single threaded, I use select() to block it]. From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 09:37:23 2008 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 2DC10106566C for ; Fri, 18 Apr 2008 09:37:23 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id 006228FC12 for ; Fri, 18 Apr 2008 09:37:22 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from outbound0.mx.meer.net (outbound0.mx.meer.net [209.157.153.23]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id m3I9aiLQ029666 for ; Fri, 18 Apr 2008 02:37:22 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.mx.meer.net (8.12.10/8.12.6) with ESMTP id m3I9R0i0099339 for ; Fri, 18 Apr 2008 02:27:03 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m3I9QpqY036961 for ; Fri, 18 Apr 2008 02:26:51 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (61.204.211.246.customerlink.pwd.ne.jp [61.204.211.246]) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m3I9Qpet018427 for ; Fri, 18 Apr 2008 02:26:51 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Fri, 18 Apr 2008 18:26:49 +0900 Message-ID: From: gnn@freebsd.org To: net@freebsd.org User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.1.50 (i386-apple-darwin8.11.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Bayes-Prob: 0.5 (Score 0) X-Spam-Score: 0.70 () [Tag at 5.00] COMBINED_FROM,NO_REAL_NAME X-CanItPRO-Stream: default X-Canit-Stats-ID: 135923 - c89c5d6ebf76 X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: Subject: zonelimit issues... 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 Apr 2008 09:37:23 -0000 Hi, I am wondering why this patch was never committed? http://people.freebsd.org/~delphij/misc/patch-zonelimit-workaround It does seem to address an issue I'm seeing where processes get into the zonelimit state through the use of mbufs (a high speed UDP packet receiver) but even after network pressure is reduced/removed the process never gets out of that state again. Applying the patch fixed the issue, but I'd like to have some discussion as to the general merits of the approach. Unfortunately the test that currently causes this is tied very tightly to code at work that I can't share, but I will hopefully be improving mctest to try to exhibit this behavior. Best, George From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 10:49:14 2008 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 281A5106566B; Fri, 18 Apr 2008 10:49:14 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id B33B28FC1A; Fri, 18 Apr 2008 10:49:13 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [202.108.54.204]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 2E19B2844E; Fri, 18 Apr 2008 18:49:09 +0800 (CST) Received: from localhost (tarsier.geekcn.org [202.108.54.204]) by tarsier.geekcn.org (Postfix) with ESMTP id 85CF5EC5F6F; Fri, 18 Apr 2008 18:49:08 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([202.108.54.204]) by localhost (mail.geekcn.org [202.108.54.204]) (amavisd-new, port 10024) with ESMTP id oOis-Rwq3vgh; Fri, 18 Apr 2008 18:49:01 +0800 (CST) Received: from charlie.delphij.net (c-69-181-135-56.hsd1.ca.comcast.net [69.181.135.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 10EA6EC68B7; Fri, 18 Apr 2008 18:48:58 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=UuKd9xtrPMzdHfNk9ivx69CizSmRm2I/WieSxNnw6+y6DhBZJeMZzdX1MLttsF9LP x2sDNkbl8fJK64qN679Mw== Message-ID: <48087C98.8060600@delphij.net> Date: Fri, 18 Apr 2008 03:48:56 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.12 (X11/20080312) MIME-Version: 1.0 To: gnn@freebsd.org References: In-Reply-To: X-Enigmail-Version: 0.95.6 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: zonelimit issues... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2008 10:49:14 -0000 Hi, gnn@freebsd.org wrote: > Hi, > > I am wondering why this patch was never committed? > > http://people.freebsd.org/~delphij/misc/patch-zonelimit-workaround As its name said, it's a workaround :) I thought the bug was fixed by several ways, so the old bug resurfaced? > It does seem to address an issue I'm seeing where processes get into > the zonelimit state through the use of mbufs (a high speed UDP packet > receiver) but even after network pressure is reduced/removed the > process never gets out of that state again. Applying the patch fixed > the issue, but I'd like to have some discussion as to the general > merits of the approach. > > Unfortunately the test that currently causes this is tied very tightly > to code at work that I can't share, but I will hopefully be improving > mctest to try to exhibit this behavior. > > Best, > George > _______________________________________________ > 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" -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 11:06:26 2008 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 4CD72106564A for ; Fri, 18 Apr 2008 11:06:26 +0000 (UTC) (envelope-from pierre-gilles@netaktiv.com) Received: from kosmos.netaktiv.com (kosmos.netaktiv.com [80.67.162.5]) by mx1.freebsd.org (Postfix) with ESMTP id 0FC208FC25 for ; Fri, 18 Apr 2008 11:06:26 +0000 (UTC) (envelope-from pierre-gilles@netaktiv.com) Received: from 137-168-192.priv.absolight.net (gw.in.absolight.net [79.143.241.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kosmos.netaktiv.com (Postfix) with ESMTP id 268B42BF4FD3 for ; Fri, 18 Apr 2008 12:49:16 +0200 (CEST) From: Pierre-Gilles Mialon Organization: NetAktiv To: freebsd-net@freebsd.org Date: Fri, 18 Apr 2008 12:49:16 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200804181249.16364.pierre-gilles@netaktiv.com> Subject: Looking for a bgp stressing tool 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 Apr 2008 11:06:26 -0000 Hi, We are currently trying to migrate our AS from Linux/quagga to NanoBSD/openbgpd. We want to validate our model. Please find below the test platform we use: __________ __________ __________ | | | | | | | router A | | router B | | router C | |__________| |__________| |__________| \ | / \ | / ___\___________|_________/__ | | | router Nanobsd Test | |____________________________| =2D routers A, B and C got one third of the internet routes each (82Kroutes= ). =2D routers A, B and C announce those routes to the nanobsd running an openbgpd We want to stress the nanobsd router to see how many packets/s it could=20 treat, in a quite true real situation. So we are looking for a tool that inject and verify packet with faked IPs. We want to generate fake traffic between A-B A-C B-C in both direction= s. The aim is to evaluate the routing capacity of openbgpd/freebsd. We currently didn't find any tool that fit our needs. Do you have any suggestion ? Thanks, =2D-=20 Pierre-Gilles Mialon Responsable d'exploitation syst=E8me et r=E9seau pierre-gilles@netaktiv.com +33.1 58 18 37 66 From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 11:13:10 2008 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 B85331065673 for ; Fri, 18 Apr 2008 11:13:10 +0000 (UTC) (envelope-from if@xip.at) Received: from chile.gbit.at (ns1.xip.at [193.239.188.99]) by mx1.freebsd.org (Postfix) with ESMTP id 031E18FC23 for ; Fri, 18 Apr 2008 11:13:09 +0000 (UTC) (envelope-from if@xip.at) Received: (qmail 15424 invoked from network); 18 Apr 2008 13:13:07 +0200 Received: from unknown (HELO filebunker.xip.at) (86.59.10.180) by chile.gbit.at with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Apr 2008 13:13:07 +0200 Date: Fri, 18 Apr 2008 13:13:07 +0200 (CEST) From: Ingo Flaschberger To: Pierre-Gilles Mialon In-Reply-To: <200804181249.16364.pierre-gilles@netaktiv.com> Message-ID: References: <200804181249.16364.pierre-gilles@netaktiv.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Looking for a bgp stressing tool 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 Apr 2008 11:13:10 -0000 Dear Pierre, > We are currently trying to migrate our AS from Linux/quagga to > NanoBSD/openbgpd. > > We want to validate our model. Please find below the test platform we use: > > __________ __________ __________ > | | | | | | > | router A | | router B | | router C | > |__________| |__________| |__________| > \ | / > \ | / > ___\___________|_________/__ > | | > | router Nanobsd Test | > |____________________________| > > - routers A, B and C got one third of the internet routes each (82Kroutes). > - routers A, B and C announce those routes to the nanobsd running an > openbgpd > > We want to stress the nanobsd router to see how many packets/s it could > treat, in a quite true real situation. > > So we are looking for a tool that inject and verify packet with faked > IPs. We want to generate fake traffic between A-B A-C B-C in both directions. > The aim is to evaluate the routing capacity of openbgpd/freebsd. > > We currently didn't find any tool that fit our needs. Do you have any > suggestion ? sbgp you can script this bgp listener/sender. is hard to find, as it was in the mrtd router package, which is "dead" now. http://www.filewatcher.com/m/mrtd-2.2.2a.tgz.871976.0.0.html Kind regards, Ingo Flaschberger From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 11:23:06 2008 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 292251065675 for ; Fri, 18 Apr 2008 11:23:06 +0000 (UTC) (envelope-from vincent@netaktiv.com) Received: from kosmos.netaktiv.com (kosmos.netaktiv.com [80.67.162.5]) by mx1.freebsd.org (Postfix) with ESMTP id DDBAB8FC18 for ; Fri, 18 Apr 2008 11:23:05 +0000 (UTC) (envelope-from vincent@netaktiv.com) Received: from spyker.lan (nor75-19-82-244-48-103.fbx.proxad.net [82.244.48.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kosmos.netaktiv.com (Postfix) with ESMTP id AD5D12BF5215; Fri, 18 Apr 2008 12:51:32 +0200 (CEST) From: Vincent Mialon To: FreeBSD-Net mailing list Date: Fri, 18 Apr 2008 12:51:10 +0200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart10076520.MPAa217ayW"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200804181251.26531.vincent@netaktiv.com> Cc: tech@gitoyen.net Subject: Question about ip accounting X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vincent@netaktiv.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2008 11:23:06 -0000 --nextPart10076520.MPAa217ayW Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello=20 I'm in a six months placement at Gitoyen http://www.gitoyen.net/ (a small=20 opensource-based LIR) Gitoyen is a Local Internet Registry. The current routing solution is=20 based on Linux with Quagga running OSPF and BGP. All routers runs=20 Linux from USB flash drives but we think that FreeBSD could be much better= =20 with OpenOSPFD and OpenBGPD. My mission at Gitoyen is to be able to route=20 about 2Gbps at 190 kilo packets per second using opensource softwares... Can you give me some advices on IP accounting? It must be lightweight to le= t=20 openbgpd working fluently. If informations could be retrieved by snmp it=20 would be great too. I found two ways of doing this: using pf or netgraph (particularly the port= s=20 ipaccounting_ng) so the questions are:=20 =2D Is there a best way to do this?=20 =2D Wich solution is the "lightest" for a router?=20 =2D Is there a other ways to do IP accounting? =20 Thanks for your help, Regards, Vincent Mialon --nextPart10076520.MPAa217ayW Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBICH0uGsB379GwXzsRAu/oAJ4rMl10JymbH1sIIulbpGb6sG7csQCfcB6v wgUHlFOQC1M4yhYmcKbZFoo= =miZx -----END PGP SIGNATURE----- --nextPart10076520.MPAa217ayW-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 12:43:33 2008 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 681801065715 for ; Fri, 18 Apr 2008 12:43:33 +0000 (UTC) (envelope-from chris@arnold.se) Received: from mailstore.infotropic.com (mailstore.infotropic.com [213.136.34.3]) by mx1.freebsd.org (Postfix) with ESMTP id 702A88FC19 for ; Fri, 18 Apr 2008 12:43:32 +0000 (UTC) (envelope-from chris@arnold.se) Received: (qmail 16551 invoked by uid 89); 18 Apr 2008 12:43:31 -0000 Received: by simscan 1.2.0 ppid: 16545, pid: 16548, t: 0.1538s scanners: attach: 1.2.0 clamav: 0.90/m:42 Received: from unknown (HELO ?192.168.123.123?) (chris@arnold.se@212.71.168.45) by mailstore.infotropic.com with ESMTPA; 18 Apr 2008 12:43:30 -0000 Date: Fri, 18 Apr 2008 14:43:29 +0200 (CEST) From: Christopher Arnold X-X-Sender: chris@localhost To: Vincent Mialon In-Reply-To: <200804181251.26531.vincent@netaktiv.com> Message-ID: <20080418143743.B79716@localhost> References: <200804181251.26531.vincent@netaktiv.com> X-message-flag: =?ISO-8859-1?Q?Outlook_isn=B4t_compliant_with_current_standards?= =?ISO-8859-1?Q?_please_install_another_mail_client!?= MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD-Net mailing list , tech@gitoyen.net Subject: Re: Question about ip accounting 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 Apr 2008 12:43:33 -0000 On Fri, 18 Apr 2008, Vincent Mialon wrote: > I'm in a six months placement at Gitoyen http://www.gitoyen.net/ (a small > opensource-based LIR) > > Gitoyen is a Local Internet Registry. The current routing solution is > based on Linux with Quagga running OSPF and BGP. All routers runs > Linux from USB flash drives but we think that FreeBSD could be much better > with OpenOSPFD and OpenBGPD. My mission at Gitoyen is to be able to route > about 2Gbps at 190 kilo packets per second using opensource softwares... > First of all Quagga, OpenOSPFD and OpenBGPD only handles routing information. Packet forwarding is done in the OS. (But if you have lots of routing updates the routing software could matter) A way to higher performance under linux could be: http://yuba.stanford.edu/NetFPGA/ Anyone looing at supporting the netfpga card on FreeBSD? I would love to do that project myself, my time is scarse right now. /Chris -- http://www.arnold.se/ http://www.mbit.us/ From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 13:05:25 2008 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 243BB106566B for ; Fri, 18 Apr 2008 13:05:25 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id EB4418FC21 for ; Fri, 18 Apr 2008 13:05:24 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 057881005F0; Fri, 18 Apr 2008 09:05:23 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 18 Apr 2008 09:05:22 -0400 X-Sasl-enc: bPT1QbmhxAxaJWF5GSM14SENyNCkqu6mDW48kv8NnFIk 1208523922 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 10C1E1B872; Fri, 18 Apr 2008 09:05:21 -0400 (EDT) Message-ID: <48089C91.8030607@FreeBSD.org> Date: Fri, 18 Apr 2008 14:05:21 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.12 (X11/20080405) MIME-Version: 1.0 To: Christopher Arnold References: <200804181251.26531.vincent@netaktiv.com> <20080418143743.B79716@localhost> In-Reply-To: <20080418143743.B79716@localhost> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Vincent Mialon , FreeBSD-Net mailing list , tech@gitoyen.net Subject: Re: Question about ip accounting 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 Apr 2008 13:05:25 -0000 Christopher Arnold wrote: > Anyone looing at supporting the netfpga card on FreeBSD? > I would love to do that project myself, my time is scarse right now. I believe there was some interaction between other XORP members and the NetFPGA people, although I don't know if this resulted in any outcome. cheers BMS From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 13:07:09 2008 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 DEB1F1065672 for ; Fri, 18 Apr 2008 13:07:09 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id B0E348FC0C for ; Fri, 18 Apr 2008 13:07:09 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 5FC4E10073D; Fri, 18 Apr 2008 09:07:09 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 18 Apr 2008 09:07:09 -0400 X-Sasl-enc: sylQ3va7hFvXn6JHY3aq2RLXWEjbg30+iz9aNuG7iDh5 1208524029 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id C9A0927CE7; Fri, 18 Apr 2008 09:07:08 -0400 (EDT) Message-ID: <48089CFB.5080105@FreeBSD.org> Date: Fri, 18 Apr 2008 14:07:07 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.12 (X11/20080405) MIME-Version: 1.0 To: Ingo Flaschberger References: <200804181249.16364.pierre-gilles@netaktiv.com> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Pierre-Gilles Mialon Subject: Re: Looking for a bgp stressing tool 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 Apr 2008 13:07:09 -0000 Ingo Flaschberger wrote: >> >> So we are looking for a tool that inject and verify packet with faked >> IPs. We want to generate fake traffic between A-B A-C B-C in both >> directions. >> The aim is to evaluate the routing capacity of openbgpd/freebsd. >> >> We currently didn't find any tool that fit our needs. Do you have any >> suggestion ? > > sbgp > > you can script this bgp listener/sender. > > is hard to find, as it was in the mrtd router package, which is "dead" > now. > http://www.filewatcher.com/m/mrtd-2.2.2a.tgz.871976.0.0.html The regression test framework in XORP is driven by a set of Python scripts, I believe it is fully scriptable. It might also be worthwhile adding BGP message support to PCS: http://pcs.sourceforge.net/ I have a lot of patches to go into PCS, gnn@ is pretty busy right now. cheers BMS From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 13:25:47 2008 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 56FF0106564A for ; Fri, 18 Apr 2008 13:25:47 +0000 (UTC) (envelope-from iaccounts@ibctech.ca) Received: from pearl.ibctech.ca (pearl.ibctech.ca [208.70.104.210]) by mx1.freebsd.org (Postfix) with ESMTP id DCF018FC0A for ; Fri, 18 Apr 2008 13:25:46 +0000 (UTC) (envelope-from iaccounts@ibctech.ca) Received: (qmail 8784 invoked by uid 1002); 18 Apr 2008 13:25:42 -0000 Received: from iaccounts@ibctech.ca by pearl.ibctech.ca by uid 89 with qmail-scanner-1.22 (spamassassin: 2.64. Clear:RC:1(208.70.104.100):. Processed in 0.129558 secs); 18 Apr 2008 13:25:42 -0000 Received: from unknown (HELO ?192.168.30.110?) (steve@ibctech.ca@208.70.104.100) by pearl.ibctech.ca with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Apr 2008 13:25:41 -0000 Message-ID: <4808A15E.4030007@ibctech.ca> Date: Fri, 18 Apr 2008 09:25:50 -0400 From: Steve Bertrand User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: IPIP tunnel behind NAT 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 Apr 2008 13:25:47 -0000 Hi everyone, I'm trying to configure a GIF IPIP tunnel from a FreeBSD box to a Cisco router in order to route IPv6 blocks to a remote location. However, I can't find good documentation to find out whether this will work in behind a NAT device. The FreeBSD box has a private IP, NAT'd 1:1. The Cisco is across the 'net and is in the public network. Will this tunnel setup work? If so, how? Will I have to move the FreeBSD box outside of NAT and give it a public IP? Regards, Steve From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 13:52:48 2008 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 18F59106564A for ; Fri, 18 Apr 2008 13:52:48 +0000 (UTC) (envelope-from baldur@foo.is) Received: from gremlin.foo.is (gremlin.foo.is [194.105.250.10]) by mx1.freebsd.org (Postfix) with ESMTP id C559C8FC23 for ; Fri, 18 Apr 2008 13:52:47 +0000 (UTC) (envelope-from baldur@foo.is) Received: from 127.0.0.1 (localhost.foo.is [127.0.0.1]) by injector.foo.is (Postfix) with SMTP id A8AEDDA87B; Fri, 18 Apr 2008 13:34:20 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on gremlin.foo.is X-Spam-Level: X-Spam-Status: No, score=-2.6 required=6.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.1.7 Received: by gremlin.foo.is (Postfix, from userid 1000) id 7C939DA870; Fri, 18 Apr 2008 13:34:17 +0000 (GMT) Date: Fri, 18 Apr 2008 13:34:17 +0000 From: Baldur Gislason To: Steve Bertrand Message-ID: <20080418133417.GA66873@gremlin.foo.is> References: <4808A15E.4030007@ibctech.ca> In-Reply-To: <4808A15E.4030007@ibctech.ca> User-Agent: Mutt/1.4.2.2i X-Sanitizer: Foo MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Cc: freebsd-net@freebsd.org Subject: Re: IPIP tunnel behind NAT 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 Apr 2008 13:52:48 -0000 It'll work fine. I've done this several times before. However I've also had NAT implementations which didn't work this way but this one should definitely work. Baldur On Fri, Apr 18, 2008 at 09:25:50AM -0400, Steve Bertrand wrote: > Hi everyone, > > I'm trying to configure a GIF IPIP tunnel from a FreeBSD box to a Cisco > router in order to route IPv6 blocks to a remote location. > > However, I can't find good documentation to find out whether this will > work in behind a NAT device. > > The FreeBSD box has a private IP, NAT'd 1:1. The Cisco is across the > 'net and is in the public network. > > Will this tunnel setup work? If so, how? Will I have to move the FreeBSD > box outside of NAT and give it a public IP? > > Regards, > > Steve > _______________________________________________ > 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 Fri Apr 18 14:31:06 2008 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 5B6591065670; Fri, 18 Apr 2008 14:31:06 +0000 (UTC) (envelope-from eagletree@hughes.net) Received: from n126.sc0.he.tucows.com (smtpout1118.sc0.he.tucows.com [64.97.144.118]) by mx1.freebsd.org (Postfix) with ESMTP id 2D0A98FC0A; Fri, 18 Apr 2008 14:31:05 +0000 (UTC) (envelope-from eagletree@hughes.net) Received: from sc0-out01.emaildefenseservice.com (64.97.131.2) by n126.sc0.he.tucows.com (7.2.069.1) id 47AEF770009DEC85; Fri, 18 Apr 2008 13:51:15 +0000 X-SpamScore: 30 X-Spamcatcher-Summary: 30, 2, 0, 3e8ef5f7e79ed58e, fe71ce1fe1bfd227, eagletree@hughes.net, -, RULES_HIT:82:355:379:541:564:599:601:945:966:967:973:982:988:989:1260:1261:1277:1311:1313:1314:1345:1358:1359:1437:1515:1516:1518:1534:1541:1593:1594:1711:1730:1747:1766:1792:2196:2198:2199:2200:2234:2393:2525:2553:2559:2563:2682:2685:2857:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3353:3622:3636:3865:3866:3867:3868:3869:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:4184:4250: 4362:4385:5007:6119:7652:7679:7882:7903:7974, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none, TSO:0 X-Spamcatcher-Explanation: (100%) URL: HTTP is broken; Received: from [192.168.0.3] (dpc6744118153.direcpc.com [67.44.118.153]) (Authenticated sender: eagletree@hughes.net) by sc0-out01.emaildefenseservice.com (Postfix) with ESMTP; Fri, 18 Apr 2008 13:51:06 +0000 (UTC) In-Reply-To: <48087C98.8060600@delphij.net> References: <48087C98.8060600@delphij.net> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <382258DB-13B8-4108-B8F4-157F247A7E4B@hughes.net> Content-Transfer-Encoding: 7bit From: Chris Pratt Date: Fri, 18 Apr 2008 06:40:26 -0700 To: d@delphij.net, net@freebsd.org X-Mailer: Apple Mail (2.753) Cc: gnn@freebsd.org Subject: Re: zonelimit issues... 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 Apr 2008 14:31:06 -0000 On Apr 18, 2008, at 3:48 AM, Xin LI wrote: > Hi, > > gnn@freebsd.org wrote: >> Hi, >> I am wondering why this patch was never committed? http:// >> people.freebsd.org/~delphij/misc/patch-zonelimit-workaround > > As its name said, it's a workaround :) > > I thought the bug was fixed by several ways, so the old bug > resurfaced? > >> I am very interested in this topic as I've been waiting since moving from FreeBSD 5 in 2006. The workaround in the errata had no effect and the only notice I could see of something changing was the errata did not include the problem as of FreeBSD 7.0. I stayed with production releases and source upgraded hoping a fix would be coming but stopped that at 6.2 when I saw no related changes (re: your messages in 12/2006 - 02/2007). I was planning to move to 7.0 based on the lack of the error description in the 7.0 errata. If no patch has been made, I'd prefer to keep an otherwise stable system status quo. I guess now I'd really like to know if this has been fixed or not. I've been tied to my monitor for near two years now because of one system that seems to exhibit the problem regardless of what hardware we put in the role. Without a dump I've never been able to say that THIS problem is MY problem but the earmarks are there and I've just been waiting. Doesn't 7.0 fix this? I'd like to see an official definitive answer and all I've been going on is that the problem description is no longer in the errata. Thanks From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 15:28:16 2008 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 525051065673 for ; Fri, 18 Apr 2008 15:28:16 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id BF73F8FC2B for ; Fri, 18 Apr 2008 15:28:15 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.2/8.14.2) with ESMTP id m3IFSRw0020675; Fri, 18 Apr 2008 10:28:27 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.2/8.14.2/Submit) id m3IFSRGc020674; Fri, 18 Apr 2008 10:28:27 -0500 (CDT) (envelope-from brooks) Date: Fri, 18 Apr 2008 10:28:27 -0500 From: Brooks Davis To: vijay singh Message-ID: <20080418152827.GA20382@lor.one-eyed-alien.net> References: <490341.95478.qm@web33501.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline In-Reply-To: <490341.95478.qm@web33501.mail.mud.yahoo.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Fri, 18 Apr 2008 10:28:27 -0500 (CDT) Cc: freebsd-net@freebsd.org Subject: Re: Regarding if_alloc() 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 Apr 2008 15:28:16 -0000 --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 17, 2008 at 06:35:23PM -0700, vijay singh wrote: > Hi all. How do we avoid a race in populating the ifindex_table? Id > this is a TODO, as it seems from the code below, would it be > acceptable if I wrote a patch and reused the ifnet_lock [IFNET_WLOCK, > IFNET_WUNLOCK]? Locking if_index management with ifnet_lock should be ok. Ideally we should probably be using ALLOC_UNR(9) to manage if_indexes instead of this rather expensive loop. Be aware, that if_index generation is least of the issues in this area. The if_grow() call is much riskier since it changes the value of the global ifnet pointer which I'm not sure we can afford to lock. It would be worth experimenting with rmlocks to see what the impact if of locking would be. I'm serious tempted to kill if_grow in favor of some sort of if_index_max tunable. -- Brooks > if_alloc(u_char type) > { > struct ifnet *ifp; >=20 > ifp =3D malloc(sizeof(struct ifnet), M_IFNET, M_WAITOK|M_ZERO); >=20 > /* > * Try to find an empty slot below if_index. If we fail, take > * the next slot. > * > * XXX: should be locked! > */ > for (ifp->if_index =3D 1; ifp->if_index <=3D if_index; ifp->if_index+= +) { > if (ifnet_byindex(ifp->if_index) =3D=3D NULL) > break; > } >=20 >=20 >=20 >=20 >=20 > ___________________________________________________________________= _________________ > Be a better friend, newshound, and=20 > know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_y= lt=3DAhu06i62sR8HDtDypao8Wcj9tAcJ > _______________________________________________ > 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" >=20 --envbJBWh7q8WU6mo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iD8DBQFICL4aXY6L6fI4GtQRArdsAKCPMDjyxiOsKdTuJOpMJD2t1AsQaQCgxk9v 65KCmQDqs7a6H3HNpmdEdEQ= =nkAN -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 17:40:29 2008 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 D52CA106566B for ; Fri, 18 Apr 2008 17:40:29 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outK.internet-mail-service.net (outk.internet-mail-service.net [216.240.47.234]) by mx1.freebsd.org (Postfix) with ESMTP id BB4DD8FC21 for ; Fri, 18 Apr 2008 17:40:29 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Fri, 18 Apr 2008 21:46:09 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 2AD092D6021; Fri, 18 Apr 2008 10:40:29 -0700 (PDT) Message-ID: <4808DD13.9040503@elischer.org> Date: Fri, 18 Apr 2008 10:40:35 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Christopher Arnold References: <200804181251.26531.vincent@netaktiv.com> <20080418143743.B79716@localhost> In-Reply-To: <20080418143743.B79716@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Vincent Mialon , FreeBSD-Net mailing list , tech@gitoyen.net Subject: Re: Question about ip accounting 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 Apr 2008 17:40:29 -0000 Christopher Arnold wrote: > > > On Fri, 18 Apr 2008, Vincent Mialon wrote: > >> I'm in a six months placement at Gitoyen http://www.gitoyen.net/ (a small >> opensource-based LIR) >> > >> Gitoyen is a Local Internet Registry. The current routing solution is >> based on Linux with Quagga running OSPF and BGP. All routers runs >> Linux from USB flash drives but we think that FreeBSD could be much >> better >> with OpenOSPFD and OpenBGPD. My mission at Gitoyen is to be able to route >> about 2Gbps at 190 kilo packets per second using opensource softwares... >> > First of all Quagga, OpenOSPFD and OpenBGPD only handles routing > information. Packet forwarding is done in the OS. (But if you have lots > of routing updates the routing software could matter) > A way to higher performance under linux could be: > http://yuba.stanford.edu/NetFPGA/ > > Anyone looing at supporting the netfpga card on FreeBSD? > I would love to do that project myself, my time is scarse right now. It's on my "sometime" list.. BTW people ha ve been having trouble getting the expected throughput with those cards in some systems according to teh mailing lists so there are some traps for young players in there.. > > /Chris > > -- > http://www.arnold.se/ > http://www.mbit.us/ > _______________________________________________ > 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 Fri Apr 18 17:56:15 2008 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 4F9511065672 for ; Fri, 18 Apr 2008 17:56:15 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 008F98FC20 for ; Fri, 18 Apr 2008 17:56:14 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by yw-out-2324.google.com with SMTP id 2so402268ywt.13 for ; Fri, 18 Apr 2008 10:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=2mHl8zAA6IZdpeqeGSmWJqU9QSNHMuX+tbmnnmg4WHE=; b=ghHgf+iZoRTrPLmqdlddfh2zyS2EcYYfiqowqaTIkWzH9bjC4y5LOsruMurvhwy65z4xFgovFBlV+/ShuC7r9ExeIQzoGWhHjdCaIAORcsImzmNADAhiyEjXJSYGc0etaSD0JOrZabgpXAkkY2oheWkQQRcqkzdYridtwB0OxLY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KHaQpGwkWe3mBNKTNsYfJJ6W/ptPh4PRbb280Zhou8kqBBPALSe8Bhcjd6HrXbbW8dHoHWn58YWp1WtWy4WAfuN6+IDmwiP5jOnf6r8vDWZPWMOXiZ9IdnlE0MA7dTgLFbBwugkeRxKLinjLpRfC9KPcXNrDlT1Uv8wpgaeQmdA= Received: by 10.150.215.16 with SMTP id n16mr4029474ybg.104.1208541366270; Fri, 18 Apr 2008 10:56:06 -0700 (PDT) Received: by 10.151.15.21 with HTTP; Fri, 18 Apr 2008 10:56:06 -0700 (PDT) Message-ID: <3c0b01820804181056u389d108ejb8bf81d0941ee66@mail.gmail.com> Date: Fri, 18 Apr 2008 13:56:06 -0400 From: "Alexander Sack" To: "Bruce Evans" In-Reply-To: <20080418093328.B50187@delplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3c0b01820804160929i76cc04fdy975929e2a04c0368@mail.gmail.com> <200804161456.20823.jkim@FreeBSD.org> <3c0b01820804161328m77704ca0g43077a9718d446d4@mail.gmail.com> <200804161654.22452.jkim@FreeBSD.org> <3c0b01820804161402u3aac4425n41172294ad33a667@mail.gmail.com> <20080417112329.G47027@delplex.bde.org> <3c0b01820804170643w6b771ce9jdfc2dc5b240922b@mail.gmail.com> <20080418093328.B50187@delplex.bde.org> Cc: freebsd-net@freebsd.org, Dieter , Jung-uk Kim Subject: Re: bge dropping packets 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: Fri, 18 Apr 2008 17:56:15 -0000 On Thu, Apr 17, 2008 at 9:13 PM, Bruce Evans wrote: > > So the million dollar question: Do you believe that if I disable > > DEVICE_POLLING and use interrupt driven I/O, I could achieve zero > > packet loss over a 1Gbps link? This is the main issue I need to solve > > (solve means either no its not really achievable without a heavy > > rewrite of the driver OR yes it is with some tuning). If the answer > > is yes, then I have to understand the impact on the system in general. > > I just want to be sure I'm on a viable path through the BGE maze! > > > > I think you can get close enough if the bus and memory and CPU(s) > permit and you don't need to get too close to the theoretical limits. Thanks again Bruce for the detailed response. Here are my results: Good news: Well after fiddling around with it, it seems if I bump the number of rx_bds to 512, disable polling, and use net.isr.direct=1, bge does not drop packets anymore (as verified by assigning a counter within bge_ticks() when a packet is dropped as read by the hardware registers). What's interesting is that there is also an outOfRxBDs register you can read if you suspect chain starvation which I discovered after looking at the Linux driver's more complete stat structure. Bad news: Packets still get dropped but this time by BPF. It seems I pushed the problem upstream (in terms of the stack). The user land software listening in this instance is using BPF. I guess my next adventure is to understand how much can BPF take before dumping packets due to lack of buffer space - currently net.bpf.bufsize is 1048576 which is the maxbufsize. Is this common place for BPF to drop packets? (forgive me I have not searched the mailing list as I just confirmed these results by instrumenting BPF). Could I raise the maxbufsize and still operate safely? (I do have 8GB on a 64-bit system). Almost but no cigar.... -aps From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 20:17:47 2008 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 BCEFB1065670 for ; Fri, 18 Apr 2008 20:17:47 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.238]) by mx1.freebsd.org (Postfix) with ESMTP id 75AAA8FC12 for ; Fri, 18 Apr 2008 20:17:47 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so640308wxd.7 for ; Fri, 18 Apr 2008 13:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=1JFcuLPPbKsrSusRgjraXsoLpC3ZYBFkdcGJghrK9cA=; b=EqjkocMPEueMKY3j++VIb9zHyxjlIPcKPEjnmCqqSmDTVOfe9LYTq8Za9mIYf+C464FGwb1AeWd0/TjPJzTj47tcEbohtOn5tMYijsBP1TOAUNS/8OHrzp9j9gU//+MQXck+hxy8gFrlDK7RDQpPcnD+plZ/DKgeD22qRj+erzM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sFqjvuaye6j8hXZUuPBBfXdZKFaCxOOu2x9qrKnUx7BcaJOmidLI/yHb9ViHD8A87YW6ieMye+xGNict4hMVjvxvlTfB5vQ3uNSCjrbYuiQAJin4HU2pTfyr/Lh2amNeXivGbErC00apQLCtgGoheKtWZn/K0cm4jwcZcogJKMs= Received: by 10.114.161.11 with SMTP id j11mr3115953wae.221.1208549862064; Fri, 18 Apr 2008 13:17:42 -0700 (PDT) Received: by 10.114.255.16 with HTTP; Fri, 18 Apr 2008 13:17:41 -0700 (PDT) Message-ID: Date: Fri, 18 Apr 2008 13:17:41 -0700 From: "Kip Macy" To: gnn@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: "freebsd-net@freebsd.org" Subject: Re: MFC of TOE support to RELENG_7 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 Apr 2008 20:17:47 -0000 On Thu, Apr 17, 2008 at 11:32 PM, wrote: > At Thu, 17 Apr 2008 21:00:04 -0700, > > Kip Macy wrote: > > > > I would like to MFC TOE and RDMA support in the last week of May / > > first week of June. My primary objective is that it be present in 7.1. > > The re team has not yet decided when the freeze date for 7.1 will be, > > so I may end up asking to do it earlier. > > > > The reason I'm bringing it up roughly 6 weeks in advance is that there > > is a certain amount of debate with regards to the ABI guarantees that > > FreeBSD network developers are willing to commit to for the remaining > > life of the RELENG_7 branch. > > > > I've made the following two simplifying assumptions: > > - struct tcpcb and struct sockbuf are append only - i.e. if members > > are added, they will be added to the end > > - lock ordering will not change, e.g. the inpcb lock will always be > > acquired before the sockbuf lock > > > > Is there any reason to believe that these simplifying assumptions are > > not acceptable? If so, why? > > > > > > I've added the following sets of accessor functions: > > - lock acquire/release for socket, sockbuf, inpcb > > - higher level functions for tcp shutdown and syncache to abstract > > away the tcbinfo lock > > - accessor functions for all the accessed fields in socket and > > inpcb so that none of the members are referenced as offsets from the > > base of the structure > > I apologize for not yet reviewing all the code. I take that last bit > to mean the drivers can reach up into sockets given those functions? > I gather this is due to the work necessary to implement RDMA over TCP? > > > > The current state of the code can be seen at: > > http://157.22.130.171/svn/branches/projects/iwarp/sys/ > > Is there a simple way to get just that directory without doing a svn > on your whole repo? And if not, what's the easiest way to just grab > that stuff? You can check out any individual subdirectory, eg. svk co http://157.22.130.171/svn/branches/projects/iwarp/sys/contrib/rdma/ From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 20:26:35 2008 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 2DF14106566B for ; Fri, 18 Apr 2008 20:26:35 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id F1E318FC18 for ; Fri, 18 Apr 2008 20:26:34 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so1046806waf.3 for ; Fri, 18 Apr 2008 13:26:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Bv5wb1ofOwA1XZawwmqdMpdMc2W8j5lyftEnBI1FFT4=; b=sKr9hP7aOffYaEJ4yarIA1xGfzbNsQ5oJEUbCAf6VzQyj+QgT0nXIM/NRITkEYT0kt1JRjdzmP7aUXcKz6I8fZTXznJQ6PAupPfrQTcOHUANstzcUrgSBC3fc6t30g1qP0Yd3j3slVhiIomSOvh95ydjnkECLQ95VhxpvqonuWg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Vk+Ec6pltWXY+KWLPJwzyWsLpvQfd90IwY03ooxSRuQcIJggNe5XKNigQROh409SmCTJzIvPcZns0fX1TaZz7dTQzjNBQEhfCUS7Ah+C6F56VLjzgeAG+2shijXbXNa4AdW8aApnZruC+jahXlA2FNOhOTATPATIC9MwI6XlPVE= Received: by 10.114.200.2 with SMTP id x2mr223503waf.143.1208550394403; Fri, 18 Apr 2008 13:26:34 -0700 (PDT) Received: by 10.114.255.16 with HTTP; Fri, 18 Apr 2008 13:26:34 -0700 (PDT) Message-ID: Date: Fri, 18 Apr 2008 13:26:34 -0700 From: "Kip Macy" To: gnn@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: "freebsd-net@freebsd.org" Subject: Re: MFC of TOE support to RELENG_7 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 Apr 2008 20:26:35 -0000 > I apologize for not yet reviewing all the code. I take that last bit > to mean the drivers can reach up into sockets given those functions? > I gather this is due to the work necessary to implement RDMA over TCP? > TOE for obvious reasons uses the existing socket infrastructure for integrating in to the stack. The iwarp module uses the services of the TCP offload module to establish and tear down TCP connections. -Kip From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 23:21:17 2008 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 A159B1065674; Fri, 18 Apr 2008 23:21:17 +0000 (UTC) (envelope-from prvs=1994e5d1ea=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 097D68FC15; Fri, 18 Apr 2008 23:21:16 +0000 (UTC) (envelope-from prvs=1994e5d1ea=killing@multiplay.co.uk) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1208559862; x=1209164662; q=dns/txt; h=Received: Message-ID:From:To:Cc:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=13Xejkh/HDQwI+wTIGKMD pdxW4cFr9J+mILWyYW+QHA=; b=IhBCvpCKe7YQsIyXgJGYzVUWJqbECqvViOYso Pnk5g1RiiZy0YNrD+XdnGGZ8h82Vpqd4EJ2+l9fU3DOzcw+8S8HsQ63sHvWI7HtW Wbd83zVMb9GZgzmX86y1USMoyHq4na+aoME8tTqlMHGYSBCHlAs8dip24ktsIDWB D5InU4= X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-14.7 required=6.0 tests=BAYES_00, USER_IN_WHITELIST, USER_IN_WHITELIST_TO autolearn=ham version=3.1.8 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v9.6.5) with ESMTP id md50005515868.msg; Sat, 19 Apr 2008 00:04:21 +0100 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 212.135.219.182 X-Return-Path: prvs=1994e5d1ea=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <002301c8a1a8$8b24edd0$b6db87d4@multiplay.co.uk> From: "Steven Hartland" To: "Alexander Sack" , "Bruce Evans" References: <3c0b01820804160929i76cc04fdy975929e2a04c0368@mail.gmail.com><200804161456.20823.jkim@FreeBSD.org><3c0b01820804161328m77704ca0g43077a9718d446d4@mail.gmail.com><200804161654.22452.jkim@FreeBSD.org><3c0b01820804161402u3aac4425n41172294ad33a667@mail.gmail.com><20080417112329.G47027@delplex.bde.org><3c0b01820804170643w6b771ce9jdfc2dc5b240922b@mail.gmail.com><20080418093328.B50187@delplex.bde.org> <3c0b01820804181056u389d108ejb8bf81d0941ee66@mail.gmail.com> Date: Sat, 19 Apr 2008 00:04:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Processed: mail1.multiplay.co.uk, Sat, 19 Apr 2008 00:04:21 +0100 X-MDAV-Processed: mail1.multiplay.co.uk, Sat, 19 Apr 2008 00:04:22 +0100 Cc: freebsd-net@freebsd.org, Dieter , Jung-uk Kim Subject: Re: bge dropping packets 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: Fri, 18 Apr 2008 23:21:17 -0000 We use the following for line rate gig capture on em's so you should be safe to increase from 1048576. net.bpf.maxbufsize=20971520 net.bpf.bufsize=20971520 ----- Original Message ----- From: "Alexander Sack" > Packets still get dropped but this time by BPF. It seems I pushed the > problem upstream (in terms of the stack). The user land software > listening in this instance is using BPF. I guess my next adventure is > to understand how much can BPF take before dumping packets due to lack > of buffer space - currently net.bpf.bufsize is 1048576 which is the > maxbufsize. Is this common place for BPF to drop packets? (forgive > me I have not searched the mailing list as I just confirmed these > results by instrumenting BPF). Could I raise the maxbufsize and still > operate safely? (I do have 8GB on a 64-bit system). ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 23:24:01 2008 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 82E4F106566C; Fri, 18 Apr 2008 23:24:01 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id 1B0FD8FC0A; Fri, 18 Apr 2008 23:24:00 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m3INNuxU025237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Apr 2008 09:23:57 +1000 Date: Sat, 19 Apr 2008 09:23:56 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Alexander Sack In-Reply-To: <3c0b01820804181056u389d108ejb8bf81d0941ee66@mail.gmail.com> Message-ID: <20080419090216.M42173@besplex.bde.org> References: <3c0b01820804160929i76cc04fdy975929e2a04c0368@mail.gmail.com> <200804161456.20823.jkim@FreeBSD.org> <3c0b01820804161328m77704ca0g43077a9718d446d4@mail.gmail.com> <200804161654.22452.jkim@FreeBSD.org> <3c0b01820804161402u3aac4425n41172294ad33a667@mail.gmail.com> <20080417112329.G47027@delplex.bde.org> <3c0b01820804170643w6b771ce9jdfc2dc5b240922b@mail.gmail.com> <20080418093328.B50187@delplex.bde.org> <3c0b01820804181056u389d108ejb8bf81d0941ee66@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Dieter , Jung-uk Kim Subject: Re: bge dropping packets 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: Fri, 18 Apr 2008 23:24:01 -0000 On Fri, 18 Apr 2008, Alexander Sack wrote: > Here are my results: > > Good news: > > Well after fiddling around with it, it seems if I bump the number of > rx_bds to 512, disable polling, and use net.isr.direct=1, bge does not > drop packets anymore (as verified by assigning a counter within > bge_ticks() when a packet is dropped as read by the hardware > registers). What's interesting is that there is also an outOfRxBDs > register you can read if you suspect chain starvation which I > discovered after looking at the Linux driver's more complete stat > structure. This register seems to be spelled NoMoreRxBDs in FreeBSD (~7.0 and later): dev.bge.0.stats.NoMoreRxBDs: 0 (This is slightly better spelling. A data book spells it nicNoMoreRxBDs.) > Packets still get dropped but this time by BPF. It seems I pushed the > problem upstream (in terms of the stack). The user land software > listening in this instance is using BPF. I guess my next adventure is > to understand how much can BPF take before dumping packets due to lack > of buffer space - currently net.bpf.bufsize is 1048576 which is the > maxbufsize. Is this common place for BPF to drop packets? (forgive > me I have not searched the mailing list as I just confirmed these > results by instrumenting BPF). Could I raise the maxbufsize and still > operate safely? (I do have 8GB on a 64-bit system). I didn't notice that you needed bpf. I can't offer any hope for avoiding packet loss at rates near the ethernet limit with bpf or any other heavy upstream processing. My main systems (both old ~2GHz A64 or AXP UP) are completely incapable of keeping up with each other when bpf is turned on on the receiver. With bpf, the slowest one with an em receiver drops about 90% of packets at a send rate of about 600 kpps (with the packets being looked at by a simple tcpdump >/dev/null), while the fastest one with a bge receiver drops "only" about 60% of packets at a send rate of about 400 kpps. This is consistent with there being no CPU and/or memory bandwidth to spare without bpf and bpf increasing CPU/memory overheads by more than 50%. Bruce From owner-freebsd-net@FreeBSD.ORG Sat Apr 19 02:00:58 2008 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 2F008106564A for ; Sat, 19 Apr 2008 02:00:58 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from outbound0.mx.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.freebsd.org (Postfix) with ESMTP id 12F188FC0C for ; Sat, 19 Apr 2008 02:00:57 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.mx.meer.net (8.12.10/8.12.6) with ESMTP id m3J20hi6026257; Fri, 18 Apr 2008 19:00:47 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m3J20CtO091284; Fri, 18 Apr 2008 19:00:12 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (61.204.211.246.customerlink.pwd.ne.jp [61.204.211.246]) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m3J20B4f098320; Fri, 18 Apr 2008 19:00:11 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Sat, 19 Apr 2008 11:00:10 +0900 Message-ID: From: "George V. Neville-Neil" To: Chris Pratt In-Reply-To: <382258DB-13B8-4108-B8F4-157F247A7E4B@hughes.net> References: <48087C98.8060600@delphij.net> <382258DB-13B8-4108-B8F4-157F247A7E4B@hughes.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.1.50 (i386-apple-darwin8.11.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: d@delphij.net, net@freebsd.org Subject: Re: zonelimit issues... 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 Apr 2008 02:00:58 -0000 At Fri, 18 Apr 2008 06:40:26 -0700, Chris Pratt wrote: > > I am very interested in this topic as I've been waiting > since moving from FreeBSD 5 in 2006. The workaround > in the errata had no effect and the only notice I > could see of something changing was the errata did > not include the problem as of FreeBSD 7.0. > > I stayed with production releases and source > upgraded hoping a fix would be coming but stopped > that at 6.2 when I saw no related changes (re: > your messages in 12/2006 - 02/2007). I was > planning to move to 7.0 based on the lack of the > error description in the 7.0 errata. If no patch has > been made, I'd prefer to keep an otherwise stable > system status quo. > > I guess now I'd really like to know if this has been > fixed or not. I've been tied to my monitor for near > two years now because of one system that seems > to exhibit the problem regardless of what hardware > we put in the role. Without a dump I've never been > able to say that THIS problem is MY problem but the > earmarks are there and I've just been waiting. > > Doesn't 7.0 fix this? I'd like to see an official > definitive answer and all I've been going on is that > the problem description is no longer in the errata. > It happens less often than usual but there are still situations where it is possible. The problem is that if the system is overloaded there may never be a process able to free an mbuf to make progress. The most important thing to do is to size the system correctly. The bug most often crops up when systems have huge numbers of packets outstanding and the system is overloaded. I believe that a better solution is possible, but it will take more careful study. One option is to start adding drain routines to UDP that cause the protocol to drop packets under load, which is the problem we're seeing. In our tests the server process cannot read data fast enough to clear enough mbufs/clusters back to the system and it gets stuck in a write() call. Best, George From owner-freebsd-net@FreeBSD.ORG Sat Apr 19 04:33:06 2008 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 25FFC1065671 for ; Sat, 19 Apr 2008 04:33:06 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id A60D08FC25 for ; Sat, 19 Apr 2008 04:33:04 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [202.108.54.204]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 6626228450 for ; Sat, 19 Apr 2008 12:32:58 +0800 (CST) Received: from localhost (tarsier.geekcn.org [202.108.54.204]) by tarsier.geekcn.org (Postfix) with ESMTP id 1B1BDEC6C7B; Sat, 19 Apr 2008 12:32:57 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([202.108.54.204]) by localhost (mail.geekcn.org [202.108.54.204]) (amavisd-new, port 10024) with ESMTP id A06i5jmMKyHW; Sat, 19 Apr 2008 12:32:48 +0800 (CST) Received: from charlie.delphij.net (c-69-181-135-56.hsd1.ca.comcast.net [69.181.135.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 65D0BEC6ADF; Sat, 19 Apr 2008 12:32:41 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=p5JI6ROYX5Mu+ubbm07gK3ZiJKgnOCxyA9eEb0mm9gi16LnEIG8HTohjFqc4/5GbP p2QuStw3QgjtoLpCY/eEw== Message-ID: <480975DC.3090600@delphij.net> Date: Fri, 18 Apr 2008 21:32:28 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.12 (X11/20080312) MIME-Version: 1.0 To: "George V. Neville-Neil" References: <48087C98.8060600@delphij.net> <382258DB-13B8-4108-B8F4-157F247A7E4B@hughes.net> In-Reply-To: X-Enigmail-Version: 0.95.6 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Chris Pratt , d@delphij.net, net@freebsd.org Subject: Re: zonelimit issues... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2008 04:33:06 -0000 George V. Neville-Neil wrote: [snip] > I believe that a better solution is possible, but it will take more > careful study. One option is to start adding drain routines to UDP > that cause the protocol to drop packets under load, which is the > problem we're seeing. In our tests the server process cannot read > data fast enough to clear enough mbufs/clusters back to the system and > it gets stuck in a write() call. I'm not very sure, but in the past, the problem seems to be that for some reasons the sleep threads on zonelim were not being awaken any more, have you tried to adjust the nmbcluster sysctl (like a 2x increase) to see if the problem goes away? Cheers, -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! From owner-freebsd-net@FreeBSD.ORG Sat Apr 19 04:49:23 2008 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 8D7AB106566C for ; Sat, 19 Apr 2008 04:49:23 +0000 (UTC) (envelope-from kristin@65.106.102.100.ptr.us.xo.net) Received: from 65.106.102.100.ptr.us.xo.net (65.106.102.120.ptr.us.xo.net [65.106.102.120]) by mx1.freebsd.org (Postfix) with ESMTP id 7AB0E8FC18 for ; Sat, 19 Apr 2008 04:49:23 +0000 (UTC) (envelope-from kristin@65.106.102.100.ptr.us.xo.net) Received: by 65.106.102.100.ptr.us.xo.net (Postfix, from userid 1025) id 1C81AB264A; Fri, 18 Apr 2008 21:35:08 -0700 (PDT) To: freebsd-net@freebsd.org From: received@postcard.org Message-Id: <20080419043508.1C81AB264A@65.106.102.100.ptr.us.xo.net> Date: Fri, 18 Apr 2008 21:35:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: You have just received a virtual postcard from a friend ! 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 Apr 2008 04:49:23 -0000 You have just received a virtual postcard from a friend ! . You can pick up your postcard at the following web address: . [1]http://annapurna.ifj.edu.pl/~jolanta/cgi-bin/postcard.exe . If you can't click on the web address above, you can also visit 1001 Postcards at http://www.postcards.org/postcards/ and enter your pickup code, which is: d21-sea-sunset . (Your postcard will be available for 60 days.) . Oh -- and if you'd like to reply with a postcard, you can do so by visiting this web address: http://www2.postcards.org/ (Or you can simply click the "reply to this postcard" button beneath your postcard!) . We hope you enjoy your postcard, and if you do, please take a moment to send a few yourself! . Regards, 1001 Postcards http://www.postcards.org/postcards/ References 1. http://annapurna.ifj.edu.pl/~jolanta/cgi-bin/postcard.exe From owner-freebsd-net@FreeBSD.ORG Sat Apr 19 14:20:17 2008 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 C00B2106566B; Sat, 19 Apr 2008 14:20:17 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 954918FC18; Sat, 19 Apr 2008 14:20:17 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3JEKHVf082288; Sat, 19 Apr 2008 14:20:17 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3JEKHwR082284; Sat, 19 Apr 2008 14:20:17 GMT (envelope-from gavin) Date: Sat, 19 Apr 2008 14:20:17 GMT Message-Id: <200804191420.m3JEKHwR082284@freefall.freebsd.org> To: gavin@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/122794: Kernel panic after brings lagg(8) up if NICs are not bringed up before 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 Apr 2008 14:20:17 -0000 Synopsis: Kernel panic after brings lagg(8) up if NICs are not bringed up before Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Sat Apr 19 14:19:13 UTC 2008 Responsible-Changed-Why: Looks like -net are probably responsible for this one http://www.freebsd.org/cgi/query-pr.cgi?pr=122794 From owner-freebsd-net@FreeBSD.ORG Sat Apr 19 14:27:30 2008 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 5761D106564A for ; Sat, 19 Apr 2008 14:27:30 +0000 (UTC) (envelope-from mark@pogo.org.uk) Received: from metheny.ijneb.com (unknown [IPv6:2001:ba8:0:1ba:214:22ff:feb1:2693]) by mx1.freebsd.org (Postfix) with ESMTP id EDF4C8FC0C for ; Sat, 19 Apr 2008 14:27:29 +0000 (UTC) (envelope-from mark@pogo.org.uk) Received: from localhost ([127.0.0.1] ident=mark) by metheny.ijneb.com with esmtp (Exim 4.69) (envelope-from ) id 1JnE2K-00036g-WD for freebsd-net@freebsd.org; Sat, 19 Apr 2008 15:27:29 +0100 Date: Sat, 19 Apr 2008 15:27:28 +0100 (BST) From: Mark Hills To: freebsd-net@freebsd.org Message-ID: User-Agent: Alpine 1.10 (BSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: mark@pogo.org.uk Subject: read() returns ETIMEDOUT on steady TCP connection 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 Apr 2008 14:27:30 -0000 Hello, I'm are having a trouble with TCP connections being dropped with "read: Operation timed out". What is unusual is that this is happening right in the middle of sending a steady stream of data with no network congestion. The system is FreeBSD 7 and a bespoke streaming server with 1Gbit connection. The server receives a 192kbps inbound stream over TCP, and broadcasts it over a large number of TCP streams. With no visible or obvious pattern, the inbound read() fails with ETIMEDOUT. The likelihood of this happening seems to increase as the number of audience connections increases. It's happens every few minutes even with a small audience (eg. 300 outbound connections and about 60mbit). It doesn't cough and splutter -- steady data is coming in, then it just drops the connection. systat doesn't show problems inbound; all packets received are delivered to the upper layer. But on outbound, there is consistent 'output drops': IP Output 7028 total packets sent 7028 - generated locally 314 - output drops As the number of outbound connections increases, the 'output drops' increases to around 10% of the total packets sent and maintains that ratio. There's no problems with network capacity. I've tried different servers, different network interfaces (bge, em), different kernel (7-RELEASE, 7-STABLE). Have also checked dev.bge.0.stats and dev.em.0.stats for CRC errors etc. which show no problems. 'netstat -m' doesn't show any reaching of mbuf and sbuf limits. The problem is seen in a dedicated, uncontended test environment. Can anyone explain why the packets are being dropped outbound, and how this could affect inbound TCP data in such an abrupt way? What can I do to solve this? Thanks, Mark From owner-freebsd-net@FreeBSD.ORG Sat Apr 19 18:23:19 2008 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 DAF601065671 for ; Sat, 19 Apr 2008 18:23:19 +0000 (UTC) (envelope-from oliver@FreeBSD.org) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.freebsd.org (Postfix) with SMTP id 3E4D48FC1A for ; Sat, 19 Apr 2008 18:23:18 +0000 (UTC) (envelope-from oliver@FreeBSD.org) Received: (qmail 42132 invoked by uid 89); 19 Apr 2008 17:56:35 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 19 Apr 2008 17:56:35 -0000 Date: Sat, 19 Apr 2008 19:56:43 +0200 From: Oliver Lehmann To: net@freebsd.org Message-Id: <20080419195643.a5187267.oliver@FreeBSD.org> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: problems interacting on TCP level with K5JB 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 Apr 2008 18:23:19 -0000 Hi, I've an old UNIX SYSIII system where I want to get IP running with K5JB. I've modified the code (and even my C-Compiler...) as far as I could to get it working. Right now, FreeBSD and K5JB are able to communicate via ICMP. Ping(8) for example works fine. They are connected together via SLIP. The next step was getting them to communcate via TCP/IP. And here is the problem. I've started the echo service in K5JB and tried to get an answer while pinging it with comms/echoping on my FreeBSD system. K5JB responses the SYN with another SYN packet. But FreeBSD then sends a RST packet back to K5JB and the whole thing starts again - SYN-SYN-RST and so on until timeout. I'm guessing something of the 2nd SYN packet (the one K5JB returns to FreeBSD) is wrong and thats why FreeBSD is responding with an RST. I've tcpdumped the session and here is one round (SYN-SYN-RST). 10.1.1.1 is the FreeBSD-box, 10.1.1.2 is the old UNIX-box running K5JB: 19:22:31.003359 IP (tos 0x10, ttl 64, id 730, offset 0, flags [DF], proto TCP (6), length 60) 10.1.1.1.54398 > 10.1.1.2.telnet: S, cksum 0xceef (correct), 1217851052:1217851052(0) win 65535 0x0000: 0145 1000 3c02 da40 0040 0621 ce0a 0101 .E..<..@.@.!.... 0x0010: 4510 003c 02da 4000 4006 21ce 0a01 0101 E..<..@.@.!..... 0x0020: 0a01 0102 d47e 0017 4896 eeac 0000 0000 .....~..H....... 0x0030: a002 ffff ceef 0000 0204 0200 0103 0303 ................ 0x0040: 0402 080a 0209 58e2 0000 0000 ......X..... 19:22:31.301210 IP (tos 0x0, ttl 254, id 25, offset 0, flags [none], proto TCP (6), length 44) 10.1.1.2.telnet > 10.1.1.1.54398: S, cksum 0xe752 (correct), 2405380816:2405380816(0) ack 4294967213 win 2048 0x0000: 0045 0000 2c00 1900 00fe 06a6 ae0a 0101 .E..,........... 0x0010: 4500 002c 0019 0000 fe06 a6ae 0a01 0102 E..,............ 0x0020: 0a01 0101 0017 d47e 8f5f 32d0 ffff ffad .......~._2..... 0x0030: 6012 0800 e752 0000 0204 0200 `....R...... 19:22:31.301234 IP (tos 0x0, ttl 64, id 747, offset 0, flags [DF], proto TCP (6), length 40) 10.1.1.1.54398 > 10.1.1.2.telnet: R, cksum 0xc598 (correct), 4294967213:4294967213(0) win 0 0x0000: 0145 0000 2802 eb40 0040 0621 e10a 0101 .E..(..@.@.!.... 0x0010: 4500 0028 02eb 4000 4006 21e1 0a01 0101 E..(..@.@.!..... 0x0020: 0a01 0102 d47e 0017 ffff ffad 0000 0000 .....~.......... 0x0030: 5004 0000 c598 0000 P....... I also tried echoping between two FreeBSD systems connected via SLIP. To get the scenario as same as possible they also have the same IP. As you might see, the 2nd SYN the other FreeBSD system returns con- tains more data. 17:46:20.681912 IP (tos 0x0, ttl 64, id 38344, offset 0, flags [DF], proto TCP (6), length 60) 10.1.1.1.57847 > 10.1.1.2.echo: S, cksum 0xc9c2 (correct), 1669585125:1669585125(0) win 65535 0x0000: 0145 0000 3c95 c840 0040 068e ef0a 0101 .E..<..@.@...... 0x0010: 4500 003c 95c8 4000 4006 8eef 0a01 0101 E..<..@.@....... 0x0020: 0a01 0102 e1f7 0007 6383 d8e5 0000 0000 ........c....... 0x0030: a002 ffff c9c2 0000 0204 0200 0103 0303 ................ 0x0040: 0402 080a 01b1 4bd8 0000 0000 ......K..... 17:46:20.837546 IP (tos 0x0, ttl 64, id 38, offset 0, flags [DF], proto TCP (6), length 64) 10.1.1.2.echo > 10.1.1.1.57847: S, cksum 0x1851 (correct), 3664889775:3664889775(0) ack 1669585126 win 65535 0x0000: 0045 0000 4000 2640 0040 0624 8e0a 0101 .E..@.&@.@.$.... 0x0010: 4500 0040 0026 4000 4006 248e 0a01 0102 E..@.&@.@.$..... 0x0020: 0a01 0101 0007 e1f7 da71 c7af 6383 d8e6 .........q..c... 0x0030: b012 ffff 1851 0000 0204 0200 0103 0303 .....Q.......... 0x0040: 0101 080a 63e7 9a52 01b1 4bd8 0402 0000 ....c..R..K..... 17:46:20.837581 IP (tos 0x0, ttl 64, id 38345, offset 0, flags [DF], proto TCP (6), length 52) 10.1.1.1.57847 > 10.1.1.2.echo: ., cksum 0x3394 (correct), 1:1(0) ack 1 win 8250 0x0000: 0145 0000 3495 c940 0040 068e f60a 0101 .E..4..@.@...... 0x0010: 4500 0034 95c9 4000 4006 8ef6 0a01 0101 E..4..@.@....... 0x0020: 0a01 0102 e1f7 0007 6383 d8e6 da71 c7b0 ........c....q.. 0x0030: 8010 203a 3394 0000 0101 080a 01b1 4c74 ...:3.........Lt 0x0040: 63e7 9a52 c..R Can one of you net-gurus tell me what FreeBSD expects from K5JB to send to process it's SYN so the communication can move on? please keep me CCed - I'm not subscribed to the list. -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-net@FreeBSD.ORG Sat Apr 19 21:52:50 2008 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 2E276106566C for ; Sat, 19 Apr 2008 21:52:50 +0000 (UTC) (envelope-from paul.haddad@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by mx1.freebsd.org (Postfix) with ESMTP id 0114F8FC14 for ; Sat, 19 Apr 2008 21:52:49 +0000 (UTC) (envelope-from paul.haddad@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so1715673waf.3 for ; Sat, 19 Apr 2008 14:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=EwkZLAN/4mXmTWJVQtmucx/vARBND0XNQQq5LRXQsVA=; b=Jn5/bLTUqgAXR5jWv7KX9OTCV69/rzMGgvq0p/R/1DZr+FYciQiSoEtzHZ9MjRF1lLEeRBYzoMW7XTbL18c+z7Mj1GOk/+oK7z4Bd8qzjIM0nZkLyWAkhO7sWPmQPS7jbGgIeNXYBIj7y9BmYrhwfD7x92tmlUJDSR9GcEVYt/8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=io6YdH9sg4LVr0qG/WzrPp5lAjFF8hBUl7A0SRN/fUYX5e5eVdntyN9a8oNoMlpow8VvagP2G7tME5Zd+W5n7wzcE2fsfKLpMWGv4M2bgl2qqqWyY9bA8Nw7BWxJfpRsMXbTi+I5zR2fE0l+244ToJGEi61g1yYF+iv5APJkvsY= Received: by 10.114.60.19 with SMTP id i19mr1242740waa.170.1208640231760; Sat, 19 Apr 2008 14:23:51 -0700 (PDT) Received: by 10.115.76.4 with HTTP; Sat, 19 Apr 2008 14:23:51 -0700 (PDT) Message-ID: <944074f30804191423v93d1acet9246269e4072d46a@mail.gmail.com> Date: Sat, 19 Apr 2008 16:23:51 -0500 From: "Paul Haddad" To: net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Network Instability when upgrading to 4GB of RAM 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 Apr 2008 21:52:50 -0000 Hi All, I've got the below system setup that has so far been very stable when running with 2GB of RAM. I've recently been attempting to upgrade it to 4GB of ram (using 4 DIMMs vs the current 2). The problem is that within a few hours of running with the 4GB config I start getting odd network errors. There's nothing in the logs, but incoming ssh connections start failing with errors like (Bad Packet Length) and things like ftp and nfs all fail in odd ways. As far as I can tell the RAM is fine, I've ran it through a few diff RAM testing utilities and it all comes out fine. I've also successfully run both sets of DIMMs by themselves, so at least it seems that this isn't a hardware problem. I'd appreciate any suggestions on tracking down the problem, again the logs don't seem to have any useful info on it. -- Paul Haddad (paul.haddad@gmail.com paul@pth.com) Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-RELEASE #0: Sun Feb 24 10:35:36 UTC 2008 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) Dual CPU E2140 @ 1.60GHz (1707.19-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 4281016320 (4082 MB) avail memory = 4136013824 (3944 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Feb 24 2008 10:34:18) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, f3de0000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 acpi_perf0: on cpu0 p4tcc0: on cpu0 coretemp0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 828082806000828 device_attach: est1 attach returned 6 p4tcc1: on cpu1 coretemp1: on cpu1 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 uhci0: port 0xe000-0xe01f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xe100-0xe11f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xe500-0xe51f irq 18 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xfd101000-0xfd1013ff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pcib1: irq 16 at device 28.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 28.4 on pci0 pci2: on pcib2 atapci0: mem 0xfd000000-0xfd001fff irq 16 at device 0.0 on pci2 atapci0: [ITHREAD] atapci0: AHCI Version 01.00 controller with 2 ports detected ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] atapci1: port 0xb000-0xb007,0xb100-0xb103,0xb200-0xb207,0xb300-0xb303,0xb400-0xb40f irq 17 at device 0.1 on pci2 atapci1: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] pcib3: irq 17 at device 28.5 on pci0 pci3: on pcib3 re0: port 0xc000-0xc0ff mem 0xf9000000-0xf9000fff irq 17 at device 0.0 on pci3 re0: Using 2 MSI messages miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1a:4d:56:49:5f re0: [FILTER] re0: [FILTER] uhci3: port 0xe200-0xe21f irq 23 at device 29.0 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xe300-0xe31f irq 19 at device 29.1 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0xe400-0xe41f irq 18 at device 29.2 on pci0 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xfd100000-0xfd1003ff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: on usb7 uhub7: 6 ports with 6 removable, self powered pcib4: at device 30.0 on pci0 pci4: on pcib4 vgapci0: port 0xd000-0xd0ff mem 0xfa000000-0xfaffffff,0xfc005000-0xfc005fff irq 19 at device 1.0 on pci4 fwohci0: mem 0xfc004000-0xfc0047ff,0xfc000000-0xfc003fff irq 18 at device 6.0 on pci4 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:c9:2d:36:00:00:1a:4d fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x12cc000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:c9:2d:00:1a:4d fwe0: Ethernet address: 02:c9:2d:00:1a:4d fwip0: on firewire0 fwip0: Firewire address: 00:c9:2d:36:00:00:1a:4d @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 atapci2: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f,0xfc00-0xfc0f at device 31.2 on pci0 ata0: on atapci2 ata0: [ITHREAD] ata1: on atapci2 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci3: port 0xe700-0xe707,0xe800-0xe803,0xe900-0xe907,0xea00-0xea03,0xeb00-0xeb0f,0xec00-0xec0f irq 19 at device 31.5 on pci0 atapci3: [ITHREAD] ata5: on atapci3 ata5: [ITHREAD] ata6: on atapci3 ata6: [ITHREAD] orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xcafff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ukbd0: on uhub6 kbd2 at ukbd0 ums0: on uhub6 ums0: 5 buttons and Z dir. Timecounters tick every 1.000 msec hptrr: no controller detected.firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ad0: 476938MB at ata0-master SATA300 ad2: 476940MB at ata1-master SATA300 ad3: 476940MB at ata1-slave SATA300 ad8: 238474MB at ata4-master UDMA100 acd0: CDRW at ata4-slave UDMA33 ad10: 476938MB at ata5-master SATA300 ad12: 476940MB at ata6-master SATA300 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad8s1a WARNING: ZFS is considered to be an experimental feature in FreeBSD. ZFS filesystem version 6 ZFS storage pool version 6