From owner-freebsd-net@FreeBSD.ORG Sun Jan 6 01:01:04 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8A3D6933 for ; Sun, 6 Jan 2013 01:01:04 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) by mx1.freebsd.org (Postfix) with ESMTP id EE4F8CE0 for ; Sun, 6 Jan 2013 01:01:03 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id em20so12321638lab.28 for ; Sat, 05 Jan 2013 17:00:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TSPfQfw4EwJlGHihSJL6JOYLF667FNBUhUUCPfUS/kM=; b=crpO+/wCg1N5InpxkjP5vHQNjs5q9p9o2wzwTFo5fGcRB2XdsCFVpNTdG6BBgbPQ8F /JuJ1Oq21yca6vCFt22v9R3gYzXZIqBASQd64zvVYNooYY3WUhoz+mo4xQFoLYb+YABR zwxSjr0XAA9ctBEto835OZRNuium6CYoTaQfQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=TSPfQfw4EwJlGHihSJL6JOYLF667FNBUhUUCPfUS/kM=; b=IufLnkeCyndtYb50FZtJcdRGm0TLUjPZ36DhljR0/bB/QjOoLYtWh3WyoP20MBbwnB URqGD9hKpMaczuUcKvRyOsXtTKpFkwGLMjmRE8t2isY8apH7B9+q3uIZsrs1DRa1qiit zVYKKot2B28CBrHVy3jj+aT0ERaWLHFylTpBfo2L9DUC/zGBVXgKctrVJUWL2mIJLno4 M3RJ/7Dn9Oi3iOG2WTk8Bn5mKEmo9XFsr546oGc2t80C4oqxvnOpo58TTiPvTSi5iACD KffPOCnlS25PbDaI2v/PWIEb8yssaaM8BAQBwlKgcw2nPWP2w17MFvlESVASfdfgUoW/ SqbA== Received: by 10.112.85.35 with SMTP id e3mr21752663lbz.106.1357434056572; Sat, 05 Jan 2013 17:00:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.75.200 with HTTP; Sat, 5 Jan 2013 17:00:25 -0800 (PST) In-Reply-To: References: <86ehl96o4i.fsf@venux.xbsd.name> <86txu277vn.fsf@venux.xbsd.name> <201210101954.49000.bschmidt@techwires.net> From: Eitan Adler Date: Sat, 5 Jan 2013 20:00:25 -0500 Message-ID: Subject: Re: What driver should I use for 'intel centrino wireless-N 2200 BGN'? To: Bernhard Schmidt Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQk2/7FQS1lzOp7tsT2nuo0UgDV0JpCw5snbQ3+J8SlXHoVeOaUB2m3Kag3J8pBMIWMGLf+/ Cc: "Denise H. G." , Kevin Oberman , Andreas Nilsson , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 06 Jan 2013 01:01:04 -0000 On 25 December 2012 22:06, Eitan Adler wrote: > On 10 October 2012 13:54, Bernhard Schmidt wrote: >> On Wednesday 10 October 2012 15:51:24 Denise H. G. wrote: >>> >>>>> none3@pci0:3:0:0: class=0x028000 card=0x42228086 chip=0x08918086 >>> >>>>> rev=0xc4 hdr=0x00 >>> >>>>> >>> >>>>> Is there a driver for that under FreeBSD 9.1-PRERELEASE? >> >> No, not yet. I'm having a hard figuring out the new firmware API for >> those new devices. Working on it.. >> > ... >> Intel Centrino Wireless-N 2200 BGN > > Has there been any progress on this? ping? I have this wireless card and would love to use the internet. :) -- Eitan Adler From owner-freebsd-net@FreeBSD.ORG Sun Jan 6 02:04:29 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 13CEC72A for ; Sun, 6 Jan 2013 02:04:29 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by mx1.freebsd.org (Postfix) with ESMTP id 790E5E0F for ; Sun, 6 Jan 2013 02:04:28 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id 15so8835944wgd.16 for ; Sat, 05 Jan 2013 18:04:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=UVCnNLw63jVViQFBGUETzCIcGYdtTGdef7NhXG7aMA4=; b=pg53/cU1ZWS0IXY7ElmNfA8KGTu+Cpzau5q+JwkRrPALZGd3Pi4hSMlSe5Io+MpxzG yht/CP3jd6N1ZZoNKf1t70TupPHpetdC/9EM5isDSrH69Pvve7XWUhl9ghyWXeyZCJDE IgOV5I5xOZuvFLB8LBlF4mhkewHimpfK+bCKEoLpyxlVOc2aqInFHafQEIxQ//lGf+LS gxlK1RDIyUV7mzkPCsOSj1A1nP19MOPeEAL9FDS4ZAZFYacCMJMT3iZ+5KUf0XUnCc6F IYvooXgoLz9/PlPvBChPYb9GRqQGjdxL4pj2E++8xnEEUek8mb5vrQRpGleXDEq0uagt q/nA== MIME-Version: 1.0 Received: by 10.180.109.201 with SMTP id hu9mr3580516wib.32.1357437866984; Sat, 05 Jan 2013 18:04:26 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sat, 5 Jan 2013 18:04:26 -0800 (PST) In-Reply-To: References: <86ehl96o4i.fsf@venux.xbsd.name> <86txu277vn.fsf@venux.xbsd.name> <201210101954.49000.bschmidt@techwires.net> Date: Sat, 5 Jan 2013 18:04:26 -0800 X-Google-Sender-Auth: 00mxx5RaE9TR_vtQft__9wTVTJU Message-ID: Subject: Re: What driver should I use for 'intel centrino wireless-N 2200 BGN'? From: Adrian Chadd To: Eitan Adler Content-Type: text/plain; charset=ISO-8859-1 Cc: Bernhard Schmidt , freebsd-net@freebsd.org, Andreas Nilsson , Kevin Oberman , "Denise H. G." X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 06 Jan 2013 02:04:29 -0000 Hi, The best thing I can suggest right now is trying the linux driver out and if it works better, working out what the driver is / isn't doing correctly. I suspect that if you simply wait for something to happen, it's not going to happen. Adrian On 5 January 2013 17:00, Eitan Adler wrote: > On 25 December 2012 22:06, Eitan Adler wrote: >> On 10 October 2012 13:54, Bernhard Schmidt wrote: >>> On Wednesday 10 October 2012 15:51:24 Denise H. G. wrote: >>>> >>>>> none3@pci0:3:0:0: class=0x028000 card=0x42228086 chip=0x08918086 >>>> >>>>> rev=0xc4 hdr=0x00 >>>> >>>>> >>>> >>>>> Is there a driver for that under FreeBSD 9.1-PRERELEASE? >>> >>> No, not yet. I'm having a hard figuring out the new firmware API for >>> those new devices. Working on it.. >>> >> ... >>> Intel Centrino Wireless-N 2200 BGN >> >> Has there been any progress on this? > > ping? > > I have this wireless card and would love to use the internet. :) > > > -- > Eitan Adler > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Jan 6 02:24:41 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0D5988CD for ; Sun, 6 Jan 2013 02:24:41 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) by mx1.freebsd.org (Postfix) with ESMTP id 8707BE64 for ; Sun, 6 Jan 2013 02:24:39 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id fk20so12088773lab.8 for ; Sat, 05 Jan 2013 18:24:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+yZbBCa/1cFmZbcuzI2Mc7bXVYh8ttnDoRQZZ3OATpk=; b=PSr99dtNhY8Awb1rkgENTeiF2T0nMpDLNYsenMvWjT0y+HTi7VJQCO7xALIU96p1WS FbOuPNCY0zhDc9pJkRGa0UP2MgbdhCTyD36ZmW6bGj/mPK6QcBkGQak5MG/vwcyVMisf tSEC4nb6PUB3CVzPjoBnI0PSEE/xfVGUtNc2w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=+yZbBCa/1cFmZbcuzI2Mc7bXVYh8ttnDoRQZZ3OATpk=; b=lYNrllgq56wIaeKbSLZIVlbqXN5h26r+kVezMKNRCpvX5XUnI2EnN1zh7uPloV/4b+ 0Wa6h48z+Ht/3l5VpVE17pwmhlnGZ37bYNuw4f+01NrU59n1QQ4yvmZ/fDngYJFgP6x6 pLu6wi29I9LNq0TpVekDT/vXPzcZkk49EvXt74vVVFmwRa6rIK+NKgD7Fxu6tbYghB/e wHen618LW6ARzaFmx1wS1ZsFjq0PPNQe9Cgp+MJcYl7vdwXcoGtwaR+I/S9THBAa3t0e 0F9BgF5R852ARN5Z4HyzvOPfVuDBlRi+byG/h29GELTrRx7jgecDbCD0Rh2tPb5eIeJp QlGw== Received: by 10.152.148.129 with SMTP id ts1mr54470949lab.19.1357439078932; Sat, 05 Jan 2013 18:24:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.75.200 with HTTP; Sat, 5 Jan 2013 18:24:08 -0800 (PST) In-Reply-To: References: <86ehl96o4i.fsf@venux.xbsd.name> <86txu277vn.fsf@venux.xbsd.name> <201210101954.49000.bschmidt@techwires.net> From: Eitan Adler Date: Sat, 5 Jan 2013 21:24:08 -0500 Message-ID: Subject: Re: What driver should I use for 'intel centrino wireless-N 2200 BGN'? To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQk5mpp6Svq7HyLG8MJ+SHHBzh0EZlgPp6AgGOSeJt+CdiJA0/bh239YLz7Glj23Uw5H9Rrp Cc: Bernhard Schmidt , freebsd-net@freebsd.org, Andreas Nilsson , Kevin Oberman , "Denise H. G." X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 06 Jan 2013 02:24:41 -0000 On 5 January 2013 21:04, Adrian Chadd wrote: > Hi, > > The best thing I can suggest right now is trying the linux driver out > and if it works better, working out what the driver is / isn't doing > correctly. Bernhard Schmidt, an expert in the area, is having a hard time figuring it out. I, with zero experience in the area, no testing hardware (just my one nic), am going to have an easier time to figure this out? > I suspect that if you simply wait for something to happen, it's not > going to happen. This assumes I have the time to work on this. Currently *all three* of my nics do not work on HEAD. I chasing down one of them on -usb now with hps. iwn is the second. The last is alc which I've been told the vendor may be working on (and db is working on as well). Furthermore my main development computer (which had working internet) has a broken motherboard which I am waiting for a replacement for. I also work during the day and take a course on the Weekend. I simply *do not* have the time to track this down. When I do have to work on FreeBSD stuff I have { ports, src, doc } stuff that I already do in addition to working on closing PRs, chasing down users, etc. Sometimes the answer isn't "please do more work". At this time I *can't* be the one tracking down the iwn bug / missing feature. -- Eitan Adler From owner-freebsd-net@FreeBSD.ORG Sun Jan 6 02:28:46 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 91AEF987 for ; Sun, 6 Jan 2013 02:28:46 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by mx1.freebsd.org (Postfix) with ESMTP id C3C01E81 for ; Sun, 6 Jan 2013 02:28:45 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id 12so8384235wgh.31 for ; Sat, 05 Jan 2013 18:28:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Vi3JB73ZC+lK8fGpgYEO3DHTbOQ5VQhRcJ9R3xOjXVc=; b=QYxKQ9ctFcomPfMUSC0mWJAvbdnHPz0XhFyds715HgLK2nZFxRwGhROzdDkJdSP2Ct Wq7ZIkHOBv3FgZ2beZOcIaQMHhqQYXKFq6VOZ3MuFECvTZeSIZMO+z2tSViQ42RwOhij i92tA3Q+OU/qK0Vn7SXN8KKRAYw1NbOtaodX5yaLIpVDtVzMvvgyXUrBWzybzUWLxNuG zx/2FqKKLQpD6HRmSOkArRyTPA1fqc41pHxMTtCKsZ7g4UL3pxDnjNW6bWfycL5RcdJF S/SXwoKjUSi5FDhVMumUO61m/zLW2repYKwD3tXLzoZ/tbfCKC4thDUyZdwEb1b/hXPs nt1A== MIME-Version: 1.0 X-Received: by 10.180.72.146 with SMTP id d18mr3613985wiv.33.1357439324471; Sat, 05 Jan 2013 18:28:44 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sat, 5 Jan 2013 18:28:44 -0800 (PST) In-Reply-To: References: <86ehl96o4i.fsf@venux.xbsd.name> <86txu277vn.fsf@venux.xbsd.name> <201210101954.49000.bschmidt@techwires.net> Date: Sat, 5 Jan 2013 18:28:44 -0800 X-Google-Sender-Auth: qtk1ZM_syleZWPyR8LCb8PgDLzY Message-ID: Subject: Re: What driver should I use for 'intel centrino wireless-N 2200 BGN'? From: Adrian Chadd To: Eitan Adler Content-Type: text/plain; charset=ISO-8859-1 Cc: Bernhard Schmidt , freebsd-net@freebsd.org, Andreas Nilsson , Kevin Oberman , "Denise H. G." X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 06 Jan 2013 02:28:46 -0000 [snip] Welcome to FreeBSD wireless. :-) Where there's like two of us pulling double-duty, and a few others helping out here and there. I think the main problem with the intel card is that the _linux_ driver isn't yet stable, so unless we find someone who knows the NIC/firmware very well, we're stuck with that. Adrian From owner-freebsd-net@FreeBSD.ORG Mon Jan 7 08:20:39 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F40E4D76; Mon, 7 Jan 2013 08:20:38 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) by mx1.freebsd.org (Postfix) with ESMTP id 87D5412A; Mon, 7 Jan 2013 08:20:37 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id E799C153434; Mon, 7 Jan 2013 09:20:34 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNUgeDm_0MEJ; Mon, 7 Jan 2013 09:20:34 +0100 (CET) Received: from [127.0.0.1] (opteron [192.168.10.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPS id 1B938153433; Mon, 7 Jan 2013 09:20:34 +0100 (CET) Message-ID: <50EA8558.4010600@digiware.nl> Date: Mon, 07 Jan 2013 09:20:40 +0100 From: Willem Jan Withagen Organization: Digiware Management b.v. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Barney Cordoba Subject: Re: kern/174851: [bxe] [patch] UDP checksum offload is wrong in bxe driver References: <1357399030.5935.YahooMailClassic@web121603.mail.ne1.yahoo.com> In-Reply-To: <1357399030.5935.YahooMailClassic@web121603.mail.ne1.yahoo.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130106-1, 01/06/2013), Outbound message X-Antivirus-Status: Clean Cc: Garrett Cooper , freebsd-net@freebsd.org, Adrian Chadd , David Christensen , linimon@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 07 Jan 2013 08:20:39 -0000 On 2013-01-05 16:17, Barney Cordoba wrote: > > > --- On Fri, 1/4/13, Willem Jan Withagen wrote: > >> From: Willem Jan Withagen >> Subject: Re: kern/174851: [bxe] [patch] UDP checksum offload is wrong in bxe driver >> To: "Barney Cordoba" >> Cc: "Garrett Cooper" , freebsd-net@freebsd.org, "Adrian Chadd" , "David Christensen" , linimon@freebsd.org >> Date: Friday, January 4, 2013, 9:41 AM >> On 2013-01-01 0:04, Barney Cordoba >> wrote: >> >>> The statement above "assumes" that there is a benefit. >> voIP packets >>> are short, so the benefit of offloading is reduced. >> There is some >>> delay added by the hardware, and there are cpu cycles >> used in managing >>> the offload code. So those operations not only muddy >> the code, >>> but they may not be faster than simply doing the >> checksum on a much, much >>> faster cpu. >> >> Forgoing all the discussions on performance and possible >> penalties in >> drivers..... >> >> I think there is a large set of UDP streams (and growing) >> that do use >> larger packets. >> >> The video streaming we did used a size of header(14)+7*188, >> which is the >> max number of MPEG packet to fit into anything with an MTU >> < 1500. >> >> Receiving those on small embedded devices which can do HW >> check-summing >> is very beneficial there. >> On the large servers we would generate up to 5Gbit of >> outgoing streams. >> I'm sure that offloading UDP checks would be an advantage as >> well. >> (They did run mainly Linux, but FreeBSD would also work) >> >> Unfortunately most of the infrastructure has been taken >> down, so it is >> no longer possible to verify any of the assumptions. >> >> --WjW > > If you haven't benchmarked it, then you're just guessing. That's my point. > > Its like SMP in freeBSD 4. People bought big, honking machines and the > big expensive machines were slower than a single core system at less than > half the price. Just because something sounds better doesn't mean that it is better. I completely agree.... Dutch proverb goes: "To measure is to know" Which was the subtitle of my graduation report, and my professional motto when working as a systems-architect.... That's why it is sad that the system is no longer up and running, because a 0-order check would be no more that 1 ifconfig would have made a difference. But that is all water under the bridge. --WjW From owner-freebsd-net@FreeBSD.ORG Mon Jan 7 11:06:49 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EBC3FBD for ; Mon, 7 Jan 2013 11:06:49 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id DD72BF97 for ; Mon, 7 Jan 2013 11:06:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r07B6nGQ087949 for ; Mon, 7 Jan 2013 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r07B6ndF087947 for freebsd-net@FreeBSD.org; Mon, 7 Jan 2013 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 7 Jan 2013 11:06:49 GMT Message-Id: <201301071106.r07B6ndF087947@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 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 07 Jan 2013 11:06:50 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172985 net [patch] [ip6] lltable leak when adding and removing IP o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171838 net [oce] [patch] Possible lock reversal and duplicate loc o kern/171739 net [bce] [panic] bce related kernel panic o kern/171728 net [arp] arp issue o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net [tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel p kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 433 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jan 7 21:41:24 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7F668A13 for ; Mon, 7 Jan 2013 21:41:24 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm12-vm1.bullet.mail.ne1.yahoo.com (nm12-vm1.bullet.mail.ne1.yahoo.com [98.138.91.41]) by mx1.freebsd.org (Postfix) with ESMTP id 3DB3487A for ; Mon, 7 Jan 2013 21:41:24 +0000 (UTC) Received: from [98.138.90.51] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 07 Jan 2013 21:41:17 -0000 Received: from [98.138.89.246] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 07 Jan 2013 21:41:17 -0000 Received: from [127.0.0.1] by omp1060.mail.ne1.yahoo.com with NNFMP; 07 Jan 2013 21:41:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 103079.12163.bm@omp1060.mail.ne1.yahoo.com Received: (qmail 65278 invoked by uid 60001); 7 Jan 2013 21:41:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1357594876; bh=cdmjs445P9/UdRk/lJW67EBxZCYAz/JSDNRAzox16wk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=OB0CASrjNEBpYqZDT+S6kdaAccxYr/Pg+3ETm/2FPoBHQlKyuHGPAkbeYOjt/7LN2KiSwqGgWzfQwMVGr5nd1xfxkeR95Nib+IeUMnsgBw901O8SJECjngENyTdtlAZHzCLM2R0hHruQ127btNXGRjBjnYCWX8gy0Oq4itCSqoQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=W9wRXfjYQzNM2pYuQlxyxtHW03xy8jLynUH+k1fg6clWKUHH1xzwBWI1lNq5s+YZTVD6CtIAILDZddTvo2J3xkF/DVb9v66SQusmB5ADRIP1cJ6mS+9FRfoQRt0hBj7r3AA9JhE05jRM1xfBklWCBJX971EdUe6BPoHucUJmbdg=; X-YMail-OSG: bnYM04EVM1nH36QQLzAAcwe27UYbxNJXLypDRkMgorMVHnj t3fiOfQfHlapic8VmMmsSl5xi52LfhXZc9_r4tVk_o9.aAeNdf_ToA9L7pHE BWotQNFmHOsx19VFJ4Q.WAWCQ2C0HlM9Jdr4kyQKKLlaGMqrfWdK2eDn0G3z NyRHMhLyTa7aYnK3SGwxNksL7WyWWQ_ndrKVt7gEEeiOSK1R3VCdph1jqxJI w.vrOkj.6qraVasqVmuYv99XKS5KgfVBZCnDbTxh4S_3Lrofc4aJVqrWayWY WRB_zboYXV6K4LqPIBVYsAwEX00Rf0DYMqBr9cwJTnikJoj_KDAlUgkEhbOI 9qhsTfjkgh56r08kVavKec5I1CCaIIxD2N3ikqCFIpL3WcdwyGoe3heqBabX ZQMwrZ4F1bR7xDeTWiGc1_64WFdVABqAWDYjHLAog5Zj5J2RZ_G1BBjXYo5y pr6QigRaElF7Go1C9G8aZCRMObb9c35fry9owtF0qVVkj8XuZJKstzLVUuTa Ysys55sw3cK019sKhQUkvJvbOj9GaRw-- Received: from [174.48.128.27] by web121603.mail.ne1.yahoo.com via HTTP; Mon, 07 Jan 2013 13:41:16 PST X-Rocket-MIMEInfo: 001.001, DQoNCi0tLSBPbiBNb24sIDEvNy8xMywgV2lsbGVtIEphbiBXaXRoYWdlbiA8d2p3QGRpZ2l3YXJlLm5sPiB3cm90ZToNCg0KPiBGcm9tOiBXaWxsZW0gSmFuIFdpdGhhZ2VuIDx3andAZGlnaXdhcmUubmw.DQo.IFN1YmplY3Q6IFJlOiBrZXJuLzE3NDg1MTogW2J4ZV0gW3BhdGNoXSBVRFAgY2hlY2tzdW0gb2ZmbG9hZCBpcyB3cm9uZyBpbiBieGUgZHJpdmVyDQo.IFRvOiAiQmFybmV5IENvcmRvYmEiIDxiYXJuZXlfY29yZG9iYUB5YWhvby5jb20.DQo.IENjOiAiR2FycmV0dCBDb29wZXIiIDx5YW5lZ29taUABMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.130.494 Message-ID: <1357594876.61921.YahooMailClassic@web121603.mail.ne1.yahoo.com> Date: Mon, 7 Jan 2013 13:41:16 -0800 (PST) From: Barney Cordoba Subject: Re: kern/174851: [bxe] [patch] UDP checksum offload is wrong in bxe driver To: Willem Jan Withagen In-Reply-To: <50EA8558.4010600@digiware.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Garrett Cooper , freebsd-net@freebsd.org, Adrian Chadd , David Christensen , linimon@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 07 Jan 2013 21:41:24 -0000 --- On Mon, 1/7/13, Willem Jan Withagen wrote: > From: Willem Jan Withagen > Subject: Re: kern/174851: [bxe] [patch] UDP checksum offload is wrong in = bxe driver > To: "Barney Cordoba" > Cc: "Garrett Cooper" , freebsd-net@freebsd.org, "Adri= an Chadd" , "David Christensen" , = linimon@freebsd.org > Date: Monday, January 7, 2013, 3:20 AM > On 2013-01-05 16:17, Barney Cordoba > wrote: > >=20 > >=20 > > --- On Fri, 1/4/13, Willem Jan Withagen > wrote: > >=20 > >> From: Willem Jan Withagen > >> Subject: Re: kern/174851: [bxe] [patch] UDP > checksum offload is wrong in bxe driver > >> To: "Barney Cordoba" > >> Cc: "Garrett Cooper" , > freebsd-net@freebsd.org, > "Adrian Chadd" , > "David Christensen" , > linimon@freebsd.org > >> Date: Friday, January 4, 2013, 9:41 AM > >> On 2013-01-01 0:04, Barney Cordoba > >> wrote: > >> > >>> The statement above "assumes" that there is a > benefit. > >> voIP packets=20 > >>> are short, so the benefit of offloading is > reduced. > >> There is some > >>> delay added by the hardware, and there are cpu > cycles > >> used in managing > >>> the offload code. So those operations not only > muddy > >> the code, > >>> but they may not be faster than simply doing > the > >> checksum on a much, much > >>> faster cpu. > >> > >> Forgoing all the discussions on performance and > possible > >> penalties in > >> drivers..... > >> > >> I think there is a large set of UDP streams (and > growing) > >> that do use > >> larger packets. > >> > >> The video streaming we did used a size of > header(14)+7*188, > >> which is the > >> max number of MPEG packet to fit into anything with > an MTU > >> < 1500. > >> > >> Receiving those on small embedded devices which can > do HW > >> check-summing > >> is very beneficial there. > >> On the large servers we would generate up to 5Gbit > of > >> outgoing streams. > >> I'm sure that offloading UDP checks would be an > advantage as > >> well. > >> (They did run mainly Linux, but FreeBSD would also > work) > >> > >> Unfortunately most of the infrastructure has been > taken > >> down, so it is > >> no longer possible to verify any of the > assumptions. > >> > >> --WjW > >=20 > > If you haven't benchmarked it, then you're just > guessing. That's my point. > >=20 > > Its like SMP in freeBSD 4. People bought big, honking > machines and the > > big expensive machines were slower than a single core > system at less than > > half the price. Just because something sounds better > doesn't mean that it is better. >=20 > I completely agree.... >=20 > Dutch proverb goes: > =A0=A0=A0 "To measure is to know" > Which was the subtitle of my graduation report, and my > professional > motto when working as a systems-architect.... >=20 > That's why it is sad that the system is no longer up and > running, > because a 0-order check would be no more that 1 ifconfig > would have made > a difference. >=20 > But that is all water under the bridge. >=20 > --WjW You can't really benchmark on a live network; you need a control. It's easy enough to generate controlled UDP streams. And of course every NIC would be a new deal. I'm sure that UDP offload is a checklist feature and not something that the intels and broadcoms of the world do a lot of=20 performance testing for. BC From owner-freebsd-net@FreeBSD.ORG Mon Jan 7 23:29:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 66265B27; Mon, 7 Jan 2013 23:29:02 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) by mx1.freebsd.org (Postfix) with ESMTP id C620FCF5; Mon, 7 Jan 2013 23:29:01 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 47DEA153434; Tue, 8 Jan 2013 00:28:59 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-4u9muI6643; Tue, 8 Jan 2013 00:28:58 +0100 (CET) Received: from [192.168.10.120] (10G [192.168.10.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPS id 36616153433; Tue, 8 Jan 2013 00:28:58 +0100 (CET) References: <1357594876.61921.YahooMailClassic@web121603.mail.ne1.yahoo.com> In-Reply-To: <1357594876.61921.YahooMailClassic@web121603.mail.ne1.yahoo.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Willem Jan Withagen Subject: Re: kern/174851: [bxe] [patch] UDP checksum offload is wrong in bxe driver Date: Tue, 8 Jan 2013 00:29:05 +0100 To: Barney Cordoba Cc: Garrett Cooper , "freebsd-net@freebsd.org" , Adrian Chadd , David Christensen , "linimon@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 07 Jan 2013 23:29:02 -0000 Op 7 jan. 2013 om 22:41 heeft Barney Cordoba het v= olgende geschreven: >=20 >=20 > --- On Mon, 1/7/13, Willem Jan Withagen wrote: >=20 >> From: Willem Jan Withagen >> Subject: Re: kern/174851: [bxe] [patch] UDP checksum offload is wrong in b= xe driver >> To: "Barney Cordoba" >> Cc: "Garrett Cooper" , freebsd-net@freebsd.org, "Adri= an Chadd" , "David Christensen" , l= inimon@freebsd.org >> Date: Monday, January 7, 2013, 3:20 AM >> On 2013-01-05 16:17, Barney Cordoba >> wrote: >>>=20 >>>=20 >>> --- On Fri, 1/4/13, Willem Jan Withagen >> wrote: >>>=20 >>>> From: Willem Jan Withagen >>>> Subject: Re: kern/174851: [bxe] [patch] UDP >> checksum offload is wrong in bxe driver >>>> To: "Barney Cordoba" >>>> Cc: "Garrett Cooper" , >> freebsd-net@freebsd.org, >> "Adrian Chadd" , >> "David Christensen" , >> linimon@freebsd.org >>>> Date: Friday, January 4, 2013, 9:41 AM >>>> On 2013-01-01 0:04, Barney Cordoba >>>> wrote: >>>>=20 >>>>> The statement above "assumes" that there is a >> benefit. >>>> voIP packets=20 >>>>> are short, so the benefit of offloading is >> reduced. >>>> There is some >>>>> delay added by the hardware, and there are cpu >> cycles >>>> used in managing >>>>> the offload code. So those operations not only >> muddy >>>> the code, >>>>> but they may not be faster than simply doing >> the >>>> checksum on a much, much >>>>> faster cpu. >>>>=20 >>>> Forgoing all the discussions on performance and >> possible >>>> penalties in >>>> drivers..... >>>>=20 >>>> I think there is a large set of UDP streams (and >> growing) >>>> that do use >>>> larger packets. >>>>=20 >>>> The video streaming we did used a size of >> header(14)+7*188, >>>> which is the >>>> max number of MPEG packet to fit into anything with >> an MTU >>>> < 1500. >>>>=20 >>>> Receiving those on small embedded devices which can >> do HW >>>> check-summing >>>> is very beneficial there. >>>> On the large servers we would generate up to 5Gbit >> of >>>> outgoing streams. >>>> I'm sure that offloading UDP checks would be an >> advantage as >>>> well. >>>> (They did run mainly Linux, but FreeBSD would also >> work) >>>>=20 >>>> Unfortunately most of the infrastructure has been >> taken >>>> down, so it is >>>> no longer possible to verify any of the >> assumptions. >>>>=20 >>>> --WjW >>>=20 >>> If you haven't benchmarked it, then you're just >> guessing. That's my point. >>>=20 >>> Its like SMP in freeBSD 4. People bought big, honking >> machines and the >>> big expensive machines were slower than a single core >> system at less than >>> half the price. Just because something sounds better >> doesn't mean that it is better. >>=20 >> I completely agree.... >>=20 >> Dutch proverb goes: >> "To measure is to know" >> Which was the subtitle of my graduation report, and my >> professional >> motto when working as a systems-architect.... >>=20 >> That's why it is sad that the system is no longer up and >> running, >> because a 0-order check would be no more that 1 ifconfig >> would have made >> a difference. >>=20 >> But that is all water under the bridge. >>=20 >> --WjW >=20 > You can't really benchmark on a live network; you need a control. It's > easy enough to generate controlled UDP streams. And of course every NIC > would be a new deal. I'm sure that UDP offload is a checklist feature and > not something that the intels and broadcoms of the world do a lot of=20 > performance testing for. We did have a 10gb test environment, as lab. That was what i ment when i said, too bad IT is no longer up and running. ATM i can't even get to the hardware. >=20 But you are right, UDP has always been the stepchild of the industry. I've seen some real bad router UDP implementations while testing consumer r= outers. And don't get me started on fragmented UDP, that is like running the lottery= . --WjW= From owner-freebsd-net@FreeBSD.ORG Tue Jan 8 02:26:01 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 09E3B513 for ; Tue, 8 Jan 2013 02:26:01 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm28-vm0.bullet.mail.ne1.yahoo.com (nm28-vm0.bullet.mail.ne1.yahoo.com [98.138.91.22]) by mx1.freebsd.org (Postfix) with ESMTP id 77C5E34D for ; Tue, 8 Jan 2013 02:25:59 +0000 (UTC) Received: from [98.138.226.179] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jan 2013 02:25:59 -0000 Received: from [98.138.226.169] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jan 2013 02:25:59 -0000 Received: from [127.0.0.1] by omp1070.mail.ne1.yahoo.com with NNFMP; 08 Jan 2013 02:25:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 181510.67102.bm@omp1070.mail.ne1.yahoo.com Received: (qmail 92793 invoked by uid 60001); 8 Jan 2013 02:25:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1357611958; bh=CJLDDtx7HUx31pGxVygwUAadE6FfqMLnrnFlsRqegS0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=rBn9/nB+7WiGklpIa2ska9Dl03uRzzeUUYJn7YnGPtx83t79FyD7rzjvFKOKyIdETcRW2dX73jplZ3xplXc0hQswQezMfYO5AdBVUA4OESD90NhSk8rhM9dw9pI3A29rfDeNrpR+3hveujqkPX3/KvVBcZoG0wInoCSX+OFoCaM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=RyZiq9l8tR6SmNBbMbI+QxSgk8XuZbx4SvLimDyZoK/XVdMZcFi0xOO7yO+74YOsqEgnuBWtgAbkE15StNn5vqrbSexRmDTYITJ9VaBJYKcVvkw/jYa0O1xQSMI+tbqR74W7thC0A8gMPeovy+b/qR87OujcltJ+0whZrpHxS/E=; X-YMail-OSG: w0aQv_cVM1nMz78HptFFtgqjoPJs0JYziT5keMO7XWGN1SL NRIzXtAVeJO7y8RtB.I191.HOoNvCSYmBSiCH3uU18v7zRkUGowRG64I8j7J pYxXmGh1gvoLnF3GD6TVkqXetFJJBHauUIbs3xpCB14D3KrvFFDSvLgZrwiY RGpCUd8AITplP8Pq.vMPY7Y33Lab9DwvyuL_C1i6OcuwD_lF0.uDXMagoS8S 99gvz1pfiGa9cE_AGD4yuWXXMsFIdLW_dZc4Ss8ZkdZ3Z7E3byo6oPtqqzn3 YwxQ.NVo7iKgAjDtoSzgmjqkggZ9FYW16qoE9Fq1uGdiJqyT0tSyaYkM10.d qlTADJlXCDPSot7RumfleTfS6ge07BsaONyvO3fDbvT15jLRqLW.oRNz2m32 uOhx._XSKe7AFX5njSKJKQCh9B9f4PtPOYHEPZtL6Rn1hWT5xrSzJiNiAYBk JlVkgKBpQneaAtxWxxbY25VStUWZXat3wp5HKGE1UfIBDyKYoy3u9OyOzjhi UkEePpQ-- Received: from [174.48.128.27] by web121603.mail.ne1.yahoo.com via HTTP; Mon, 07 Jan 2013 18:25:58 PST X-Rocket-MIMEInfo: 001.001, SSBoYXZlIGEgc2l0dWF0aW9uIHdoZXJlIEkgaGF2ZSB0byBydW4gOS4xIG9uIGFuIG9sZCBzaW5nbGUgY29yZSBib3guIERvZXMgYW55b25lIGhhdmUgYSBoYW5kbGUgb24gd2hldGhlciBpdCdzIGJldHRlciB0byBidWlsZCBhIG5vbiBTTVAga2VybmVsIG9yIHRvIGp1c3QgdXNlIGEgc3RhbmRhcmQgU01QIGJ1aWxkIHdpdGgganVzdCB0aGUgb25lIGNvcmU_IFRoYW5rcy4KCkJDATABAQEB X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.130.494 Message-ID: <1357611958.66651.YahooMailClassic@web121603.mail.ne1.yahoo.com> Date: Mon, 7 Jan 2013 18:25:58 -0800 (PST) From: Barney Cordoba Subject: To SMP or not to SMP To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jan 2013 02:26:01 -0000 I have a situation where I have to run 9.1 on an old single core box. Does anyone have a handle on whether it's better to build a non SMP kernel or to just use a standard SMP build with just the one core? Thanks. BC From owner-freebsd-net@FreeBSD.ORG Tue Jan 8 02:39:09 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 594AD8E0 for ; Tue, 8 Jan 2013 02:39:09 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by mx1.freebsd.org (Postfix) with ESMTP id 36B443EA for ; Tue, 8 Jan 2013 02:39:09 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id bj3so21806pad.0 for ; Mon, 07 Jan 2013 18:39:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=0SMOpzWM3dsStXvEl3b0FZ98feAym7Od+CZLnl/ITtI=; b=RVFU3rb/WzuhIg2yA/sTgaVGh5Y+BFZ33u6eG1mPv01QCVldaRZIsK7xz2iLUw4sta qll1zAg9vr6tbuQm6BkfYQhnN/z4ByKYdPpqFVeimesEUU0SuatOSbCzEjspmx7nbf0X PHlbCmfjMypgEoipyl1tTay7/O1Rkvo5WMd39a8VE38G2jrWzePK91wHPt1ifUyZD0BD +GiidW7XzN0FQZeEAoPeocHpxoOd+MUBFzGCybHArw51f3mw8wSSCVCj+/M35R8SMGpx +RXZl1Ezjt+M8Bi9Fm9kmy/iujyhAf4hDjrvuJBj4ciuaZQz0yvKmcHP4pZLD0tQwWPg NZaA== X-Received: by 10.68.190.227 with SMTP id gt3mr194436912pbc.5.1357612743601; Mon, 07 Jan 2013 18:39:03 -0800 (PST) Received: from [192.168.242.58] (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by mx.google.com with ESMTPS id y9sm4156904paw.1.2013.01.07.18.38.59 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Jan 2013 18:39:02 -0800 (PST) Subject: Re: To SMP or not to SMP Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <1357611958.66651.YahooMailClassic@web121603.mail.ne1.yahoo.com> Date: Mon, 7 Jan 2013 18:38:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1357611958.66651.YahooMailClassic@web121603.mail.ne1.yahoo.com> To: Barney Cordoba X-Mailer: Apple Mail (2.1283) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jan 2013 02:39:09 -0000 On Jan 7, 2013, at 6:25 PM, Barney Cordoba wrote: > I have a situation where I have to run 9.1 on an old single core box. = Does anyone have a handle on whether it's better to build a non SMP = kernel or to just use a standard SMP build with just the one core? = Thanks. Non-SMP. I don't see why it would be wise to involve the = standard locking structure overhead for a single-core box. Cheers, -Garrett= From owner-freebsd-net@FreeBSD.ORG Tue Jan 8 03:02:36 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7B5FA15B for ; Tue, 8 Jan 2013 03:02:36 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm19.bullet.mail.ne1.yahoo.com (nm19.bullet.mail.ne1.yahoo.com [98.138.90.82]) by mx1.freebsd.org (Postfix) with ESMTP id 23B83760 for ; Tue, 8 Jan 2013 03:02:35 +0000 (UTC) Received: from [98.138.90.48] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jan 2013 02:59:14 -0000 Received: from [98.138.89.161] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jan 2013 02:59:14 -0000 Received: from [127.0.0.1] by omp1017.mail.ne1.yahoo.com with NNFMP; 08 Jan 2013 02:59:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 394299.12815.bm@omp1017.mail.ne1.yahoo.com Received: (qmail 19743 invoked by uid 60001); 8 Jan 2013 02:59:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1357613954; bh=tkIwZd2JCysSPI1A/PWltQQm64GwN8F7LmYry1VPyFY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=n3pW9gZNs//KPcYycwXcrykxoCJDp5+MbqTttsYo+kkcTY+5m2RKm7S74eOzYIKw8OC+Bk2iS1UZBYwbQT51G00f049oIIc9f98gyy1vuzrBaQ0W+YgM9LJZj7AEKBrlgKUsOYf0FFFF1HsN9RBo5OyoTj0AApYLW3ff6kBDTi0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=LpAAem+peBIxjumrTmHO+bVc21ZY+DgFPvGUsTe5e38jXXSTey/hEUEWrr/J4j2MxSCWsptJ4mHrFxM4xyajhFQ3B2OKdjgztEGaH3FdkzO6kLbsF1fpeKxyPMlTJBgdJ8HhY6Yvp3v9Xn3FvAPR0589N5mmwur4Jsf4mwog5OQ=; X-YMail-OSG: a_B10iIVM1kSyanuW9s4zGe2gqdmVOXgyKpMaHT9gwyJMW_ lhVeskhfmJ6PKvGgP32rJ6RuDO1M9.2R5YPg8OgbepDfW12VNEun4koXPHJ3 qEc3xbm5ykGhi0U21reua5XSJXBB68Pq.WBRx4ehoKpPepBfvj6nNyMEDlrd F745EKy7ljD8w5c7KgbKAhtivXC5UZ1aIZPlgAEZ3vmemjodIue.Xzsg83P7 OokHtYg29_jtLr2B007s0hLvWlc722zdd1WhxsjH4MeOZ92fiQ7sQ_ebqZjQ M5iRK9EKiGXzBB5cXAimj9Zsk9h.xveatL6kZu.l6UfWwhFmQyCcYrUMXUkl X.0nmQ2N11KIGny8HTqH3owHE21EdsS7zIMz6pMVeezpWIq.e6znYfIOJEa4 92pwws.l6QltTb.cZRwDS_bpgmWfa1rardnouN.irqKuqGgiPk0Uj9UMqurS kTDKaNKkcthyM03.OeanOE3lZ0UCamqEZEJFVqSeUrIFZyLWqtzTdNYFRG.N 7FshlL4p42bTjegG2CdRefIfLTDO.nQ-- Received: from [174.48.128.27] by web121604.mail.ne1.yahoo.com via HTTP; Mon, 07 Jan 2013 18:59:14 PST X-Rocket-MIMEInfo: 001.001, CgotLS0gT24gTW9uLCAxLzcvMTMsIEdhcnJldHQgQ29vcGVyIDx5YW5lZ29taUBnbWFpbC5jb20.IHdyb3RlOgoKPiBGcm9tOiBHYXJyZXR0IENvb3BlciA8eWFuZWdvbWlAZ21haWwuY29tPgo.IFN1YmplY3Q6IFJlOiBUbyBTTVAgb3Igbm90IHRvIFNNUAo.IFRvOiAiQmFybmV5IENvcmRvYmEiIDxiYXJuZXlfY29yZG9iYUB5YWhvby5jb20.Cj4gQ2M6IGZyZWVic2QtbmV0QGZyZWVic2Qub3JnCj4gRGF0ZTogTW9uZGF5LCBKYW51YXJ5IDcsIDIwMTMsIDk6MzggUE0KPiBPbiBKYW4gNywgMjAxMywgYXQgNjoBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.130.494 Message-ID: <1357613954.19271.YahooMailClassic@web121604.mail.ne1.yahoo.com> Date: Mon, 7 Jan 2013 18:59:14 -0800 (PST) From: Barney Cordoba Subject: Re: To SMP or not to SMP To: Garrett Cooper In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jan 2013 03:02:36 -0000 =0A=0A--- On Mon, 1/7/13, Garrett Cooper wrote:=0A=0A>= From: Garrett Cooper =0A> Subject: Re: To SMP or not t= o SMP=0A> To: "Barney Cordoba" =0A> Cc: freebsd-n= et@freebsd.org=0A> Date: Monday, January 7, 2013, 9:38 PM=0A> On Jan 7, 201= 3, at 6:25 PM, Barney=0A> Cordoba wrote:=0A> =0A> > I have a situation wher= e I have to run 9.1 on an old=0A> single core box. Does anyone have a handl= e on whether it's=0A> better to build a non SMP kernel or to just use a sta= ndard=0A> SMP build with just the one core? Thanks.=0A> =0A> =A0=A0=A0 Non-= SMP. I don't see why it would be wise=0A> to involve the standard locking s= tructure overhead for a=0A> single-core box.=0A=0AIt might not be wise, but= I'd guess that 99% of the development work=0Ais being done on SMP systems,= so who knows what weirdness non-smp=0Asystems might have.=0A=0ABC From owner-freebsd-net@FreeBSD.ORG Tue Jan 8 03:56:52 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 01D7F793 for ; Tue, 8 Jan 2013 03:56:51 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id 862FA8CF for ; Tue, 8 Jan 2013 03:56:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=4CiQiL+cXXtnmKlMPoQkCXOmEsQTsTvMpJrThd3UyYU=; b=XbxA7SJhQMZyhezPbaR0wC3nfWD1/KIAzXA2CK/Awr7hq5Rm58tnc9pSnhrxdOgeRpLKNRj4ZOeWLdXNXtHUxUUeeUMPvWwvN2NCsaDcGhBI/dTgX2HNQYswerHrVkwN; Received: from [122.129.203.50] (port=31207 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TsQIt-00276I-As; Mon, 07 Jan 2013 20:56:43 -0700 Date: Tue, 8 Jan 2013 10:56:38 +0700 From: Erich Dollansky To: Barney Cordoba Subject: Re: To SMP or not to SMP Message-ID: <20130108105638.7ef9d6c2@X220.ovitrap.com> In-Reply-To: <1357611958.66651.YahooMailClassic@web121603.mail.ne1.yahoo.com> References: <1357611958.66651.YahooMailClassic@web121603.mail.ne1.yahoo.com> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jan 2013 03:56:52 -0000 Hi, On Mon, 7 Jan 2013 18:25:58 -0800 (PST) Barney Cordoba wrote: > I have a situation where I have to run 9.1 on an old single core box. > Does anyone have a handle on whether it's better to build a non SMP > kernel or to just use a standard SMP build with just the one core? > Thanks. I ran a single CPU version of FreeBSD until my last single CPU got hit by a lightning last April or May without any problems. I never saw a reason to include the overhead of SMP for this kind of machine and I also never ran into problems with this. Erich From owner-freebsd-net@FreeBSD.ORG Tue Jan 8 06:02:43 2013 Return-Path: Delivered-To: FreeBSD-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 90B08549 for ; Tue, 8 Jan 2013 06:02:43 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 3B560CC8 for ; Tue, 8 Jan 2013 06:02:39 +0000 (UTC) Received: from mr16.lnh.mail.rcn.net ([207.172.157.36]) by smtp02.lnh.mail.rcn.net with ESMTP; 08 Jan 2013 01:02:39 -0500 Received: from smtp04.lnh.mail.rcn.net (smtp04.lnh.mail.rcn.net [207.172.157.104]) by mr16.lnh.mail.rcn.net (MOS 4.3.4-GA) with ESMTP id CEF21851; Tue, 8 Jan 2013 01:02:38 -0500 X-Auth-ID: anat Received: from pool-173-70-92-11.nwrknj.fios.verizon.net (HELO [192.168.1.8]) ([173.70.92.11]) by smtp04.lnh.mail.rcn.net with ESMTP; 08 Jan 2013 01:02:38 -0500 Message-ID: <50EBB67E.3040704@aldan.algebra.com> Date: Tue, 08 Jan 2013 01:02:38 -0500 From: "Mikhail T." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120820 Thunderbird/14.0 MIME-Version: 1.0 To: FreeBSD-net@FreeBSD.org Subject: smbfs slow compared to smbclient Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Boris Popov , Tom Pepper X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jan 2013 06:02:43 -0000 Hello! I found this same question asked back in 2005, but never answered: http://lists.freebsd.org/pipermail/freebsd-questions/2005-September/098717.html Today, 7 years later, using FreeBSD-9.1 I observe, that copying a file to an SMB-server (a box with embedded Linux, actually), I get just under 1Mb/s using an smbfs mount. On contrast, uploading the same file to the same remote host using smbclient runs at between 8 and 9 Mb/s. Is this a known discrepancy? Are there tweaks to be applied to the smbfs mount, that can make it perform better? Thanks! Yours, -mi From owner-freebsd-net@FreeBSD.ORG Tue Jan 8 06:14:21 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 36417636; Tue, 8 Jan 2013 06:14:21 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id F04BFD04; Tue, 8 Jan 2013 06:14:20 +0000 (UTC) Received: from Xins-MacBook-Pro-2.local (unknown [IPv6:2001:470:83bf:0:fde3:6b6f:53d:dc1a]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 6C50D1FDC7; Mon, 7 Jan 2013 22:14:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1357625660; bh=uLLSAdeAOtEKdK+P87xJDpN3nXAlUDa5WRKDUlkvIcU=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=krGJqOZHx3lY7E36walayarIYEiA38ew+TO5jMW77MFU319detfC9xzcSvkuNs5Uo E3JOYiL3eLTyaFvTFO+JACcZTOUi82pgWnyxHznkHsWewMAKwKvBrFQzB5N5yxoOs5 IgLzuzzBMeKC9lq6zpu4CjfykGnA+49YSJKx/5/c= Message-ID: <50EBB93C.8000709@delphij.net> Date: Mon, 07 Jan 2013 22:14:20 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: smbfs slow compared to smbclient References: <50EBB67E.3040704@aldan.algebra.com> In-Reply-To: <50EBB67E.3040704@aldan.algebra.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Davide Italiano X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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: Tue, 08 Jan 2013 06:14:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 1/7/13 10:02 PM, Mikhail T. wrote: > Hello! > > I found this same question asked back in 2005, but never answered: > > > http://lists.freebsd.org/pipermail/freebsd-questions/2005-September/098717.html > > > > Today, 7 years later, using FreeBSD-9.1 I observe, that copying a > file to an SMB-server (a box with embedded Linux, actually), I get > just under 1Mb/s using an smbfs mount. > > On contrast, uploading the same file to the same remote host using > smbclient runs at between 8 and 9 Mb/s. > > Is this a known discrepancy? Are there tweaks to be applied to the > smbfs mount, that can make it perform better? Thanks! Yours, I think this is a known issue. Davide (cc'ed) had worked on smbfs recently and eliminated Giant on smbfs dependencies so I think he would have a lot of saying on this.. Cheers, -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJQ67k8AAoJEG80Jeu8UPuzQBAH/jf0FY8EZ+BD+4KKqrpaTmG9 WftAGmnByHUat8OBtb6+Sztkpr14VWcxYNcytTbqH6zMBgeA7koJtuzO8JVpxMM9 Btno2TJkL9zUKC6fkHs5Zd14TNJ/v29CE+6ooQbC4K791PaMcg2vP++Ce9EXmqkA Pew/3846rjhdY0H7weNDtz3G/XBCXEP0i2kq3PH5E9dvazIIXMa3z7KMs4935I29 /PBrNGnaxbXyxUqvLQGlxnR8BZKCewH8camhSNUlbb3gkghug74fwbRw/v8HFZcj SUOV/6ujhcjzmHCGAJsQ+WysCqJb7hFEUOZXbXEEOvmh4Nsm5f4P9JPauv6xs+I= =bZ2X -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Tue Jan 8 12:47:10 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8548F2B7; Tue, 8 Jan 2013 12:47:10 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1296EEA5; Tue, 8 Jan 2013 12:47:09 +0000 (UTC) Received: from MightyAtom.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id r08ChBT2054352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jan 2013 12:43:12 GMT Date: Tue, 08 Jan 2013 12:42:30 +0000 From: Karl Pielorz To: Gleb Smirnoff Subject: Re: Arp table size - any adjustments? Message-ID: <1AAC1452A561ABA2C6309047@MightyAtom.tdx.co.uk> In-Reply-To: <20121213113333.GT97487@FreeBSD.org> References: <523DE5571B5BE81B8BA1846F@MightyAtom.tdx.co.uk> <20121213113333.GT97487@FreeBSD.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jan 2013 12:47:10 -0000 --On 13 December 2012 15:33 +0400 Gleb Smirnoff wrote: > Nope, there is no autotuning here yet. > > The hash table size is hardcoded in sys/net/if_llatbl.h. The name of > constant is LLTBL_HASHTBL_SIZE. Default is 32, which is even commented with "/* default 32 ? */" - I found another thread via Google which discussed upping this to 512 for a 'Generic Box' For a router that has 4k+ ARP entries, any recommendations? - e.g. 1024? / 2048? 2048 seems sensible considering the other thread recommended it should be 1/4 the table size (so, 4k entries in arp table = 2k hash?) or even 4k to cover expansion. -Karl From owner-freebsd-net@FreeBSD.ORG Tue Jan 8 14:45:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 62118C51; Tue, 8 Jan 2013 14:45:02 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by mx1.freebsd.org (Postfix) with ESMTP id 2F9CE686; Tue, 8 Jan 2013 14:45:02 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id c10so554502ieb.25 for ; Tue, 08 Jan 2013 06:44:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2mE4DGCuWJd5YLeI5VG6lmZKM0mm6grd5LcQmBfj+Gw=; b=OasCVaHoGTk8DMD6NWkOoy17vqIO86jP3tIUoDvOt7ikvoL6AxaH1uzsUW07f4uRPb aQDlf+t8WW+Yn+2KbYOkEXRgMNJIg1hcrQg1YZLfYwqFYlvbgF3pJ4HowygZd3Fuh8aQ GH+AoRXzzlJIBmO1EqAVdIqxtYz1/3rQEZuqc/C/QPMrVIBPDJ4T8C2PncgfGtqduEQ2 AqWZk7192cTe/cGDB0Z0LWQS4I/xXSqQ0MbrRBDmMqdmCCHxt4Bm7qtVynuHqQgLz/h2 tNPpow91ELBBSvfsf/CGbPOx9XTEI4tVf5y4qDofpzs37qSHEJY1IXu324pDZff56fYX D0zA== MIME-Version: 1.0 Received: by 10.50.222.226 with SMTP id qp2mr9328671igc.103.1357656295255; Tue, 08 Jan 2013 06:44:55 -0800 (PST) Received: by 10.64.51.98 with HTTP; Tue, 8 Jan 2013 06:44:55 -0800 (PST) Received: by 10.64.51.98 with HTTP; Tue, 8 Jan 2013 06:44:55 -0800 (PST) Date: Tue, 8 Jan 2013 16:44:55 +0200 Message-ID: Subject: firewall rules for core router From: Sami Halabi To: freebsd-ipfw , freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jan 2013 14:45:02 -0000 Anh one? =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 7 =D7=91=D7=99=D7=A0=D7=95 2013 18:09,= =D7=9E=D7=90=D7=AA "Sami Halabi" : > Hi, > i have a core router that i want to enable firewall on it. > is these enough for a start: > > ipfw add 100 allow all from any to any via lo0 > ipfw add 25000 allow all from me to any > ipfw add 25100 allow ip from "table(7)" to me dst-port 179 > #ipfw add 25150 allow ip from "table(7)" to me > ipfw add 25200 allow ip from "table(8)" to me dst-port 161 > #ipfw add 25250 allow ip from "table(8)" to me > ipfw add 25300 allow all from any to me dst-port 22 > ipfw add 25400 allow icmp from any to any > ipfw add 25500 deny all from any to me > ipfw add 230000 allow all from any to any > > while table-7 are my BGP peers, table-8 my NMS. > > do i need to open anything more? any routing protocol/forwarding plan > issues? > > > another thing: > i plan to add the following rule > ipfw add 26000 fwd w.x.y.z all from a.b.c.0/24 to any > > will this work?, does my peer (ISP, with Cisco/Juniper equipment) needs t= o > do anything else? > Thanks in advance, > > -- > Sami Halabi > Information Systems Engineer > NMS Projects Expert > FreeBSD SysAdmin Expert > From owner-freebsd-net@FreeBSD.ORG Tue Jan 8 15:53:15 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 67A62426 for ; Tue, 8 Jan 2013 15:53:15 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm14-vm2.bullet.mail.ne1.yahoo.com (nm14-vm2.bullet.mail.ne1.yahoo.com [98.138.91.90]) by mx1.freebsd.org (Postfix) with ESMTP id 0B5989A7 for ; Tue, 8 Jan 2013 15:53:13 +0000 (UTC) Received: from [98.138.90.51] by nm14.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jan 2013 15:50:52 -0000 Received: from [98.138.87.10] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jan 2013 15:50:52 -0000 Received: from [127.0.0.1] by omp1010.mail.ne1.yahoo.com with NNFMP; 08 Jan 2013 15:50:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 719022.62354.bm@omp1010.mail.ne1.yahoo.com Received: (qmail 43472 invoked by uid 60001); 8 Jan 2013 15:50:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1357660252; bh=zhWKIh/V2UQ6hPaT+FXi+UtHXs9AgrBKqnJnfXBFfbM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=QUgWFIK1qor+2i6PR0rmSoAlfxJpqfvtk980gFia4FmupLNRwQCg5hio0rYbLayhaMLkJyR8IhQThfsRv1lflBzyiXRYrGBpBpk0907VpwSHrAtNRgWzCuaDR3VpnKoogo8IaVeSdzsVHrCUOctx0u8PgVQFTChF40txm6uMUpE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=FtfgxuKv+cwyeNBMGulwilXVxE2Nnim+gMCkrD5R028RQiBAE134up2vfBMAUwB2DMo/HNcUt0YfORK1M11QsSBEda/7X/6ewPXfaATcsw5T1kdPJh72SuLVouvMcahUxwK3f8HLg/NNRla7hXLUwH76CCY7PNqD/FXl/2KBSpE=; X-YMail-OSG: I.n5MlgVM1khNJzgFP_HYLtRUU9fiuQhvs468ZmwUQan4no AhMdUnF5uA_r0bR7tYcAArlj4.izjuRlAC3h7x7ey1LJHRo6T4bTjoWf9WYE xZsXTdi0JNMhnY9v.sxEg2b43WFlMSlw87YdfLeZ.190374goCjXtyDKZp1K lnMkCwJsXO5HUetosqwHCEWQvOluBVoPBqdG19HxGqWZtTortOKiZKkBdXRC Imi_tkkbbxBMcTjIafyn.FYYn3PKgUnUH5wnAuSG6PecpulKtKrBdNfi6qCL wRy9dPYefqy5C8_l3mV0oITQ1Hwop_BlHT.UKfaMoya0Y9VDrCrHEerEADA7 Xib.kecjSTuMoJqMh2jWL1YJPMxeWkl6_Yu9UfbvOoA_451YZJBCGVK2gp9I lXBAHjxOsqj2_ufmpEz.22nob5ZT8P61a944FYNzgQJBkA1FNaPzWNpnjzh8 HoJLKximc0uooFlkwtgOa1YqX3K3qq_dt09sxG6Jz9hIuzFndVSqRui1cii_ 3yHbL8HNAFNH6TPc2ooIJ6le2K0akXg-- Received: from [174.48.128.27] by web121603.mail.ne1.yahoo.com via HTTP; Tue, 08 Jan 2013 07:50:52 PST X-Rocket-MIMEInfo: 001.001, CgotLS0gT24gTW9uLCAxLzcvMTMsIEVyaWNoIERvbGxhbnNreSA8ZXJpY2hzZnJlZWJzZGxpc3RAYWxvZ3QuY29tPiB3cm90ZToKCj4gRnJvbTogRXJpY2ggRG9sbGFuc2t5IDxlcmljaHNmcmVlYnNkbGlzdEBhbG9ndC5jb20.Cj4gU3ViamVjdDogUmU6IFRvIFNNUCBvciBub3QgdG8gU01QCj4gVG86ICJCYXJuZXkgQ29yZG9iYSIgPGJhcm5leV9jb3Jkb2JhQHlhaG9vLmNvbT4KPiBDYzogZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmcKPiBEYXRlOiBNb25kYXksIEphbnVhcnkgNywgMjAxMywgMTA6NTYgUE0KPiABMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.130.494 Message-ID: <1357660252.29936.YahooMailClassic@web121603.mail.ne1.yahoo.com> Date: Tue, 8 Jan 2013 07:50:52 -0800 (PST) From: Barney Cordoba Subject: Re: To SMP or not to SMP To: Erich Dollansky In-Reply-To: <20130108105638.7ef9d6c2@X220.ovitrap.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jan 2013 15:53:15 -0000 --- On Mon, 1/7/13, Erich Dollansky wrote: > From: Erich Dollansky > Subject: Re: To SMP or not to SMP > To: "Barney Cordoba" > Cc: freebsd-net@freebsd.org > Date: Monday, January 7, 2013, 10:56 PM > Hi, > > On Mon, 7 Jan 2013 18:25:58 -0800 (PST) > Barney Cordoba > wrote: > > > I have a situation where I have to run 9.1 on an old > single core box. > > Does anyone have a handle on whether it's better to > build a non SMP > > kernel or to just use a standard SMP build with just > the one core? > > Thanks. > > I ran a single CPU version of FreeBSD until my last single > CPU got hit > by a lightning last April or May without any problems. > > I never saw a reason to include the overhead of SMP for this > kind of > machine and I also never ran into problems with this. Another "ass"umption based on logic rather than empirical evidence. I think I'll test it. BC From owner-freebsd-net@FreeBSD.ORG Tue Jan 8 15:56:20 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 01DB450B for ; Tue, 8 Jan 2013 15:56:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by mx1.freebsd.org (Postfix) with ESMTP id 6F61C9D3 for ; Tue, 8 Jan 2013 15:56:18 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id 15so466307wgd.16 for ; Tue, 08 Jan 2013 07:56:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5i/Ifsmh3EwGheQ/eqFrAeDK2rbTjyWUwLI9e3k3Rg4=; b=VGuWBxRfdUAdlPAy8MXW2uN55oWiRYmCNILtsuI/dSPmlHrJaQqzFcLv1RFK136jXQ GchEF1NmcDpWQvDKOedV9orL9nWHYkdXGOq04E++psa+UAUyE97uZA2cPrj+9EsTMB85 ieU2pkmrcN83jywiZ9Ebcw/u5tmpEMOLWYY93SZy0Rv1gxXV156sbVo4HCJy1efyiMvT xbjU7HKdd8MvRVGFlq/hwHDXa1UrY8/CT8TEvt/OOFdK5frUOMHBEHK6UrZD7IIn5pLD r0vWCRzRHygWk+HKIe7dZL+Xgnne7GNc8rKMlNOOF+e3NMDfPc0w7rOWEa/sZAC/0xNt SHxw== MIME-Version: 1.0 Received: by 10.194.109.10 with SMTP id ho10mr11833536wjb.16.1357660570541; Tue, 08 Jan 2013 07:56:10 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Tue, 8 Jan 2013 07:56:10 -0800 (PST) In-Reply-To: <1357660252.29936.YahooMailClassic@web121603.mail.ne1.yahoo.com> References: <20130108105638.7ef9d6c2@X220.ovitrap.com> <1357660252.29936.YahooMailClassic@web121603.mail.ne1.yahoo.com> Date: Tue, 8 Jan 2013 07:56:10 -0800 X-Google-Sender-Auth: et2hhuv75J3n-ipwom22XB2815Y Message-ID: Subject: Re: To SMP or not to SMP From: Adrian Chadd To: Barney Cordoba Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Erich Dollansky X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jan 2013 15:56:20 -0000 The only weird crap I've seen with SMP versus non-SMP these days is some assumptions that it's cheap to alternate between two tasks in a preemptive kernel. That behaviour sucks on MIPS. On SMP machines with enough CPUs/hardware threads, you don't see the context switch overhead because you have enough CPUs to run them concurrently. But on single core MIPS boards, things aren't quite as shiny. (Yes, I'm working towards making net80211 and some of the wifi drivers enforce better behaviour in this regard. The network stack doesn't really "help" me here.) Adrian From owner-freebsd-net@FreeBSD.ORG Tue Jan 8 15:57:09 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9F38470A for ; Tue, 8 Jan 2013 15:57:09 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by mx1.freebsd.org (Postfix) with ESMTP id 7E0929E2 for ; Tue, 8 Jan 2013 15:57:09 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id bh2so408072pad.5 for ; Tue, 08 Jan 2013 07:57:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=IY/p7SCZr2j+chvaaN6Ws4GyRSeMhL8dZGXjBrqcljY=; b=XkG7Cv72vgYxYQLI/rChYsCg6TozQMWf8tQYWw9u0vuuDVZydLAl4lj+ptF9TpRuSt g2XX6KnhpKC4FmQv12TGlhHtz6fhV9fLbL1s9LB65y9ppjRd5PRIywJfKU3Q8odnvA/R UZMgbBWcwUoStAt5zPsQSgvoZV3Hi36GxGLDF++aYiIexcwIOz5QDvsNxlHucMQpjGZN zOtbC0LeU8vSJFz25uO3OGaWmsh11XpKwhNCHN3RxvKUh3k4JgWHqxVpC425kn2KIHga f7o2MbYJ2E5t4zv/n4VpUnUVzAAAsMljkf+QAN50Vo+hjXQUI62KRpB4YpD8fvDOpMTP tV7A== X-Received: by 10.68.192.97 with SMTP id hf1mr199323505pbc.106.1357660628753; Tue, 08 Jan 2013 07:57:08 -0800 (PST) Received: from [192.168.20.11] (c-24-19-191-56.hsd1.wa.comcast.net. [24.19.191.56]) by mx.google.com with ESMTPS id oi3sm39849448pbb.1.2013.01.08.07.57.06 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Jan 2013 07:57:06 -0800 (PST) Subject: Re: To SMP or not to SMP Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <1357660252.29936.YahooMailClassic@web121603.mail.ne1.yahoo.com> Date: Tue, 8 Jan 2013 07:57:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1357660252.29936.YahooMailClassic@web121603.mail.ne1.yahoo.com> To: Barney Cordoba X-Mailer: Apple Mail (2.1283) Cc: freebsd-net@freebsd.org, Erich Dollansky X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jan 2013 15:57:09 -0000 On Jan 8, 2013, at 7:50 AM, Barney Cordoba wrote: > --- On Mon, 1/7/13, Erich Dollansky = wrote: >=20 >> From: Erich Dollansky >> Subject: Re: To SMP or not to SMP >> To: "Barney Cordoba" >> Cc: freebsd-net@freebsd.org >> Date: Monday, January 7, 2013, 10:56 PM >> Hi, >>=20 >> On Mon, 7 Jan 2013 18:25:58 -0800 (PST) >> Barney Cordoba >> wrote: >>=20 >>> I have a situation where I have to run 9.1 on an old >> single core box. >>> Does anyone have a handle on whether it's better to >> build a non SMP >>> kernel or to just use a standard SMP build with just >> the one core? >>> Thanks. >>=20 >> I ran a single CPU version of FreeBSD until my last single >> CPU got hit >> by a lightning last April or May without any problems. >>=20 >> I never saw a reason to include the overhead of SMP for this >> kind of >> machine and I also never ran into problems with this. >=20 > Another "ass"umption based on logic rather than empirical evidence. It isn't really an offhanded assumption because there _is_ = additional overhead added into the kernel structures to make things work = SMP with locking :). Whether or not it's measurable for you and your = applications, I have no idea. HTH, -Garrett= From owner-freebsd-net@FreeBSD.ORG Tue Jan 8 16:30:14 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7A1E619B for ; Tue, 8 Jan 2013 16:30:14 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3BC47B40 for ; Tue, 8 Jan 2013 16:30:14 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Tsc4B-00006j-SH for freebsd-net@freebsd.org; Tue, 08 Jan 2013 17:30:19 +0100 Received: from 208.85.208.53 ([208.85.208.53]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 08 Jan 2013 17:30:19 +0100 Received: from atkin901 by 208.85.208.53 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 08 Jan 2013 17:30:19 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Mark Atkinson Subject: Re: To SMP or not to SMP Date: Tue, 08 Jan 2013 08:29:51 -0800 Lines: 20 Message-ID: References: <1357611958.66651.YahooMailClassic@web121603.mail.ne1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 208.85.208.53 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/17.0 Thunderbird/17.0 In-Reply-To: <1357611958.66651.YahooMailClassic@web121603.mail.ne1.yahoo.com> X-Enigmail-Version: 1.4.6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jan 2013 16:30:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/07/2013 18:25, Barney Cordoba wrote: > I have a situation where I have to run 9.1 on an old single core > box. Does anyone have a handle on whether it's better to build a > non SMP kernel or to just use a standard SMP build with just the > one core? Thanks. You can build a SMP kernel, but you'll get better performance (in my experience) with SCHED_4BSD on single cpu than with ULE. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDsSX8ACgkQrDN5kXnx8yYntACgophmypAll5NMMjsW3GRnkloY v6wAn0cPS9+/4xZyGCZ35Ttn4lK4b0t1 =Rlxm -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Tue Jan 8 16:45:43 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1C278813 for ; Tue, 8 Jan 2013 16:45:43 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 643C0CC1 for ; Tue, 8 Jan 2013 16:45:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r08GY0ID074549; Wed, 9 Jan 2013 03:34:01 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 9 Jan 2013 03:34:00 +1100 (EST) From: Ian Smith To: Garrett Cooper Subject: Re: To SMP or not to SMP In-Reply-To: Message-ID: <20130109032940.H30575@sola.nimnet.asn.au> References: <1357660252.29936.YahooMailClassic@web121603.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Barney Cordoba , Erich Dollansky , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jan 2013 16:45:43 -0000 On Tue, 8 Jan 2013 07:57:04 -0800, Garrett Cooper wrote: > On Jan 8, 2013, at 7:50 AM, Barney Cordoba wrote: > > > --- On Mon, 1/7/13, Erich Dollansky wrote: > > > >> From: Erich Dollansky > >> Subject: Re: To SMP or not to SMP > >> To: "Barney Cordoba" > >> Cc: freebsd-net@freebsd.org > >> Date: Monday, January 7, 2013, 10:56 PM > >> Hi, > >> > >> On Mon, 7 Jan 2013 18:25:58 -0800 (PST) > >> Barney Cordoba > >> wrote: > >> > >>> I have a situation where I have to run 9.1 on an old > >> single core box. > >>> Does anyone have a handle on whether it's better to > >> build a non SMP > >>> kernel or to just use a standard SMP build with just > >> the one core? > >>> Thanks. > >> > >> I ran a single CPU version of FreeBSD until my last single > >> CPU got hit > >> by a lightning last April or May without any problems. > >> > >> I never saw a reason to include the overhead of SMP for this > >> kind of > >> machine and I also never ran into problems with this. > > > > Another "ass"umption based on logic rather than empirical evidence. > > It isn't really an offhanded assumption because there _is_ > additional overhead added into the kernel structures to make things > work SMP with locking :). Whether or not it's measurable for you and > your applications, I have no idea. > HTH, > -Garrett Where's Kris Kennaway when you need something compared, benchmarked under N different types of loads, and nicely graphed? Do we have a contender? :) cheers, Ian From owner-freebsd-net@FreeBSD.ORG Tue Jan 8 22:39:31 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 967EDBAA for ; Tue, 8 Jan 2013 22:39:31 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by mx1.freebsd.org (Postfix) with ESMTP id 3B146FFF for ; Tue, 8 Jan 2013 22:39:31 +0000 (UTC) Received: by mail-vc0-f169.google.com with SMTP id gb23so960667vcb.14 for ; Tue, 08 Jan 2013 14:39:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=96TlGwCm6FULF3571vpotA/BEMFZpRFnM5168BovkSk=; b=AIHRO6erieniN1XhM0AQt9K++bbXEbFr79wbO06s8aDzvclacUoRdPAP7xjrrUZdbM +mQTg+uvH6poLz5lMTaDA7XN/NjZ3m88n35RPIbkh6ZrscME733SeR+Lo7RkGe3Mzcm9 /OotBHbxOvIV6csIKmQaXUAeqxmJVd7epyS4F6/i4BLRDPmYe48pq0CzURDna8ReHXDD zBiI0rLdoHV37EFaEv3TP/0kzEyOB67bbiQDFUeAoOrE5os/0Mr1GbAUhU4JP3pmN6k6 EKhAEluBEwZUsqV1ITlKJOaKuCZZzusD0661tsH3hgTelT+cuSnh+gfMMTmvu7Jyvg00 sgZA== Received: by 10.52.26.229 with SMTP id o5mr76638751vdg.66.1357684770324; Tue, 08 Jan 2013 14:39:30 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.58.164.100 with HTTP; Tue, 8 Jan 2013 14:39:10 -0800 (PST) From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Tue, 8 Jan 2013 23:39:10 +0100 X-Google-Sender-Auth: fUm7pGiab1mIKCaBfQVwxRf9iPM Message-ID: Subject: How to use netmap pkt-gen on 9.1? To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jan 2013 22:39:31 -0000 Hi, I'm try to use netmap pkt-gen on real and virtual (virtualbox) hardware with FreeBSD 9.1. My setup is pretty simple: ( HOST1 em0:1.1.1.1 ) <------> ( em0:1.1.1.2 HOST2 ) But I didn't reach to use pkt-gen (from tools/tools/netmap), I've got errors (on both physical and virtual machines): - Unable to get if info for em0 - Unable to mmap 0 KB - Unable to register interface em0 Here are all the steps I've done, where is my mistake ? [root@HOST1]~# uname -r 9.1-RELEASE [root@HOST1]~# kldload netmap 018.237252 netmap_new_obj_allocator [425] objsize 1024 clustsize 4096 objects 4 018.248826 netmap_new_obj_allocator [503] Pre-allocated 128 clusters (4/512KB) for 'netmap_if' 018.252891 netmap_new_obj_allocator [425] objsize 36864 clustsize 36864 objects 1 018.257305 netmap_new_obj_allocator [503] Pre-allocated 200 clusters (36/7200KB) for 'netmap_ring' 018.259826 netmap_new_obj_allocator [425] objsize 2048 clustsize 4096 objects 2 018.332819 netmap_new_obj_allocator [503] Pre-allocated 50000 clusters (4/200000KB) for 'netmap_buf' 018.351183 netmap_memory_init [553] Have 512 KB for interfaces, 7200 KB for rings and 195 MB for buffers netmap: loaded module with 202 Mbytes [root@HOST1]~# ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=9b ether aa:aa:00:01:01:01 inet 1.1.1.1 netmask 0xffffff00 broadcast 1.1.1.255 inet6 fe80::a8aa:ff:fe01:101%em0 prefixlen 64 scopeid 0x1 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active [root@HOST1]~# ping -c 1 1.1.1.2 PING 1.1.1.2 (1.1.1.2): 56 data bytes 64 bytes from 1.1.1.2: icmp_seq=0 ttl=64 time=0.466 ms --- 1.1.1.2 ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.466/0.466/0.466/0.000 ms [root@HOST1]~# arp 1.1.1.2 ? (1.1.1.2) at aa:aa:00:00:02:12 on em0 expires in 1197 seconds [ethernet] [root@HOST1]~# pkt-gen -i em0 -t 500 -s 1.1.1.1 -d 1.1.1.2 -D aa:aa:00:00:02 main [808] ether_aton(aa:aa:00:00:02) gives 0x0 main [876] map size is 207712 Kb main [882] Unable to get if info for em0 main [889] bad nthreads 1, have 0 queues main [898] mmapping 0 Kbytes main [903] Unable to mmap 0 KB main [917] Unable to register interface em0 Sending on em0: 0 queues, 1 threads and 1 cpus. 1.1.1.1 -> 1.1.1.2 (aa:aa:00:01:01:01 -> aa:aa:00:00:02) main [951] Wait 2 secs for phy reset main [953] Ready... main [1004] Unable to register em0 main [1061] 0 pps Sent 0 packets, 60 bytes each, in 0.00 seconds. Speed: nanpps. Bandwidth: nanbps. From owner-freebsd-net@FreeBSD.ORG Tue Jan 8 23:02:49 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6284182B for ; Tue, 8 Jan 2013 23:02:49 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id E1254176 for ; Tue, 8 Jan 2013 23:02:48 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id E0DDC7300A; Wed, 9 Jan 2013 00:02:00 +0100 (CET) Date: Wed, 9 Jan 2013 00:02:00 +0100 From: Luigi Rizzo To: Olivier Cochard-Labb? Subject: Re: How to use netmap pkt-gen on 9.1? Message-ID: <20130108230200.GA36903@onelab2.iet.unipi.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jan 2013 23:02:49 -0000 On Tue, Jan 08, 2013 at 11:39:10PM +0100, Olivier Cochard-Labb? wrote: > Hi, > I'm try to use netmap pkt-gen on real and virtual (virtualbox) > hardware with FreeBSD 9.1. > My setup is pretty simple: > > ( HOST1 em0:1.1.1.1 ) <------> ( em0:1.1.1.2 HOST2 ) > > But I didn't reach to use pkt-gen (from tools/tools/netmap), I've got > errors (on both physical and virtual machines): > - Unable to get if info for em0 > - Unable to mmap 0 KB > - Unable to register interface em0 > > Here are all the steps I've done, where is my mistake ? not your mistake, on stable/9 i have not merged yet the device driver changes. Your best option is to copy sys/dev/netmap from HEAD, and add the device-specific chunks also from HEAD into the various drivers (dev/e1000, dev/ixgbe, dev/re) The changes are clearly identified by #ifdef DEV_NETMAP/#endif blocks. cheers luigi > [root@HOST1]~# uname -r > 9.1-RELEASE > [root@HOST1]~# kldload netmap > 018.237252 netmap_new_obj_allocator [425] objsize 1024 clustsize 4096 objects 4 > 018.248826 netmap_new_obj_allocator [503] Pre-allocated 128 clusters > (4/512KB) for 'netmap_if' > 018.252891 netmap_new_obj_allocator [425] objsize 36864 clustsize > 36864 objects 1 > 018.257305 netmap_new_obj_allocator [503] Pre-allocated 200 clusters > (36/7200KB) for 'netmap_ring' > 018.259826 netmap_new_obj_allocator [425] objsize 2048 clustsize 4096 objects 2 > 018.332819 netmap_new_obj_allocator [503] Pre-allocated 50000 clusters > (4/200000KB) for 'netmap_buf' > 018.351183 netmap_memory_init [553] Have 512 KB for interfaces, 7200 > KB for rings and 195 MB for buffers > netmap: loaded module with 202 Mbytes > > [root@HOST1]~# ifconfig em0 > em0: flags=8843 RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 > options=9b > ether aa:aa:00:01:01:01 > inet 1.1.1.1 netmask 0xffffff00 broadcast 1.1.1.255 > inet6 fe80::a8aa:ff:fe01:101%em0 prefixlen 64 scopeid 0x1 > nd6 options=21 > media: Ethernet autoselect (1000baseT ) > status: active > > [root@HOST1]~# ping -c 1 1.1.1.2 > PING 1.1.1.2 (1.1.1.2): 56 data bytes > 64 bytes from 1.1.1.2: icmp_seq=0 ttl=64 time=0.466 ms > > --- 1.1.1.2 ping statistics --- > 1 packets transmitted, 1 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 0.466/0.466/0.466/0.000 ms > [root@HOST1]~# arp 1.1.1.2 > ? (1.1.1.2) at aa:aa:00:00:02:12 on em0 expires in 1197 seconds [ethernet] > > [root@HOST1]~# pkt-gen -i em0 -t 500 -s 1.1.1.1 -d 1.1.1.2 -D aa:aa:00:00:02 > main [808] ether_aton(aa:aa:00:00:02) gives 0x0 > main [876] map size is 207712 Kb > main [882] Unable to get if info for em0 > main [889] bad nthreads 1, have 0 queues > main [898] mmapping 0 Kbytes > main [903] Unable to mmap 0 KB > main [917] Unable to register interface em0 > Sending on em0: 0 queues, 1 threads and 1 cpus. > 1.1.1.1 -> 1.1.1.2 (aa:aa:00:01:01:01 -> aa:aa:00:00:02) > main [951] Wait 2 secs for phy reset > main [953] Ready... > main [1004] Unable to register em0 > main [1061] 0 pps > Sent 0 packets, 60 bytes each, in 0.00 seconds. > Speed: nanpps. Bandwidth: nanbps. > _______________________________________________ > 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 Tue Jan 8 23:15:36 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 539E3C69 for ; Tue, 8 Jan 2013 23:15:36 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm30-vm1.bullet.mail.ne1.yahoo.com (nm30-vm1.bullet.mail.ne1.yahoo.com [98.138.90.46]) by mx1.freebsd.org (Postfix) with ESMTP id 091C7200 for ; Tue, 8 Jan 2013 23:15:35 +0000 (UTC) Received: from [98.138.226.177] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jan 2013 23:12:38 -0000 Received: from [98.138.89.254] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jan 2013 23:12:38 -0000 Received: from [127.0.0.1] by omp1046.mail.ne1.yahoo.com with NNFMP; 08 Jan 2013 23:12:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 588279.45359.bm@omp1046.mail.ne1.yahoo.com Received: (qmail 77939 invoked by uid 60001); 8 Jan 2013 23:12:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1357686758; bh=sqNm0Co/cS0h5m+qmPWHm54Mq08CLeuW2+v9B05KcMQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=WSSjAtosimVk3KZvPZ8nYTasCM7rB+t2gK2SKsOHfASirDedpLImnAAL3fecV8iuMt4VxxaH6Hi8Fkef1/WoU2CsV7b8Bjx8WwOTVVZmn2Mz7/NjPAOKwUFGMthQKtmN+5chMJhaYqRC9NfgfUSvalMjcDkhEsTP6pg1h2YIzw0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=QlgAW6pPC4xHsv9CiR9iPuWpWhXrg30JLoK5VKAGCRApOepALpI9DybKA7jky2luZ9M1SHRFCSmUAneUk4GF7eIoPLNOpzQY/pLQvoFWjbVlDz5JW0XIeslPNOSaqQHhDVqxHy6v/pzQ8dGvV6tB9a+WqPHqnFYcOHbRYNnb7/Y=; X-YMail-OSG: 9icEtAwVM1n3M2t9W21KjXWMHLRZN1v9kPhTrb56tlwOz5c 2YqstneSb1pb2PS3uML4KBuSpdvA.Kz0Ccuv6KYcIT7mJf_qTz_cd0VZS2zp qApG.oHztI4G8bQsoE2q6.irNiGXnFCUuXCu_igm0_lwf0tr7bHZk85SYg9B Pe2Xue9wXg8QIaGo8rrTAxUhn6Sn1rwHYIWgdm6ZcsNLeyJ5OEH2dgThZ7Tg qzTsgkIFHLnE5.pU2VzuqGdbW4A.ZIR.SPz5Lso5SoADfvlRDcf0ik7wJuAB BPCUyjzwbmZ3dK1uQNK9YkNh2qcTd6ffs902PAgCNdrVoF9lPUHhzSRCiAUG CYatWQJ4JfZmyyPO6LG7WO3MEiAggRyTvUuVBHz1r4Rlu.zzLdvDFkLz8abS YsVgIYfyRnAH_TxS0EHd5MnJglQRl7rLbUoZ.MDMaGYoXgKY1lcHSnNFD0hv tu2cikg.o6u7H_HB2vuJV5LXjZfRdUxVhO_0nJ0WbvpoT563XHz6.1DljBJS tUPgDgBQTPGHF_Nw.pt_8Ql5rJtdyog-- Received: from [174.48.128.27] by web121604.mail.ne1.yahoo.com via HTTP; Tue, 08 Jan 2013 15:12:38 PST X-Rocket-MIMEInfo: 001.001, DQoNCi0tLSBPbiBUdWUsIDEvOC8xMywgSWFuIFNtaXRoIDxzbWl0aGlAbmltbmV0LmFzbi5hdT4gd3JvdGU6DQoNCj4gRnJvbTogSWFuIFNtaXRoIDxzbWl0aGlAbmltbmV0LmFzbi5hdT4NCj4gU3ViamVjdDogUmU6IFRvIFNNUCBvciBub3QgdG8gU01QDQo.IFRvOiAiR2FycmV0dCBDb29wZXIiIDx5YW5lZ29taUBnbWFpbC5jb20.DQo.IENjOiAiQmFybmV5IENvcmRvYmEiIDxiYXJuZXlfY29yZG9iYUB5YWhvby5jb20.LCAiRXJpY2ggRG9sbGFuc2t5IiA8ZXJpY2hzZnJlZWJzZGxpc3RAYWxvZ3QuY29tPiwBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.130.494 Message-ID: <1357686758.66466.YahooMailClassic@web121604.mail.ne1.yahoo.com> Date: Tue, 8 Jan 2013 15:12:38 -0800 (PST) From: Barney Cordoba Subject: Re: To SMP or not to SMP To: Ian Smith In-Reply-To: <20130109032940.H30575@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 08 Jan 2013 23:15:36 -0000 --- On Tue, 1/8/13, Ian Smith wrote: > From: Ian Smith > Subject: Re: To SMP or not to SMP > To: "Garrett Cooper" > Cc: "Barney Cordoba" , "Erich Dollansky" , freebsd-net@freebsd.org > Date: Tuesday, January 8, 2013, 11:34 AM > On Tue, 8 Jan 2013 07:57:04 -0800, > Garrett Cooper wrote: > > On Jan 8, 2013, at 7:50 AM, Barney Cordoba wrote: > >=20 > > > --- On Mon, 1/7/13, Erich Dollansky > wrote: > > >=20 > > >> From: Erich Dollansky > > >> Subject: Re: To SMP or not to SMP > > >> To: "Barney Cordoba" > > >> Cc: freebsd-net@freebsd.org > > >> Date: Monday, January 7, 2013, 10:56 PM > > >> Hi, > > >>=20 > > >> On Mon, 7 Jan 2013 18:25:58 -0800 (PST) > > >> Barney Cordoba > > >> wrote: > > >>=20 > > >>> I have a situation where I have to run > 9.1 on an old > > >> single core box. > > >>> Does anyone have a handle on whether it's > better to > > >> build a non SMP > > >>> kernel or to just use a standard SMP > build with just > > >> the one core? > > >>> Thanks. > > >>=20 > > >> I ran a single CPU version of FreeBSD until > my last single > > >> CPU got hit > > >> by a lightning last April or May without any > problems. > > >>=20 > > >> I never saw a reason to include the overhead > of SMP for this > > >> kind of > > >> machine and I also never ran into problems > with this. > > >=20 > > > Another "ass"umption based on logic rather than > empirical evidence. > >=20 > > =A0=A0=A0 It isn't really an offhanded > assumption because there _is_=20 > > additional overhead added into the kernel structures > to make things=20 > > work SMP with locking :). Whether or not it's > measurable for you and=20 > > your applications, I have no idea. > > HTH, > > -Garrett >=20 > Where's Kris Kennaway when you need something compared, > benchmarked=20 > under N different types of loads, and nicely graphed?=A0 > Do we have a=20 > contender? :) >=20 > cheers, Ian I don't need no stinking graphs. I'll do some testing. bc From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 01:04:51 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AEF3F155 for ; Wed, 9 Jan 2013 01:04:51 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by mx1.freebsd.org (Postfix) with ESMTP id 628DA8C0 for ; Wed, 9 Jan 2013 01:04:51 +0000 (UTC) Received: by mail-ia0-f172.google.com with SMTP id u8so335322iag.17 for ; Tue, 08 Jan 2013 17:04:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=aqAz2yxl4J6qys632Z2XpEWEpeGSR/Cz1mKaTfG23RU=; b=WPL83N/Z1XDI9DJok6UaWXVC7Dd27BEv9xYxEbOgmP1WrZAy+BzXOiv5PCQhIaxQ9F KlZ/smJiClONd2lwiVkp/6xB+6s9xTTxdfG2qLxEY1QzZtB8hwVNVfKiYjYV5ON8Vdnw JVAcGL8eRcNsSZM3qZLWOwLrENOm8yz1YxQVVan7YPxb3LnNM5IAo26ifQQVgrdMGOHq sygcT397N7cuuUoRN8NDwMUu5tt7XbXlkIUb3A8LcLJgrOiMSxNIRhjlx0y+0lnQFvlb 2/c4k941r/zwmmZoHbCruHZgQU0U5yv33LXwchbiro7hsie/56Gth2nSz4GmqJz6o9vV 10Qg== MIME-Version: 1.0 Received: by 10.43.134.65 with SMTP id ib1mr49720667icc.12.1357693490686; Tue, 08 Jan 2013 17:04:50 -0800 (PST) Received: by 10.64.51.98 with HTTP; Tue, 8 Jan 2013 17:04:50 -0800 (PST) Received: by 10.64.51.98 with HTTP; Tue, 8 Jan 2013 17:04:50 -0800 (PST) Date: Wed, 9 Jan 2013 03:04:50 +0200 Message-ID: Subject: vimage & routetables From: Sami Halabi To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jan 2013 01:04:51 -0000 hi, I want to compile new kernel with vimage and multiple.routing tables in host, would that work? Or to expect kernel panics? I want to be able to mske.independent stack jails & usr setfib in host to create vrfs... Thank you in advance, Sami From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 05:56:58 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BA071B61 for ; Wed, 9 Jan 2013 05:56:58 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 92B492BD for ; Wed, 9 Jan 2013 05:56:58 +0000 (UTC) Received: from JRE-MBP-2.local (c-50-143-148-105.hsd1.ca.comcast.net [50.143.148.105]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r095utTa076979 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 8 Jan 2013 21:56:56 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <50ED06A2.3040509@freebsd.org> Date: Tue, 08 Jan 2013 21:56:50 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Sami Halabi Subject: Re: vimage & routetables References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jan 2013 05:56:58 -0000 On 1/8/13 5:04 PM, Sami Halabi wrote: > hi, > I want to compile new kernel with vimage and multiple.routing tables in > host, would that work? Or to expect kernel panics? > I want to be able to mske.independent stack jails & usr setfib in host to > create vrfs... done all the time > > Thank you in advance, > Sami > _______________________________________________ > 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 Wed Jan 9 06:01:39 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0C8D7C2C for ; Wed, 9 Jan 2013 06:01:39 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id 648042EB for ; Wed, 9 Jan 2013 06:01:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=ZFDfR6BgdyU71mz62VcqX3viELgbEkOeD99BXPgnAa0=; b=WSR/sgJV03p5ty5BYSD1ThFNJAEGmxLi0VVyjzapX9tqaU5ufmwmKhne98KOh31HEgVWxP//aWGh2XPP/jzf8jVH63rcn7GVvP22zcW7rom3sK7ScCPNrndh9tgw1lau; Received: from [122.129.203.50] (port=23333 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TsojI-000Vhy-NF; Tue, 08 Jan 2013 23:01:37 -0700 Date: Wed, 9 Jan 2013 13:01:33 +0700 From: Erich Dollansky To: Mark Atkinson Subject: Re: To SMP or not to SMP Message-ID: <20130109130133.0399a6cc@X220.ovitrap.com> In-Reply-To: References: <1357611958.66651.YahooMailClassic@web121603.mail.ne1.yahoo.com> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jan 2013 06:01:39 -0000 Hi, On Tue, 08 Jan 2013 08:29:51 -0800 Mark Atkinson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01/07/2013 18:25, Barney Cordoba wrote: > > I have a situation where I have to run 9.1 on an old single core > > box. Does anyone have a handle on whether it's better to build a > > non SMP kernel or to just use a standard SMP build with just the > > one core? Thanks. > > You can build a SMP kernel, but you'll get better performance (in my > experience) with SCHED_4BSD on single cpu than with ULE. > I would not say so. The machine behaves different with the two schedulers. It depends mostly what you want to do with the machine. I forgot which scheduler I finally left in the single CPU kernel. Erich From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 13:22:03 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C60B1168 for ; Wed, 9 Jan 2013 13:22:03 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-vb0-f47.google.com (mail-vb0-f47.google.com [209.85.212.47]) by mx1.freebsd.org (Postfix) with ESMTP id 86BF1EAF for ; Wed, 9 Jan 2013 13:22:03 +0000 (UTC) Received: by mail-vb0-f47.google.com with SMTP id e21so1491012vbm.6 for ; Wed, 09 Jan 2013 05:22:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=9/7TQEQZyYjTAlRfhfcsgKFe0jc8s66oinc2v68lrJU=; b=foRxuaZ1QMajFqGUFqZ+Aw/54LkPB8u4sEowenro2nwEweOxnLjm73qLFzaT/3ARTp KY5K35n3aUcC3p9GN0Or8wBVrK/t1RdXe6zuAytLOXiUC9U0GSqH5d+aRiKzoSlKX6n8 sDWz9TG7QJVRP9mJENaVrkqWI7ghSaJhfSkudPiFHjZMWiZ6CahJ0Te8Zl9u7yiscQSG xo7pG8oe6NW17+fi+FtAA9vVDitaB6UpWUUP6bHZFfNsoUqYsBoHqRaqEwKRqzN97wTO 0CLeCMFHyUgiINVmTByqd4xfztzHaEIVkVNd+weDszAUv1NRnThQ+z7Oe5LSgqorJpwD JMww== Received: by 10.52.29.231 with SMTP id n7mr77320163vdh.103.1357737722456; Wed, 09 Jan 2013 05:22:02 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.58.164.100 with HTTP; Wed, 9 Jan 2013 05:21:42 -0800 (PST) In-Reply-To: <20130108230200.GA36903@onelab2.iet.unipi.it> References: <20130108230200.GA36903@onelab2.iet.unipi.it> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Wed, 9 Jan 2013 14:21:42 +0100 X-Google-Sender-Auth: OWGe_041WKPTZTQmyvIlJ60sq_A Message-ID: Subject: Re: How to use netmap pkt-gen on 9.1? To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jan 2013 13:22:03 -0000 On Wed, Jan 9, 2013 at 12:02 AM, Luigi Rizzo wrote: > not your mistake, on stable/9 i have not merged yet the > device driver changes. > Your best option is to copy sys/dev/netmap from HEAD, > and add the device-specific chunks also from HEAD > into the various drivers (dev/e1000, dev/ixgbe, dev/re) > Ok but before starting to merge the changes, I've tested with a -current and meet the same problem (under virtualbox): [root@router]~# uname -a FreeBSD router.bsdrp.net 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r245223: Wed Jan 9 11:28:12 CET 2013 root@orange.bsdrp.net:/usr/obj/BSDRP.amd64/usr/local/BSDRPexp/FreeBSD/src/sys/amd64 amd64 [root@router]~# kldload netmap netmap: loaded module [root@router]~# pkt-gen -i em0 -t 50 -d 1.1.1.2 -s 1.1.1.1 -D aa:aa:00:00:02:12 main [832] ether887.679157 netmap_memory_config [688] reconfiguring _aton(aa:aa:00:0887.682154 netmap_config_obj_allocator [563] objsize 1024 clustsize 4096 objects 4 0:02:12) gives 0887.684256 netmap_config_obj_allocator [563] objsize 36864 clustsize 36864 objects 1 x800fc0a70 887.686584 netmap_config_obj_allocator [563] objsize 2048 clustsize 4096 objects 2 887.688061 netmap_memory_config [708] Have 100 KB for interfaces, 7200 KB for rings and 320 MB for buffers 887.690015 netmap_finalize_obj_allocator [654] Pre-allocated 25 clusters (4/100KB) for 'netmap_if' 887.694443 netmap_finalize_obj_allocator [654] Pre-allocated 200 clusters (36/7200KB) for 'netmap_ring' 887.938950 netmap_finalize_obj_allocator [654] Pre-allocated 81920 clusters (4/327680KB) for 'netmap_buf' main [900] map size is 334980 Kb main [906] Unable to get if info for em0 main [913] bad nthreads 1, have 0 queues main [922] mmapping 0 Kbytes main [927] Unable to mmap 0 KB main [941] Unable to register interface em0 Sending on em0: 0 queues, 1 threads and 1 cpus. 1.1.1.1 -> 1.1.1.2 (aa:aa:00:01:01:01 -> aa:aa:00:00:02:12) main [975] Wait 2 secs for phy reset main [977] Ready889.942650 netmap_memory_finalize [724] busy (refcount 2) ... main [1028] Unable to register em0 main [1085] 0 pp890.952608 netmap_ioctl [1073] deprecated, data is 0xffffff8000323b90 s Sent 0 packets, 60 bytes each, in 0.00 second890.955473 netmap_memory_deref [950] refcount = 1 s. Speed: nanpp890.956985 netmap_close [575] dev 0xfffffe00210f8400 fflag 0x3 devtype 8192 td 0xfffffe000a0d8000 s. Bandwidth: nanbps (nanbps with overhead). 890.960688 netmap_memory_deref [950] refcount = 0 From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 13:40:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E779354D for ; Wed, 9 Jan 2013 13:40:19 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm23-vm2.bullet.mail.ne1.yahoo.com (nm23-vm2.bullet.mail.ne1.yahoo.com [98.138.91.211]) by mx1.freebsd.org (Postfix) with ESMTP id 8A53FF6C for ; Wed, 9 Jan 2013 13:40:19 +0000 (UTC) Received: from [98.138.90.49] by nm23.bullet.mail.ne1.yahoo.com with NNFMP; 09 Jan 2013 13:40:13 -0000 Received: from [98.138.87.9] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 09 Jan 2013 13:40:13 -0000 Received: from [127.0.0.1] by omp1009.mail.ne1.yahoo.com with NNFMP; 09 Jan 2013 13:40:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 822194.68755.bm@omp1009.mail.ne1.yahoo.com Received: (qmail 53360 invoked by uid 60001); 9 Jan 2013 13:40:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1357738813; bh=MaO9k49rLDcWm4U3Lz+ZvtyjzZOO328CY5L3Y1w0Nqw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=v0cHSpeV71dHhuXJoSf6KJFQm5tdTe8uWnYQfoVad6NwIlPwisn5/tksM2UZBaQurmbUvQen1942g2DKlocJIjuKNmn6DRQtfVnJGhkWCUAhNf2rfRVXt0YaoPnpLvDU0p1u6XZV8oaORqmJUdV78Kfie3+OGeNnS9OJ7qRINFI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=xLbePG3jdwq767v3X0K/0Ik3m6809yoT/onM4HsFnk6bhtEvqgHIOU1aV0GniGeOgAlbb2gXDEeioPswbBjzeRslgOaUub6qa9gsvvSi0+qcGv/fY0t7Fw6R7SySHq1bjPxnzBf5b76HMMyk2BseS4Ox/5mcZg3Pl8Zmrzpc4E4=; X-YMail-OSG: Lowpi7oVM1ldUsYGQ4OL.4XB8SzQwo1zZCn6og0g64_HOGt UFBohQb3Gde54uj_KyyZyKlis0eXUst_lVGZmJa4CxKFhNUSE9j.iBq56DMr 5aW2i7rdeV2Etyf58RpfRA3E_9AQr2BCxqmSyCf6D7M_xCzhQJqLPo5.wyEF Os558c0P9vFR0IfGqhp8JZD51PAb6CotZJdXK72Dp2A927fWrrKDHfoR81yg Ig61qkc0Ar1r0i6zRarUCDd799lMuIo0tuDeI7aPoqnc0NRbmltZg2L1nuZ9 Ewo.lQAuiH6axCGO81Zto35ptvpNM0oNYS_GAdvEhwLwy6doey4K5Mqnlq2m ANiqquzRJ2ztlT_dXvt42MxS7LhQh0SMBCStaCuNJI_hDcOUC8_TQwQcaCWF n1Hhb0kolYWroDCYRJw_W64dWHMpUYJN6F_x49Vx.JfeeIrXvlh_sC.botHQ ZqKn6vKKjw5y8z9bgTongTmIVd6fBB7mV5qhyE2yzKC1tIOWzITyy9Pv2H6i 1nAekNTO0VyLPps_.uk_LcUYvhypwag-- Received: from [174.48.128.27] by web121601.mail.ne1.yahoo.com via HTTP; Wed, 09 Jan 2013 05:40:13 PST X-Rocket-MIMEInfo: 001.001, CgotLS0gT24gV2VkLCAxLzkvMTMsIEVyaWNoIERvbGxhbnNreSA8ZXJpY2hzZnJlZWJzZGxpc3RAYWxvZ3QuY29tPiB3cm90ZToKCj4gRnJvbTogRXJpY2ggRG9sbGFuc2t5IDxlcmljaHNmcmVlYnNkbGlzdEBhbG9ndC5jb20.Cj4gU3ViamVjdDogUmU6IFRvIFNNUCBvciBub3QgdG8gU01QCj4gVG86ICJNYXJrIEF0a2luc29uIiA8YXRraW45MDFAZ21haWwuY29tPgo.IENjOiBmcmVlYnNkLW5ldEBmcmVlYnNkLm9yZwo.IERhdGU6IFdlZG5lc2RheSwgSmFudWFyeSA5LCAyMDEzLCAxOjAxIEFNCj4gSGksCj4BMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.130.494 Message-ID: <1357738813.28186.YahooMailClassic@web121601.mail.ne1.yahoo.com> Date: Wed, 9 Jan 2013 05:40:13 -0800 (PST) From: Barney Cordoba Subject: Re: To SMP or not to SMP To: Mark Atkinson , Erich Dollansky In-Reply-To: <20130109130133.0399a6cc@X220.ovitrap.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org, jack.vogel@gmail.com X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jan 2013 13:40:20 -0000 --- On Wed, 1/9/13, Erich Dollansky wrote: > From: Erich Dollansky > Subject: Re: To SMP or not to SMP > To: "Mark Atkinson" > Cc: freebsd-net@freebsd.org > Date: Wednesday, January 9, 2013, 1:01 AM > Hi, > > On Tue, 08 Jan 2013 08:29:51 -0800 > Mark Atkinson > wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 01/07/2013 18:25, Barney Cordoba wrote: > > > I have a situation where I have to run 9.1 on an > old single core > > > box. Does anyone have a handle on whether it's > better to build a > > > non SMP kernel or to just use a standard SMP build > with just the > > > one core? Thanks. > > > > You can build a SMP kernel, but you'll get better > performance (in my > > experience) with SCHED_4BSD on single cpu than with > ULE. > > > I would not say so. The machine behaves different with the > two > schedulers. It depends mostly what you want to do with the > machine. I > forgot which scheduler I finally left in the single CPU > kernel. > > Erich 4BSD runs pretty well with an SMP kernel. I can test ULE and compare easily. A no SMP kernel is problematic as the igb driver doesn't seem to work and my onboard NICs are, sadly, igb. Rather than say "depends what you want to do", perhaps an explanation of which cases you might choose one or the other would be helpful. So can anyone in the know confirm that the kernel really isn't smart enough to know there there's only 1 core so that most of the SMP "overhead" is avoided? It seems to me that SMP scheduling should only be enabled if there is more than 1 core as part of the scheduler initialization. Its arrogant indeed to assume that just because SMP support is compiled in that there are multiple cores. BC From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 13:55:08 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2C340942 for ; Wed, 9 Jan 2013 13:55:08 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-ea0-f170.google.com (mail-ea0-f170.google.com [209.85.215.170]) by mx1.freebsd.org (Postfix) with ESMTP id B782D85 for ; Wed, 9 Jan 2013 13:55:07 +0000 (UTC) Received: by mail-ea0-f170.google.com with SMTP id d11so697665eaa.29 for ; Wed, 09 Jan 2013 05:55:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=DBBL65k4ILBrxEJxT3Zc7dARMMq9UOllvRhqRtTfjtk=; b=Hv+T0UsdSaujjHvO9VwSK2An9h2GvOQICZs2km7tcmdSDUtSkO+3AnZhV+CU4yp3aM Ei3LnXXKJ94T+Nr0cArDrZl5PqyFKX+pPO2FdDxCHgxUA118OSondRn78ubCeVMs8eg+ EVrGbHncWP7vg2rezllTJjkypaYjF5d67yH79K1nYqVG2glQYsTdKMb8wmusKtkE9Jro lPGCkq8gatI2rLbErc8QoCFbLjL+YOLDRvRedcS5oPmYSXpnr12c8N3k9LWqnIc41xxX glMVy8np0Ipd8s3cBSv1Fe4gW8g9F5t5rPjUgjtYnEAG2GH82TR7gDvOpFEJnpPDqgmd gVXw== MIME-Version: 1.0 Received: by 10.14.209.193 with SMTP id s41mr183090505eeo.9.1357739682050; Wed, 09 Jan 2013 05:54:42 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.14.0.2 with HTTP; Wed, 9 Jan 2013 05:54:41 -0800 (PST) In-Reply-To: References: <20130108230200.GA36903@onelab2.iet.unipi.it> Date: Wed, 9 Jan 2013 05:54:41 -0800 X-Google-Sender-Auth: M-HQdAXOdEcN4yueh3UTBmkTWl4 Message-ID: Subject: Re: How to use netmap pkt-gen on 9.1? From: Luigi Rizzo To: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jan 2013 13:55:08 -0000 On Wed, Jan 9, 2013 at 5:21 AM, Olivier Cochard-Labb=E9 wrote: > On Wed, Jan 9, 2013 at 12:02 AM, Luigi Rizzo wrote: > > > not your mistake, on stable/9 i have not merged yet the > > device driver changes. > > Your best option is to copy sys/dev/netmap from HEAD, > > and add the device-specific chunks also from HEAD > > into the various drivers (dev/e1000, dev/ixgbe, dev/re) > > > > Ok but before starting to merge the changes, I've tested with a > -current and meet the same problem (under virtualbox): > you need to add a "device netmap" option in your kernel config file in order to build the device drivers with the required changes. This also introduces a dependency of these modules on the netmap module so you either have 'netmap' and 'em' statically compiled in, or first load netmap and then 'em'. (you see the same symptoms on 9.x but adding 'device netmap' won't help there because the drivers do not have the relevant modifications. cheers luigi > > [root@router]~# uname -a > FreeBSD router.bsdrp.net 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r245223: > Wed Jan 9 11:28:12 CET 2013 > root@orange.bsdrp.net: > /usr/obj/BSDRP.amd64/usr/local/BSDRPexp/FreeBSD/src/sys/amd64 > amd64 > [root@router]~# kldload netmap > netmap: loaded module > [root@router]~# pkt-gen -i em0 -t 50 -d 1.1.1.2 -s 1.1.1.1 -D > aa:aa:00:00:02:12 > main [832] ether887.679157 netmap_memory_config [688] reconfiguring > _aton(aa:aa:00:0887.682154 netmap_config_obj_allocator [563] objsize > 1024 clustsize 4096 objects 4 > 0:02:12) gives 0887.684256 netmap_config_obj_allocator [563] objsize > 36864 clustsize 36864 objects 1 > x800fc0a70 > 887.686584 netmap_config_obj_allocator [563] objsize 2048 clustsize > 4096 objects 2 > 887.688061 netmap_memory_config [708] Have 100 KB for interfaces, 7200 > KB for rings and 320 MB for buffers > 887.690015 netmap_finalize_obj_allocator [654] Pre-allocated 25 > clusters (4/100KB) for 'netmap_if' > 887.694443 netmap_finalize_obj_allocator [654] Pre-allocated 200 > clusters (36/7200KB) for 'netmap_ring' > 887.938950 netmap_finalize_obj_allocator [654] Pre-allocated 81920 > clusters (4/327680KB) for 'netmap_buf' > main [900] map size is 334980 Kb > main [906] Unable to get if info for em0 > main [913] bad nthreads 1, have 0 queues > main [922] mmapping 0 Kbytes > main [927] Unable to mmap 0 KB > main [941] Unable to register interface em0 > Sending on em0: 0 queues, 1 threads and 1 cpus. > 1.1.1.1 -> 1.1.1.2 (aa:aa:00:01:01:01 -> aa:aa:00:00:02:12) > main [975] Wait 2 secs for phy reset > main [977] Ready889.942650 netmap_memory_finalize [724] busy (refcount 2) > ... > main [1028] Unable to register em0 > main [1085] 0 pp890.952608 netmap_ioctl [1073] deprecated, data is > 0xffffff8000323b90 > s > Sent 0 packets, 60 bytes each, in 0.00 second890.955473 > netmap_memory_deref [950] refcount =3D 1 > s. > Speed: nanpp890.956985 netmap_close [575] dev 0xfffffe00210f8400 fflag > 0x3 devtype 8192 td 0xfffffe000a0d8000 > s. Bandwidth: nanbps (nanbps with overhead). > 890.960688 netmap_memory_deref [950] refcount =3D 0 > --=20 -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 14:14:45 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1D4F1148 for ; Wed, 9 Jan 2013 14:14:45 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id CF7FA1B3 for ; Wed, 9 Jan 2013 14:14:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=d+OeePXNtDXfS5m/jnfYMUkKJyGZjc2Z7Z83kK3FoG4=; b=kIamPsXJlS3ZCP2pBX/O51lwIeyyDllnicCjSCKy8A4R/sCNmHQQEWsVBRxDy9iwlh14JXf8kCsWjl+M1NPIaStvXMFEpJ6l5B3AAor3KqHBAa2eYb93ld6JSRtNldW0; Received: from [122.129.203.50] (port=15739 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TswQV-002Fuu-Bu; Wed, 09 Jan 2013 07:14:43 -0700 Date: Wed, 9 Jan 2013 21:14:39 +0700 From: Erich Dollansky To: Barney Cordoba Subject: Re: To SMP or not to SMP Message-ID: <20130109211439.5b590bf5@X220.ovitrap.com> In-Reply-To: <1357738813.28186.YahooMailClassic@web121601.mail.ne1.yahoo.com> References: <20130109130133.0399a6cc@X220.ovitrap.com> <1357738813.28186.YahooMailClassic@web121601.mail.ne1.yahoo.com> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-net@freebsd.org, jack.vogel@gmail.com, Mark Atkinson X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jan 2013 14:14:45 -0000 Hi, On Wed, 9 Jan 2013 05:40:13 -0800 (PST) Barney Cordoba wrote: > --- On Wed, 1/9/13, Erich Dollansky > wrote: > > From: Erich Dollansky > > Subject: Re: To SMP or not to SMP > > To: "Mark Atkinson" > > Cc: freebsd-net@freebsd.org > > Date: Wednesday, January 9, 2013, 1:01 AM > > Hi, > > > > On Tue, 08 Jan 2013 08:29:51 -0800 > > Mark Atkinson > > wrote: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > On 01/07/2013 18:25, Barney Cordoba wrote: > > > > I have a situation where I have to run 9.1 on an > > old single core > > > > box. Does anyone have a handle on whether it's > > better to build a > > > > non SMP kernel or to just use a standard SMP build > > with just the > > > > one core? Thanks. > > > > > > You can build a SMP kernel, but you'll get better > > performance (in my > > > experience) with SCHED_4BSD on single cpu than with > > ULE. > > > > > I would not say so. The machine behaves different with the > > two > > schedulers. It depends mostly what you want to do with the > > machine. I > > forgot which scheduler I finally left in the single CPU > > kernel. > > > > Erich > > 4BSD runs pretty well with an SMP kernel. I can test ULE and compare > easily. A no SMP kernel is problematic as the igb driver doesn't seem > to work and my onboard NICs are, sadly, igb. > this is bad luck. I know of the kernels as I have had SMP and single CPU machines since 4.x times. > Rather than say "depends what you want to do", perhaps an explanation > of which cases you might choose one or the other would be helpful. > > So can anyone in the know confirm that the kernel really isn't smart > enough to know there there's only 1 core so that most of the SMP The kernel does not think like this. It is a fixed program flow. > "overhead" is avoided? It seems to me that SMP scheduling should only > be enabled if there is more than 1 core as part of the scheduler > initialization. Its arrogant indeed to assume that just because SMP > support is compiled in that there are multiple cores. I compile my own kernels and set the parameters as needed. Erich From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 14:35:40 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5516F5CD for ; Wed, 9 Jan 2013 14:35:40 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm36-vm3.bullet.mail.ne1.yahoo.com (nm36-vm3.bullet.mail.ne1.yahoo.com [98.138.229.115]) by mx1.freebsd.org (Postfix) with ESMTP id 0A9AE291 for ; Wed, 9 Jan 2013 14:35:39 +0000 (UTC) Received: from [98.138.226.177] by nm36.bullet.mail.ne1.yahoo.com with NNFMP; 09 Jan 2013 14:35:33 -0000 Received: from [98.138.87.6] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 09 Jan 2013 14:35:33 -0000 Received: from [127.0.0.1] by omp1006.mail.ne1.yahoo.com with NNFMP; 09 Jan 2013 14:35:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 676871.70403.bm@omp1006.mail.ne1.yahoo.com Received: (qmail 11641 invoked by uid 60001); 9 Jan 2013 14:35:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1357742133; bh=l+Sg89LUUze5sbtxHi0XlpQlBLcaoMC7xffkaD1LgbM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=2duJISat7W6xaUPpiwud/3nKtOb7jFIiqeUngsyHbtDWYb1xNBhuxdFxeKy1dqmUtzzLkXvpcJT9yWDuP1fuNmO/IZSmKfEm4/oIi15NzfYqhvQJ318IUnV1EI/m84y3whmVXYYlGdjeTzawNW0ijWkEDyRhqeTZ/WXmcGLCfms= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=luZ5fT1lYMfgAn6TzfroybxwWEPd/GYnKfeUcSwFnpdjmY+PuaKH+RJ4vHhzyscyW5k2extJHX3TOMIMCmz5gE47yiM2NQCJe+YcWZnlt54mCaZxN/sSlwqMO3Pii0P3Q1WPH3cUXg1NZYMzS9GaMyaAdoap0VLs1uyuE3nFMPE=; X-YMail-OSG: iNYP7A0VM1ni51x6jZ.wesGV1T34KJaNCA1JqEOKbiEGOtg 2y12wKu7uQP2CmPK_3Kd6xO3b0rE91S7UUFtz7V_PO6Fz4v687VrWFS3bLgQ 5aPGrRcCECWubSg.jn4lpslh8kPEpznQNWpsBkdEA5fw233BgGncozNSoMjQ 5p5BeQEudCGnyOQvDlAio2Gkk6i_5wVd0Cvy5o_rrjBIELdBPNztQ4aPvtpG tv5iTErdgJ21.X8aNQQvbv6cF4KeFQ8pn0sTYt43uJXP0zSDC3yHcp23UqXk D4EBh8itnCO8aB2R4YCte_W7ofSsx9tEHYJKCW0QvERZzo4wULkS1cbB2T5k h1xYaGD6w42HLsFp7K8C_6LNCXXnyE5QxZBWphqBKeYIJKCITohy1jV1jXo0 cF9R1q.phkO7oLd3nItdfC6DHVhY4p6qHzAnsUzf3kFbtI4RBKzzoa0VJUgU GLfe4Udl.N.Hja50lcRlDsoyjCJHhZgwHvSKbtztQRwueQrzwSie.e_Iymq6 joER5IPTBGOx4LJCJPLhM116MrtzhAA-- Received: from [174.48.128.27] by web121601.mail.ne1.yahoo.com via HTTP; Wed, 09 Jan 2013 06:35:33 PST X-Rocket-MIMEInfo: 001.001, CgotLS0gT24gV2VkLCAxLzkvMTMsIEVyaWNoIERvbGxhbnNreSA8ZXJpY2hzZnJlZWJzZGxpc3RAYWxvZ3QuY29tPiB3cm90ZToKCj4gRnJvbTogRXJpY2ggRG9sbGFuc2t5IDxlcmljaHNmcmVlYnNkbGlzdEBhbG9ndC5jb20.Cj4gU3ViamVjdDogUmU6IFRvIFNNUCBvciBub3QgdG8gU01QCj4gVG86ICJCYXJuZXkgQ29yZG9iYSIgPGJhcm5leV9jb3Jkb2JhQHlhaG9vLmNvbT4KPiBDYzogIk1hcmsgQXRraW5zb24iIDxhdGtpbjkwMUBnbWFpbC5jb20.LCBmcmVlYnNkLW5ldEBmcmVlYnNkLm9yZywgamFjay4BMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.130.494 Message-ID: <1357742133.9692.YahooMailClassic@web121601.mail.ne1.yahoo.com> Date: Wed, 9 Jan 2013 06:35:33 -0800 (PST) From: Barney Cordoba Subject: Re: To SMP or not to SMP To: Erich Dollansky In-Reply-To: <20130109211439.5b590bf5@X220.ovitrap.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org, jack.vogel@gmail.com, Mark Atkinson X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jan 2013 14:35:40 -0000 --- On Wed, 1/9/13, Erich Dollansky wrote: > From: Erich Dollansky > Subject: Re: To SMP or not to SMP > To: "Barney Cordoba" > Cc: "Mark Atkinson" , freebsd-net@freebsd.org, jack.vogel@gmail.com > Date: Wednesday, January 9, 2013, 9:14 AM > Hi, > > On Wed, 9 Jan 2013 05:40:13 -0800 (PST) > Barney Cordoba > wrote: > > > --- On Wed, 1/9/13, Erich Dollansky > > wrote: > > > From: Erich Dollansky > > > Subject: Re: To SMP or not to SMP > > > To: "Mark Atkinson" > > > Cc: freebsd-net@freebsd.org > > > Date: Wednesday, January 9, 2013, 1:01 AM > > > Hi, > > > > > > On Tue, 08 Jan 2013 08:29:51 -0800 > > > Mark Atkinson > > > wrote: > > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > Hash: SHA1 > > > > > > > > On 01/07/2013 18:25, Barney Cordoba wrote: > > > > > I have a situation where I have to run > 9.1 on an > > > old single core > > > > > box. Does anyone have a handle on > whether it's > > > better to build a > > > > > non SMP kernel or to just use a standard > SMP build > > > with just the > > > > > one core? Thanks. > > > > > > > > You can build a SMP kernel, but you'll get > better > > > performance (in my > > > > experience) with SCHED_4BSD on single cpu > than with > > > ULE. > > > > > > > I would not say so. The machine behaves different > with the > > > two > > > schedulers. It depends mostly what you want to do > with the > > > machine. I > > > forgot which scheduler I finally left in the > single CPU > > > kernel. > > > > > > Erich > > > > 4BSD runs pretty well with an SMP kernel. I can test > ULE and compare > > easily. A no SMP kernel is problematic as the igb > driver doesn't seem > > to work and my onboard NICs are, sadly, igb. > > > this is bad luck. I know of the kernels as I have had SMP > and single > CPU machines since 4.x times. > > > Rather than say "depends what you want to do", perhaps > an explanation > > of which cases you might choose one or the other would > be helpful. > > > > So can anyone in the know confirm that the kernel > really isn't smart > > enough to know there there's only 1 core so that most > of the SMP > > The kernel does not think like this. It is a fixed program > flow. > > > "overhead" is avoided? It seems to me that SMP > scheduling should only > > be enabled if there is more than 1 core as part of the > scheduler > > initialization. Its arrogant indeed to assume that just > because SMP > > support is compiled in that there are multiple cores. > > I compile my own kernels and set the parameters as needed. > > Erich > This explanation defies the possibility of a GENERIC kernel, which of course is an important element of a GPOS. Its too bad that smp support can't be done with logic rather than a kernel option. The big thing I see is the use of legacy interrupts vs msix. Its not like flipping off SMP support only changes the scheduler behavior. BC From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 14:39:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AA2116B2 for ; Wed, 9 Jan 2013 14:39:34 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id D22AE2B4 for ; Wed, 9 Jan 2013 14:39:33 +0000 (UTC) Received: (qmail 16892 invoked from network); 9 Jan 2013 14:32:49 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 9 Jan 2013 14:32:49 -0000 Date: Wed, 09 Jan 2013 15:32:49 +0100 (CET) Message-Id: <20130109.153249.41633097.sthaug@nethelp.no> To: erichsfreebsdlist@alogt.com Subject: Re: To SMP or not to SMP From: sthaug@nethelp.no In-Reply-To: <20130109211439.5b590bf5@X220.ovitrap.com> References: <20130109130133.0399a6cc@X220.ovitrap.com> <1357738813.28186.YahooMailClassic@web121601.mail.ne1.yahoo.com> <20130109211439.5b590bf5@X220.ovitrap.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: barney_cordoba@yahoo.com, jack.vogel@gmail.com, atkin901@gmail.com, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jan 2013 14:39:34 -0000 > > 4BSD runs pretty well with an SMP kernel. I can test ULE and compare > > easily. A no SMP kernel is problematic as the igb driver doesn't seem > > to work and my onboard NICs are, sadly, igb. > > > this is bad luck. I know of the kernels as I have had SMP and single > CPU machines since 4.x times. I have had igb working with both SMP and non-SMP kernel for at least a year or two, 8.x-STABLE. No specific problems. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 15:00:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D5E24259 for ; Wed, 9 Jan 2013 15:00:37 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm1-vm4.bullet.mail.ne1.yahoo.com (nm1-vm4.bullet.mail.ne1.yahoo.com [98.138.91.161]) by mx1.freebsd.org (Postfix) with ESMTP id 8C0286B9 for ; Wed, 9 Jan 2013 15:00:37 +0000 (UTC) Received: from [98.138.90.48] by nm1.bullet.mail.ne1.yahoo.com with NNFMP; 09 Jan 2013 15:00:31 -0000 Received: from [98.138.89.164] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 09 Jan 2013 15:00:31 -0000 Received: from [127.0.0.1] by omp1020.mail.ne1.yahoo.com with NNFMP; 09 Jan 2013 15:00:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 804445.26298.bm@omp1020.mail.ne1.yahoo.com Received: (qmail 26071 invoked by uid 60001); 9 Jan 2013 15:00:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1357743631; bh=8jkYnBnqZBBCBPwVeqqZUIzWH7fjSeD5svQFjcnIxb8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=4ywqNQ4T3DTwqDe59INXMqNMuese03Bub2JchPDXfj37eO6W8eVzaFnBJW0r2LuHIWtQ14s5BfrA3iBqOwYaRv5MWMq832F+ielhMfWg/qO1i/y8YMLcJM432ued6HWJ8FD1VyARVSyyYx18ItmIYtHaBEHacvdQ9+vHatF8xXE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=XqUV4hGvacjqfEjW53GEmxytonQF2SwRbHOUs652DAkaMYGSiWLaQnDSLeGwVgc1yb/wrRqZ1G72dDg36HS+3qbVRHCbX/f9i1cDyqnr6p6FgjrlcV0JC/BSwzfOzIHm1FHJqt7ZXamEjrgYuQF7TQTGJdtBOJmXNFZLyotjSNE=; X-YMail-OSG: f__xyq0VM1nNy0d58U6vlO0D_BOoiZKLTybhFD9adhfbHRn tYEJW6pbDfKapKf8ma_ScMjgBzZUC0x4xPBG79NHsuUzaDclBc.H5lWr7uW0 WRjNwmsPSPsRMZeU1SHu_27ttt2QN8BDWNtCaVMzsjxBbrhefzqPYdnQ7iZJ 3HsaBiyPftKIr4kn7v2en0lMtAYXzCXSqmqWNwkanvvDnNayR8bMLP4qdo9G ZFZCJKeXoOjmHMPwJks6RGsK7FRvNdgpUqaLgn8gsBL3.wHoFnvD5Kpr1KbV 6SOpGW8xmqJSjS.v4M5JpwJq6ASMd34VRXwSKACDshDyygzhgALABRBQiRm8 UUMAc4gQvAr9zv_92AsVLOjAp4NjQvUCNljs.w0tD0Vv9uL8lUDGaQBoPxmy PGhyHCX4ULiVrC8KK2o9MQQ3RWAX5I4E.O25XsGzEdAl4BthmU3rG09L9LsO qEMDWgC6Tx39hsnX.anTFp1bJn2PV13q4K4fdS16TS4LlMeIBwOArYFqirVH RzEMoBgINLd5HqKCX7a_dCEtcVs_qFw-- Received: from [174.48.128.27] by web121605.mail.ne1.yahoo.com via HTTP; Wed, 09 Jan 2013 07:00:31 PST X-Rocket-MIMEInfo: 001.001, CgotLS0gT24gV2VkLCAxLzkvMTMsIHN0aGF1Z0BuZXRoZWxwLm5vIDxzdGhhdWdAbmV0aGVscC5ubz4gd3JvdGU6Cgo.IEZyb206IHN0aGF1Z0BuZXRoZWxwLm5vIDxzdGhhdWdAbmV0aGVscC5ubz4KPiBTdWJqZWN0OiBSZTogVG8gU01QIG9yIG5vdCB0byBTTVAKPiBUbzogZXJpY2hzZnJlZWJzZGxpc3RAYWxvZ3QuY29tCj4gQ2M6IGJhcm5leV9jb3Jkb2JhQHlhaG9vLmNvbSwgZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmcsIGphY2sudm9nZWxAZ21haWwuY29tLCBhdGtpbjkwMUBnbWFpbC5jb20KPiBEYXRlOiABMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.130.494 Message-ID: <1357743631.24911.YahooMailClassic@web121605.mail.ne1.yahoo.com> Date: Wed, 9 Jan 2013 07:00:31 -0800 (PST) From: Barney Cordoba Subject: Re: To SMP or not to SMP To: erichsfreebsdlist@alogt.com, sthaug@nethelp.no In-Reply-To: <20130109.153249.41633097.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org, jack.vogel@gmail.com, atkin901@gmail.com X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jan 2013 15:00:37 -0000 --- On Wed, 1/9/13, sthaug@nethelp.no wrote: > From: sthaug@nethelp.no > Subject: Re: To SMP or not to SMP > To: erichsfreebsdlist@alogt.com > Cc: barney_cordoba@yahoo.com, freebsd-net@freebsd.org, jack.vogel@gmail.com, atkin901@gmail.com > Date: Wednesday, January 9, 2013, 9:32 AM > > > 4BSD runs pretty well with > an SMP kernel. I can test ULE and compare > > > easily. A no SMP kernel is problematic as the igb > driver doesn't seem > > > to work and my onboard NICs are, sadly, igb. > > > > > this is bad luck. I know of the kernels as I have had > SMP and single > > CPU machines since 4.x times. > > I have had igb working with both SMP and non-SMP kernel for > at least a > year or two, 8.x-STABLE. No specific problems. > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > Maybe a problem with "legacy interrupts" on more modern processors? I'm using an E5520 and while the NIC inits ok, it just doesnt seem to gen interrupts. I can't spend much time debugging it.... I notice that HAMMER kernels use MSI/X interrupts whether SMP is enabled or not, while i386 kernels seem to require APIC. Is there some physical reason for this? BC From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 15:22:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 05B15A21; Wed, 9 Jan 2013 15:22:19 +0000 (UTC) (envelope-from steve.read@netasq.com) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id C7D2A801; Wed, 9 Jan 2013 15:22:18 +0000 (UTC) Received: from stever.netasq.com (unknown [10.2.0.1]) by work.netasq.com (Postfix) with ESMTPA id B53EA2706304; Wed, 9 Jan 2013 16:22:15 +0100 (CET) Message-ID: <50ED8B27.8070708@netasq.com> Date: Wed, 09 Jan 2013 16:22:15 +0100 From: Steve Read User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111110 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: panics in soabort with so_count != 0, one possible solution to one cause. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rwatson@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jan 2013 15:22:19 -0000 Context for this message: http://www.freebsd.org/cgi/query-pr.cgi?pr=145825&cat=kern kern/145825: [panic] panic: soabort: so_count AND http://www.freebsd.org/cgi/query-pr.cgi?pr=159621 kern/159621: [tcp] [panic] panic: soabort: so_count The two PRs are essentially reporting the same thing, and I have seen evidence of people reporting this panic against kernels as old as 6.2. == Scenario == The basic scenario is: 1. There is a local listening TCP socket. A userland thread is waiting on a kqueue, and will eventually call accept() on this socket. 2. A new TCP connection arrives that matches this TCP socket. Syncache hangs on to the connection until the three-way handshake is complete (i.e. the ACK arrives). 3. At this point, syncache_socket() calls sonewconn() and passes SS_ISCONNECTED. sonewconn() as a result hands the new socket off to the accept queue and wakes up the userland thread (marks the listening socket "readable", sends a kqueue notification, etc.). 4. Something goes wrong during the rest of syncache_socket(), as a result of which it calls soabort(). == Consequence == On a single-CPU machine, the netisr thread that called syncache_socket() blocks out the userland thread until it has finished, so so_count of the new connected socket is still zero when syncache_socket() calls soabort(). (It's not absolutely guaranteed, as there are calls to locking functions along the way, but it usually happens.) On a multi-CPU machine of any sort, the userland thread resumes immediately that it is woken up, and it is possible (but not guaranteed) for it to grab the socket and increment its so_count before syncache_socket() calls soabort(). I have a core which shows the netisr thread hitting the panic in soabort(), while the expected userland thread (on a different CPU) is still in the kernel, churning through the post-pickup part of accept(). == Proposed solution == My proposed solution to this issue is: 1. Replace SS_ISCONNECTED with 0 in the call to sonewconn() to prevent it from waking up the listening thread. 2. At the "end" of syncache_socket(), call soisconnected(), passing the new socket. This will issue the wakeup after syncache_socket() has finished preparing itself, and in particular after the last possible call to soabort(). I'm concerned, of course, that this may cause some unobvious fallout somewhere, but I can't see for the moment what it would be. Any advice would be welcome. == Patch that applies the proposed solution == A patch that would apply to kernel 8.3 (the basic scenario appears to still be feasible with HEAD, and the code is very similar): ====== --- netinet/tcp_syncache.c.orig 2013-01-09 13:18:05.000000000 +0000 +++ netinet/tcp_syncache.c 2013-01-09 14:03:54.000000000 +0000 @@ -638,7 +638,7 @@ * connection when the SYN arrived. If we can't create * the connection, abort it. */ - so = sonewconn(lso, SS_ISCONNECTED); + so = sonewconn(lso, 0); if (so == NULL) { /* * Drop the connection; we will either send a RST or @@ -831,6 +831,8 @@ INP_WUNLOCK(inp); + soisconnected(so); + TCPSTAT_INC(tcps_accepts); return (so); ====== -- Steve Read steve.read@netasq.org From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 16:50:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6ABDA7E4 for ; Wed, 9 Jan 2013 16:50:34 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by mx1.freebsd.org (Postfix) with ESMTP id F2D17D4B for ; Wed, 9 Jan 2013 16:50:33 +0000 (UTC) Received: by mail-vc0-f172.google.com with SMTP id fw7so1761412vcb.31 for ; Wed, 09 Jan 2013 08:50:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=aI8avfPfZw0ZA+D4d8590tN3vNM3UCgeocwJn6c9Qgo=; b=yqefe5dlExcUrXESYZl/oScng9GFeVHmQ4wWoCGr1xZr4tBHiu0WKtLhBXpbz15KsY RMdA6wpGu3HoLtnq2ulvScUVGlXvj4hQPin8QhDp9HymCBr89yS8bQMmkrkYr6Fvmmay lqbGhjrQXeKXojXDKNDkNi0LrQVhLpwa1knICOSSctmFXpsPZZFqx3K6lGNl4155pkVW kxpbRn5vOKhuo+h3xJjzMOh31ooJxW86y6/NyWuZt/g7Es1cqLkiH9/F4EzGuoMbVdPX 0NqxAkZ3YpqdWuLhORpCVPE4V9GqlJGwQg5W/QKGlfOXXHqJ8GebtMW0zRyZHdNrH5u4 9G8w== Received: by 10.220.142.74 with SMTP id p10mr16496435vcu.63.1357750227059; Wed, 09 Jan 2013 08:50:27 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.58.164.100 with HTTP; Wed, 9 Jan 2013 08:50:06 -0800 (PST) In-Reply-To: References: <20130108230200.GA36903@onelab2.iet.unipi.it> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Wed, 9 Jan 2013 17:50:06 +0100 X-Google-Sender-Auth: NddaLawf4yfelvjAMX3cUhJSVuY Message-ID: Subject: Re: How to use netmap pkt-gen on 9.1? To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jan 2013 16:50:34 -0000 On Wed, Jan 9, 2013 at 2:54 PM, Luigi Rizzo wrote: > you need to add a "device netmap" option in your kernel config file in order > to > build the device drivers with the required changes. "device netmap" was the forgotten part ! Now I reach to use it on -current and, following your advice, on 9.1 too. The patch (for 9.1-release) that I've used his here: http://gugus69.free.fr/freebsd/freebsd.netmap.patch But I didn't adapt the ixgbe drivers (only em and re): - the DEV_NETMAP part in the ixgbe drivers include new -current drivers code and simply copy the full -current ixgbe drivers didn't works - I didn't have this hardware for testing it Tested on virtualbox: [root@router]~# uname -a FreeBSD router.bsdrp.net 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243710M: Wed Jan 9 16:30:29 CET 2013 root@orange.bsdrp.net:/usr/obj/BSDRP.amd64/usr/local/BSDRP/FreeBSD/src/sys/amd64 amd6 [root@router]~# pkt-gen -i em0 -t 50 -d 1.1.1.2 -D aa:aa:00:00:02:12 -s 1.1.1.1 main [832] ether627.452946 netmap_mmap_single [511] cdev 0xfffffe00022d4a00 foff 0 size 343019520 objp 0xffffff800033ba08 prot 3 _aton(aa:aa:00:00:02:12) gives 0x800f9a292 main [900] map size is 334980 Kb main [922] mmapping 334980 Kbytes 627.461541 netmap_set_ringid [886] ringid em0 set to all 1 HW RINGS Sending on em0: 1 queues, 1 threads and 1 cpus. 1.1.1.1 -> 1.1.1.2 (aa:aa:00:01:01:01 -> aa:aa:00:00:02:12) main [975] Wait 2 secs for phy reset main [977] Ready629.517672 netmap_memory_finalize [724] busy (refcount 2) ... 629.520162 netmap_set_ringid [886] ringid em0 set to all 1 HW RINGS sender_body [479] start main [1085] 50 p630.528557 netmap_ioctl [1073] deprecated, data is 0xffffff800033bbc0 ps 630.531703 netmap_memory_deref [950] refcount = 1 Sent 50 packets,630.533182 netmap_ioctl [1073] deprecated, data is 0xffffff800033bbc0 60 bytes each, in 0.02 seconds. Speed: 3.22Kpps. Bandwidth: 1.54Mbps (2.16Mbps with overhead).630.536432 netmap_dev_pager_dtor [494] ready to release memory for 0xfffffe00022d4a00 630.538334 netmap_close [575] dev 0xfffffe00022d4a00 fflag 0x3 devtype 8192 td 0xfffffe00050ec8e0 630.540230 netmap_dtor_locked [354] deleting last netmap instance for em0 630.620152 netmap_memory_deref [950] refcount = 0 4 Thanks, Olivier From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 17:12:56 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 825D04C1; Wed, 9 Jan 2013 17:12:56 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 03708FE0; Wed, 9 Jan 2013 17:12:55 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id r09HCrHN076864; Wed, 9 Jan 2013 21:12:53 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id r09HCrDJ076863; Wed, 9 Jan 2013 21:12:53 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 9 Jan 2013 21:12:53 +0400 From: Gleb Smirnoff To: Steve Read Subject: Re: panics in soabort with so_count != 0, one possible solution to one cause. Message-ID: <20130109171253.GO66284@FreeBSD.org> References: <50ED8B27.8070708@netasq.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <50ED8B27.8070708@netasq.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org, andre@FreeBSD.org, rwatson@FreeBSD.org, Vijay Singh X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jan 2013 17:12:56 -0000 On Wed, Jan 09, 2013 at 04:22:15PM +0100, Steve Read wrote: S> Context for this message: S> http://www.freebsd.org/cgi/query-pr.cgi?pr=145825&cat=kern S> S> kern/145825: [panic] panic: soabort: so_count S> S> AND S> S> http://www.freebsd.org/cgi/query-pr.cgi?pr=159621 S> kern/159621: [tcp] [panic] panic: soabort: so_count S> S> The two PRs are essentially reporting the same thing, and I have seen S> evidence of people reporting this panic against kernels as old as 6.2. S> S> == Scenario == S> The basic scenario is: S> 1. There is a local listening TCP socket. A userland thread is waiting S> on a kqueue, and will eventually call accept() on this socket. S> 2. A new TCP connection arrives that matches this TCP socket. Syncache S> hangs on to the connection until the three-way handshake is complete S> (i.e. the ACK arrives). S> 3. At this point, syncache_socket() calls sonewconn() and passes S> SS_ISCONNECTED. sonewconn() as a result hands the new socket off to the S> accept queue and wakes up the userland thread (marks the listening S> socket "readable", sends a kqueue notification, etc.). S> 4. Something goes wrong during the rest of syncache_socket(), as a S> result of which it calls soabort(). S> S> == Consequence == S> On a single-CPU machine, the netisr thread that called syncache_socket() S> blocks out the userland thread until it has finished, so so_count of the S> new connected socket is still zero when syncache_socket() calls S> soabort(). (It's not absolutely guaranteed, as there are calls to S> locking functions along the way, but it usually happens.) S> S> On a multi-CPU machine of any sort, the userland thread resumes S> immediately that it is woken up, and it is possible (but not guaranteed) S> for it to grab the socket and increment its so_count before S> syncache_socket() calls soabort(). S> S> I have a core which shows the netisr thread hitting the panic in S> soabort(), while the expected userland thread (on a different CPU) is S> still in the kernel, churning through the post-pickup part of accept(). S> S> == Proposed solution == S> My proposed solution to this issue is: S> 1. Replace SS_ISCONNECTED with 0 in the call to sonewconn() to prevent S> it from waking up the listening thread. S> 2. At the "end" of syncache_socket(), call soisconnected(), passing the S> new socket. This will issue the wakeup after syncache_socket() has S> finished preparing itself, and in particular after the last possible S> call to soabort(). S> S> I'm concerned, of course, that this may cause some unobvious fallout S> somewhere, but I can't see for the moment what it would be. Any advice S> would be welcome. S> S> == Patch that applies the proposed solution == S> A patch that would apply to kernel 8.3 (the basic scenario appears to S> still be feasible with HEAD, and the code is very similar): S> S> ====== S> --- netinet/tcp_syncache.c.orig 2013-01-09 13:18:05.000000000 +0000 S> +++ netinet/tcp_syncache.c 2013-01-09 14:03:54.000000000 +0000 S> @@ -638,7 +638,7 @@ S> * connection when the SYN arrived. If we can't create S> * the connection, abort it. S> */ S> - so = sonewconn(lso, SS_ISCONNECTED); S> + so = sonewconn(lso, 0); S> if (so == NULL) { S> /* S> * Drop the connection; we will either send a RST or S> @@ -831,6 +831,8 @@ S> S> INP_WUNLOCK(inp); S> S> + soisconnected(so); S> + S> TCPSTAT_INC(tcps_accepts); S> return (so); AFAIU, in head this race was fixed by r243627. Can Vijay and Andre comment? -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 18:08:51 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2FCC0F42 for ; Wed, 9 Jan 2013 18:08:51 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm20-vm1.bullet.mail.ne1.yahoo.com (nm20-vm1.bullet.mail.ne1.yahoo.com [98.138.91.21]) by mx1.freebsd.org (Postfix) with ESMTP id D8C4B25F for ; Wed, 9 Jan 2013 18:08:50 +0000 (UTC) Received: from [98.138.90.49] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 09 Jan 2013 18:08:44 -0000 Received: from [98.138.88.232] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 09 Jan 2013 18:08:44 -0000 Received: from [127.0.0.1] by omp1032.mail.ne1.yahoo.com with NNFMP; 09 Jan 2013 18:08:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 575376.84374.bm@omp1032.mail.ne1.yahoo.com Received: (qmail 67971 invoked by uid 60001); 9 Jan 2013 18:08:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1357754924; bh=F9OXQAsu4Q6DHpZzRKr7tfpk/G7e8czVbROOnsNck5k=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=MIms9tv2uyYyX2stau9IxIIw6kFugSrJhglHlVT/Kd/sDBVa6ZHJl6WCgiUxtgkGO9yfNC/jvdbSopFSi1R8Bra/19Nx07X/OEImAdmsBEp7ABxHtA1xqBydx9NwZ/ieZ753woI0Je5x7XpUYrNorYtrUHVUww6IecJBU6QIEes= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=W0ZngTjMraWP5DAG4pAD/HVWs5WTAzIMLJpdLrf3IviDGltuSqfLnxFg4L5s7G6VDA7F+FA1dD2gwMNZLoZcvqYrGvS0+mAHNqVKmUWxCn3lUmBwsOkLQ6mS8mT7JGr/JL6UctwT7dpRl5NEuRVSrJYFLDWNVqVxYgfIaVfGzXY=; X-YMail-OSG: IxS35mAVM1kQPQxr2ihv5fFjmNo2wcusSXTvda0pr_MBcdL J9EEu40RqOZ3MD9zYwQJR_z5LalohPqJVhZ9RavPtdFBFodhWgfhw6ckZza. .U1zBZslS6Ox_PFdKuPbfeMY0hlUBwRAXggBGsacqed5HBt7QoCRS8z7zAAA pXokBve0V8rSoPnsAENuZffZJfw.1ztYCDzdgWv2uvzaCRRi.reFs_rqLmq9 .Kg3ldvoKzBahoTWgO.mJZ9npO2f3ElB_h9X_iKr3PfuAixK4gMvBW4WKSAD uhQl0rwCdauxkypXWUe93oblsNk3Umj__vy2QtiRBcKEeE9uFPLsY6_mjFMX G7dPUdYZt8Yn85TsxUP0eV_6mjrDong6qygZBqst7DJ8LRqx2gFtYqCNtRtM Hn1WWbw055n4WKxRWnITiQpbsB21Ovv8lUuaeS8ow30AvdfjqN4huT78VYgd Hc31EnVlZcx0h.czoCihzCCy4bOadCblJX8L7Ror7UAyT4W.MYKKPphjh4p0 .2KEzb5oDbPcSj7ME2YMZrm7sHWr.Aw-- Received: from [174.48.128.27] by web121601.mail.ne1.yahoo.com via HTTP; Wed, 09 Jan 2013 10:08:44 PST X-Rocket-MIMEInfo: 001.001, DQoNCi0tLSBPbiBUdWUsIDEvOC8xMywgTWFyayBBdGtpbnNvbiA8YXRraW45MDFAZ21haWwuY29tPiB3cm90ZToNCg0KPiBGcm9tOiBNYXJrIEF0a2luc29uIDxhdGtpbjkwMUBnbWFpbC5jb20.DQo.IFN1YmplY3Q6IFJlOiBUbyBTTVAgb3Igbm90IHRvIFNNUA0KPiBUbzogZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmcNCj4gRGF0ZTogVHVlc2RheSwgSmFudWFyeSA4LCAyMDEzLCAxMToyOSBBTQ0KPiAtLS0tLUJFR0lOIFBHUCBTSUdORUQgTUVTU0FHRS0tLS0tDQo.IEhhc2g6IFNIQTENCj4gDQo.IE9uIDAxLzABMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.130.494 Message-ID: <1357754924.51744.YahooMailClassic@web121601.mail.ne1.yahoo.com> Date: Wed, 9 Jan 2013 10:08:44 -0800 (PST) From: Barney Cordoba Subject: Re: To SMP or not to SMP To: Mark Atkinson In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jan 2013 18:08:51 -0000 --- On Tue, 1/8/13, Mark Atkinson wrote: > From: Mark Atkinson > Subject: Re: To SMP or not to SMP > To: freebsd-net@freebsd.org > Date: Tuesday, January 8, 2013, 11:29 AM > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01/07/2013 18:25, Barney Cordoba wrote: > > I have a situation where I have to run 9.1 on an old > single core > > box. Does anyone have a handle on whether it's better > to build a > > non SMP kernel or to just use a standard SMP build with > just the > > one core? Thanks. > > You can build a SMP kernel, but you'll get better > performance (in my > experience) with SCHED_4BSD on single cpu than with ULE. > I've tested the 2 schedulers on an SMP kernel with 1 core. I don't have a 1 core system to test with so I'm using an E5520 with 1 core enabled. Bridging a controlled test (curl-loader doing a web-load test with 100 users that consistently generates 870Mb/s and 77Kpps, I see the following: top -SH ULE: idle: 74.85% kernel {em1 que} 17.68% kernel {em0 que} 5.86% httpd: .49% 4BSD: idle: 70.95% kernel {em1 que} 18.07% kernel {em0 que} 4.44% httpd: .93% Note that the https is a monitor I'm running. so it appears that theres 7% of usage missing (all other apps show 0% usage). If i had to guess just looking at the numbers, it seems that 4BSD might do better with the interrupt level stuff, and not as good with user level context switching. I think they're close enough to stick with ULE so I can just use a stock kernel. One thing that bothers me is the idle sits at 100% when other tasks are registering values under light loads, so it's certainly not all that accurate. BC From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 19:42:04 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8915782C for ; Wed, 9 Jan 2013 19:42:04 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id E785A8E9 for ; Wed, 9 Jan 2013 19:42:03 +0000 (UTC) Received: (qmail 16111 invoked from network); 9 Jan 2013 21:05:44 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 9 Jan 2013 21:05:44 -0000 Message-ID: <50EDC801.8060101@freebsd.org> Date: Wed, 09 Jan 2013 20:41:53 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: panics in soabort with so_count != 0, one possible solution to one cause. References: <50ED8B27.8070708@netasq.com> <20130109171253.GO66284@FreeBSD.org> In-Reply-To: <20130109171253.GO66284@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Steve Read , Vijay Singh , rwatson@FreeBSD.org, freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jan 2013 19:42:04 -0000 On 09.01.2013 18:12, Gleb Smirnoff wrote: > On Wed, Jan 09, 2013 at 04:22:15PM +0100, Steve Read wrote: > S> Context for this message: > S> http://www.freebsd.org/cgi/query-pr.cgi?pr=145825&cat=kern > S> > S> kern/145825: [panic] panic: soabort: so_count > S> > S> AND > S> > S> http://www.freebsd.org/cgi/query-pr.cgi?pr=159621 > S> kern/159621: [tcp] [panic] panic: soabort: so_count > S> > S> The two PRs are essentially reporting the same thing, and I have seen > S> evidence of people reporting this panic against kernels as old as 6.2. > S> > S> == Scenario == > S> The basic scenario is: > S> 1. There is a local listening TCP socket. A userland thread is waiting > S> on a kqueue, and will eventually call accept() on this socket. > S> 2. A new TCP connection arrives that matches this TCP socket. Syncache > S> hangs on to the connection until the three-way handshake is complete > S> (i.e. the ACK arrives). > S> 3. At this point, syncache_socket() calls sonewconn() and passes > S> SS_ISCONNECTED. sonewconn() as a result hands the new socket off to the > S> accept queue and wakes up the userland thread (marks the listening > S> socket "readable", sends a kqueue notification, etc.). > S> 4. Something goes wrong during the rest of syncache_socket(), as a > S> result of which it calls soabort(). > S> > S> == Consequence == > S> On a single-CPU machine, the netisr thread that called syncache_socket() > S> blocks out the userland thread until it has finished, so so_count of the > S> new connected socket is still zero when syncache_socket() calls > S> soabort(). (It's not absolutely guaranteed, as there are calls to > S> locking functions along the way, but it usually happens.) > S> > S> On a multi-CPU machine of any sort, the userland thread resumes > S> immediately that it is woken up, and it is possible (but not guaranteed) > S> for it to grab the socket and increment its so_count before > S> syncache_socket() calls soabort(). > S> > S> I have a core which shows the netisr thread hitting the panic in > S> soabort(), while the expected userland thread (on a different CPU) is > S> still in the kernel, churning through the post-pickup part of accept(). > S> > S> == Proposed solution == > S> My proposed solution to this issue is: > S> 1. Replace SS_ISCONNECTED with 0 in the call to sonewconn() to prevent > S> it from waking up the listening thread. > S> 2. At the "end" of syncache_socket(), call soisconnected(), passing the > S> new socket. This will issue the wakeup after syncache_socket() has > S> finished preparing itself, and in particular after the last possible > S> call to soabort(). > S> > S> I'm concerned, of course, that this may cause some unobvious fallout > S> somewhere, but I can't see for the moment what it would be. Any advice > S> would be welcome. > S> > S> == Patch that applies the proposed solution == > S> A patch that would apply to kernel 8.3 (the basic scenario appears to > S> still be feasible with HEAD, and the code is very similar): > S> > S> ====== > S> --- netinet/tcp_syncache.c.orig 2013-01-09 13:18:05.000000000 +0000 > S> +++ netinet/tcp_syncache.c 2013-01-09 14:03:54.000000000 +0000 > S> @@ -638,7 +638,7 @@ > S> * connection when the SYN arrived. If we can't create > S> * the connection, abort it. > S> */ > S> - so = sonewconn(lso, SS_ISCONNECTED); > S> + so = sonewconn(lso, 0); > S> if (so == NULL) { > S> /* > S> * Drop the connection; we will either send a RST or > S> @@ -831,6 +831,8 @@ > S> > S> INP_WUNLOCK(inp); > S> > S> + soisconnected(so); > S> + > S> TCPSTAT_INC(tcps_accepts); > S> return (so); > > AFAIU, in head this race was fixed by r243627. Can Vijay and Andre comment? No, this is a different problem. Here it is a race with the newly created socket that is not fully set up yet. The socket structure itself is set up but the INPCB/TCPCB is not yet finished. The new socket is not locked but already placed on the accept queue as fully set up. From there is may get picked up by userspace already. There are a numner of things that can go wrong in syncache_socket() like insertion into the INPCBHASH. External influence by way of RST or such is not a problem and not part of the problem I think. When syncache_socket() decides to abort the socket it calls soabort(), which is an internal quick cleanup that assumes that no consumers of the socket exist yet. In this case this isn't true as another core has already snatched up this socket and delivered to userspace. The locking model on accept sockets unfortunately is not fully refined yet. There are three possible ways to fix this as I can see at the moment: 1. the proposed patch going through the incomplete accept queue first; 2. lock the newly created socket; 3. defer adding the socket to the complete accept queue without going through the incomplete queue for a few cycles. The first one is the simplest and carries the lowest risk at the expense of a bit of unnecessary work. The second one requires an extension of the current locking model (or lack thereof in this area) and needs more work to get everything right, also for other protocols. sonewconn() would then return a locked socket. Current callers do not expect that. The third one would add a special case to sonewconn() at the callers request foregoing the incomplete queue. For now I'd say the first option, the proposed patch, is the way to go as it has the lowest risk with only little overhead. And it is easy to MFC. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 21:13:10 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4F61A882 for ; Wed, 9 Jan 2013 21:13:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2EA70E4E for ; Wed, 9 Jan 2013 21:13:10 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4FC78B91E; Wed, 9 Jan 2013 16:13:09 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: bpf hold buffer in-use flag Date: Wed, 9 Jan 2013 15:35:04 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <9C928117-2230-4F01-9B95-B6D945AF4416@gmail.com> In-Reply-To: <9C928117-2230-4F01-9B95-B6D945AF4416@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301091535.04904.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 09 Jan 2013 16:13:09 -0500 (EST) Cc: Guy Helmer X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jan 2013 21:13:10 -0000 On Tuesday, November 13, 2012 4:40:57 pm Guy Helmer wrote: > To try to completely resolve the race in bpfread(), I have put together these changes to add a flag to indicate when the hold buffer cannot be modified because it is in use. Since it's my first time using mtx_sleep() and wakeup(), I wanted to run these past the list to see if I can get any feedback on the approach. > > > Index: bpf.c > =================================================================== > --- bpf.c (revision 242997) > +++ bpf.c (working copy) > @@ -819,6 +819,7 @@ bpfopen(struct cdev *dev, int flags, int fmt, stru > * particular buffer method. > */ > bpf_buffer_init(d); > + d->bd_hbuf_in_use = 0; > d->bd_bufmode = BPF_BUFMODE_BUFFER; > d->bd_sig = SIGIO; > d->bd_direction = BPF_D_INOUT; > @@ -872,6 +873,9 @@ bpfread(struct cdev *dev, struct uio *uio, int iof > callout_stop(&d->bd_callout); > timed_out = (d->bd_state == BPF_TIMED_OUT); > d->bd_state = BPF_IDLE; > + while (d->bd_hbuf_in_use) > + mtx_sleep(&d->bd_hbuf_in_use, &d->bd_lock, > + PRINET|PCATCH, "bd_hbuf", 0); You need to check the return value here, otherwise the PCATCH is useless (you will just go back to sleep instead of failing with an error if this is interrupted by a signal). -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 21:13:12 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 04071883 for ; Wed, 9 Jan 2013 21:13:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id D7064E4F for ; Wed, 9 Jan 2013 21:13:11 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3A836B943; Wed, 9 Jan 2013 16:13:11 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: To SMP or not to SMP Date: Wed, 9 Jan 2013 15:54:43 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <1357743631.24911.YahooMailClassic@web121605.mail.ne1.yahoo.com> In-Reply-To: <1357743631.24911.YahooMailClassic@web121605.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301091554.43618.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 09 Jan 2013 16:13:11 -0500 (EST) Cc: Barney Cordoba , erichsfreebsdlist@alogt.com, jack.vogel@gmail.com, atkin901@gmail.com, sthaug@nethelp.no X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jan 2013 21:13:12 -0000 On Wednesday, January 09, 2013 10:00:31 am Barney Cordoba wrote: > > --- On Wed, 1/9/13, sthaug@nethelp.no wrote: > > > From: sthaug@nethelp.no > > Subject: Re: To SMP or not to SMP > > To: erichsfreebsdlist@alogt.com > > Cc: barney_cordoba@yahoo.com, freebsd-net@freebsd.org, jack.vogel@gmail.com, atkin901@gmail.com > > Date: Wednesday, January 9, 2013, 9:32 AM > > > > 4BSD runs pretty well with > > an SMP kernel. I can test ULE and compare > > > > easily. A no SMP kernel is problematic as the igb > > driver doesn't seem > > > > to work and my onboard NICs are, sadly, igb. > > > > > > > this is bad luck. I know of the kernels as I have had > > SMP and single > > > CPU machines since 4.x times. > > > > I have had igb working with both SMP and non-SMP kernel for > > at least a > > year or two, 8.x-STABLE. No specific problems. > > > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > > > > Maybe a problem with "legacy interrupts" on more modern processors? > I'm using an E5520 and while the NIC inits ok, it just doesnt seem to > gen interrupts. I can't spend much time debugging it.... > > I notice that HAMMER kernels use MSI/X interrupts whether SMP is enabled > or not, while i386 kernels seem to require APIC. Is there some physical > reason for this? MSI always requires APIC. (MSI interrupts on x86 have to be delivered to a local APIC, no way to send them to 8259As.) You can build an i386 kernel with device apic but without 'options SMP' which is akin to leaving SMP out of an amd64 kernel. Removing SMP on x86 changes the following things: - Spin mutexes just disable interrupts on the local CPU and don't use any atomic operations at all. All other lock types work the same. - atomic operations don't use the "lock" prefix so are cheaper. However, the atomic op used for locks (cmpxchg) has an implicit "lock" prefix, so this isn't but so much of a gain. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 23:42:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A97F36E1; Wed, 9 Jan 2013 23:42:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 049C03D9; Wed, 9 Jan 2013 23:42:22 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r09NgGCg016497; Thu, 10 Jan 2013 01:42:16 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r09NgGCg016497 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r09NgFV6016496; Thu, 10 Jan 2013 01:42:15 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 10 Jan 2013 01:42:15 +0200 From: Konstantin Belousov To: John Baldwin Subject: Re: To SMP or not to SMP Message-ID: <20130109234215.GK2561@kib.kiev.ua> References: <1357743631.24911.YahooMailClassic@web121605.mail.ne1.yahoo.com> <201301091554.43618.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EVcIhgQsEzAXu06J" Content-Disposition: inline In-Reply-To: <201301091554.43618.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Barney Cordoba , freebsd-net@freebsd.org, erichsfreebsdlist@alogt.com, jack.vogel@gmail.com, atkin901@gmail.com, sthaug@nethelp.no X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jan 2013 23:42:23 -0000 --EVcIhgQsEzAXu06J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 09, 2013 at 03:54:43PM -0500, John Baldwin wrote: > On Wednesday, January 09, 2013 10:00:31 am Barney Cordoba wrote: > >=20 > > --- On Wed, 1/9/13, sthaug@nethelp.no wrote: > >=20 > > > From: sthaug@nethelp.no > > > Subject: Re: To SMP or not to SMP > > > To: erichsfreebsdlist@alogt.com > > > Cc: barney_cordoba@yahoo.com, freebsd-net@freebsd.org,=20 > jack.vogel@gmail.com, atkin901@gmail.com > > > Date: Wednesday, January 9, 2013, 9:32 AM > > > > > 4BSD runs pretty well with > > > an SMP kernel. I can test ULE and compare > > > > > easily. A no SMP kernel is problematic as the igb > > > driver doesn't seem > > > > > to work and my onboard NICs are, sadly, igb.=20 > > > > >=20 > > > > this is bad luck. I know of the kernels as I have had > > > SMP and single > > > > CPU machines since 4.x times. > > >=20 > > > I have had igb working with both SMP and non-SMP kernel for > > > at least a > > > year or two, 8.x-STABLE. No specific problems. > > >=20 > > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > > >=20 > >=20 > > Maybe a problem with "legacy interrupts" on more modern processors? > > I'm using an E5520 and while the NIC inits ok, it just doesnt seem to > > gen interrupts. I can't spend much time debugging it.... > >=20 > > I notice that HAMMER kernels use MSI/X interrupts whether SMP is enabled > > or not, while i386 kernels seem to require APIC. Is there some physical > > reason for this? >=20 > MSI always requires APIC. (MSI interrupts on x86 have to be delivered to= a=20 > local APIC, no way to send them to 8259As.) You can build an i386 kernel= with=20 > device apic but without 'options SMP' which is akin to leaving SMP out of= an=20 > amd64 kernel. >=20 > Removing SMP on x86 changes the following things: > - Spin mutexes just disable interrupts on the local CPU and don't use any > atomic operations at all. All other lock types work the same. > - atomic operations don't use the "lock" prefix so are cheaper. However,= the > atomic op used for locks (cmpxchg) has an implicit "lock" prefix, so th= is > isn't but so much of a gain. I do not think that cmpxchg uses implicit lock, and Intel IA32 SDM supports this view. The absense of the lock prefix makes the instruction decode faster, and removes the locked bus cycle. It is xchg which is implicitely locked, but we no longer use it for unlock. --EVcIhgQsEzAXu06J Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ7gBUAAoJEJDCuSvBvK1Bp5MP/0sfhpAgyKogFDXv/hB+WRnF G5RcN/Hid8J7LAO9y5j1OeWs1mL/nR7zQDknqICE4qx5cl/W7hAqm1KR2Tkxc/bo luStOwjl2ktf0PA45istAvxf8Md+z+9HMPZCR8unnQkm3WijKdtns7FKgM9XMCa/ /XW1p5slRNwCoo24JVC9asLdS3ZareVLSo9L92b1BFxV4RHQtDxQ4FL/JYngDH2t r3TLS7Zzby9wIWNz+yXqZIzL8VSAkQrsKYjZebfDLbWDuPheIRqA6LX+bZMhe5mf syYcGLV+T9iAptJNmVMYgZjdhqQSlh8Mx+jQ6nt+f6AAjp9Z4Q+HRjIclSiPLnyD 8t2RTlKtJvxE34ByyhD5C04JzyiGXw1U2rQVqLeLEb8HOc9J1qL2cJLuAzxADXu2 TN3f+j8MGx1x4L2hER0vc7uJBpP1sDHKl0SsmFpgkh+rWrnqHEovv+59ZxHjpwSW 8AsulX4u0BqWeBKNlU3lEFiH/1Aly9pwCL/4axus1MzOX4iYh0mSpwE8IAALvBSq FHr71CeBUVDWQ1pGZmmf08v2CTuHD10xk+JFCRja03c6+CvdrDJnnfCCKuKlfiBA mm5cTrFjxxav9K6gg2YOYzTI6iakwreRsgDBdUDfN3qiWGK0obqxpguI/Yji3w6c 2DPvrcZeSsEJh6gAK/KV =vWZT -----END PGP SIGNATURE----- --EVcIhgQsEzAXu06J-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 10 00:18:56 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7F0623F4 for ; Thu, 10 Jan 2013 00:18:56 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id 482B9939 for ; Thu, 10 Jan 2013 00:18:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=fJ0hr0pWvSgvmvfJzRWktG5XCW73XczSTtKMMtbq4uI=; b=W51TnPfb9vEQSxQ3FKe+mprnNMGUzoDeF86jWUWvKOymyuPQMLtt3kGVSJwMzBfhFIV40FXBHw7Z2YtU+LchOo0XGSSWKfUu/X2rDuJC6PxZSuHVXjzxvnuzfXeNEyMF; Received: from [122.129.203.50] (port=34143 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Tt5rC-000sVz-A6; Wed, 09 Jan 2013 17:18:54 -0700 Date: Thu, 10 Jan 2013 07:18:50 +0700 From: Erich Dollansky To: Barney Cordoba Subject: Re: To SMP or not to SMP Message-ID: <20130110071850.191a257c@X220.ovitrap.com> In-Reply-To: <1357742133.9692.YahooMailClassic@web121601.mail.ne1.yahoo.com> References: <20130109211439.5b590bf5@X220.ovitrap.com> <1357742133.9692.YahooMailClassic@web121601.mail.ne1.yahoo.com> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-net@freebsd.org, jack.vogel@gmail.com, Mark Atkinson X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jan 2013 00:18:56 -0000 Hi, On Wed, 9 Jan 2013 06:35:33 -0800 (PST) Barney Cordoba wrote: > > This explanation defies the possibility of a GENERIC kernel, which > of course is an important element of a GPOS. Its too bad that smp > support can't be done with logic rather than a kernel option. > it seems to me that you have a very simply view on what SMP means for software. > The big thing I see is the use of legacy interrupts vs msix. Its not > like flipping off SMP support only changes the scheduler behavior. SMP goes into the applications. A single-CPU kernel must still run these kind of applications. Erich From owner-freebsd-net@FreeBSD.ORG Thu Jan 10 00:25:49 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7127761E for ; Thu, 10 Jan 2013 00:25:49 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by mx1.freebsd.org (Postfix) with ESMTP id 2F47599A for ; Thu, 10 Jan 2013 00:25:48 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id za17so2875633obc.31 for ; Wed, 09 Jan 2013 16:25:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=oznL197C0mVjVRtTTt5XlVez8lTWoKfOCIABa3dd5XA=; b=FA+FbFa50NFnQf20UVUjfJ4cfTngZu7KTzboIiMCUcZYV/SuB/8r9IHCcDaPccvc92 XkK9wxriUr5nYE+3NTAwCUgr5pw35Hq8iyVJzpmaVvFmb2u42AU9pmRg4SziU/aN3Mwl HaZq2i3T51jABesrspfPhfonFqaLus81qa+lpjuSgv8cFiQKrhGE9Q0yb2Y0d2B2mItX wRSJCiXgdC8jdDChVUlcjycPsoYvmCckNPE1cdoW9sSsu1jJrnIBXLmXGU21Y7kd3cEk XrhhsqG1xsTuDdM1fl3o9tLIMvfX8pTkrRD7ZKcNBGJFV2KvAhkw4c+GB+aR7w3t2uIT 3rMQ== MIME-Version: 1.0 Received: by 10.182.157.44 with SMTP id wj12mr49510014obb.41.1357777541800; Wed, 09 Jan 2013 16:25:41 -0800 (PST) Received: by 10.60.119.9 with HTTP; Wed, 9 Jan 2013 16:25:41 -0800 (PST) In-Reply-To: <20130110071850.191a257c@X220.ovitrap.com> References: <20130109211439.5b590bf5@X220.ovitrap.com> <1357742133.9692.YahooMailClassic@web121601.mail.ne1.yahoo.com> <20130110071850.191a257c@X220.ovitrap.com> Date: Wed, 9 Jan 2013 16:25:41 -0800 Message-ID: Subject: Re: To SMP or not to SMP From: Michael Sierchio To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlV7bSaYQbA9+cIqpYK5l1nIXFE1A8fXZ2m4IDAQ00nZZ44Hnw78iQymi5E/a96OwnxqGcE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jan 2013 00:25:49 -0000 On Wed, Jan 9, 2013 at 4:18 PM, Erich Dollansky wrote: > SMP goes into the applications. A single-CPU kernel must still run > these kind of applications. Applications may be multithreaded - and on a host with more than one (real or virtual) CPU, those threads may run concurrently. De quoi s'agit-il? What's your point? - M From owner-freebsd-net@FreeBSD.ORG Thu Jan 10 00:42:49 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2551B9B0 for ; Thu, 10 Jan 2013 00:42:49 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id E891EA31 for ; Thu, 10 Jan 2013 00:42:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=6HwhlJZM4HS3q2EdXsEk9uKWzPdUJqw3AxOYjXciKQI=; b=Nvp0HKCEikOoBK5H2HBSBtuNpVXBjWHiuCROxaOhg9Cm8EPeJRHeXcdf6BWr3m/yxd14C9TFkSsuC1LY0BMEQCGuOT1BUIRLZLIxNWB0LmR6V3A3LJ8Bqail84uP03EX; Received: from [122.129.203.50] (port=27797 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Tt6EJ-000zcX-4Q; Wed, 09 Jan 2013 17:42:47 -0700 Date: Thu, 10 Jan 2013 07:42:44 +0700 From: Erich Dollansky To: Michael Sierchio Subject: Re: To SMP or not to SMP Message-ID: <20130110074244.6c105264@X220.ovitrap.com> In-Reply-To: References: <20130109211439.5b590bf5@X220.ovitrap.com> <1357742133.9692.YahooMailClassic@web121601.mail.ne1.yahoo.com> <20130110071850.191a257c@X220.ovitrap.com> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jan 2013 00:42:49 -0000 Hi, On Wed, 9 Jan 2013 16:25:41 -0800 Michael Sierchio wrote: > On Wed, Jan 9, 2013 at 4:18 PM, Erich Dollansky > wrote: > > > SMP goes into the applications. A single-CPU kernel must still run > > these kind of applications. > > Applications may be multithreaded - and on a host with more than one > (real or virtual) CPU, those threads may run concurrently. De quoi > s'agit-il? What's your point? they call those OS functions to handle mutexes etc. Some of these things can be simpler when only a single CPU is present. I do not know if there is a difference in FreeBSD. With other words, it is a bit more complex than just an if instruction in the kernel to decide what should be done. This is the reason why the decision is made at compile time and not at run time. Erich > > - M > _______________________________________________ > 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 Thu Jan 10 01:38:47 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F307116D for ; Thu, 10 Jan 2013 01:38:46 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm40-vm4.bullet.mail.ne1.yahoo.com (nm40-vm4.bullet.mail.ne1.yahoo.com [98.138.229.180]) by mx1.freebsd.org (Postfix) with ESMTP id B5023D04 for ; Thu, 10 Jan 2013 01:38:46 +0000 (UTC) Received: from [98.138.90.51] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jan 2013 01:38:39 -0000 Received: from [98.138.89.254] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jan 2013 01:38:39 -0000 Received: from [127.0.0.1] by omp1046.mail.ne1.yahoo.com with NNFMP; 10 Jan 2013 01:38:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 922599.68529.bm@omp1046.mail.ne1.yahoo.com Received: (qmail 12554 invoked by uid 60001); 10 Jan 2013 01:38:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1357781919; bh=qq0IFnL1Texq09Iy5LNjOnH6taG99dj/wQNSFiiOBQU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2fC0rdUOHsKdeXRlsoe2JqZBCdsPdiXLu7eRTWVvWCmPOwJeqKWa+/cPSVc/142cX/9wFb6iPWM/HVGPw8TAkpgHbi5Tsk3X6fYLEa4/QhK66KX0gvcWqePgeQjQEE2hbIyv/6Ql4F5+zIbtpXFEr0hjfiF8SEPCWnHKCMzSkVk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=f+zAPhHFTGwK7iIzg/CTZNCgKBFhdq4QQo39XMZMB3akhmBWagNHAlX+xlHZcdYULynYi8AtfzxGsaBS4rv5Y6N9BSFK32/lt91eW1uImBC1Qm41TXVrWDMKpTT51C4BVfqV3bub5sFxA/DtAaNrJgkd0nev2kySWEBtzvM5AaI=; X-YMail-OSG: XIRz4usVM1mbrnEIlr0DqIIRytNtcOOinn5W30uuwqDaeB0 tUhCVrRvJlpBmUy8TARNfGf0NbS9yX2LyVIpXTlT9nKb3K7tFfhruMBCYF9R FzC5FUxgKUfT8j_.YW.kBvu.J2K9ybr6BQLTAhQYLEcdBvswd4BfUkLU8ZKk hylSHgDn0Wx1hlULLcy4uHVRvC.J5bwGfp5vdj4YJBZ_xuHzTRKXX6rAcjiD Hu1kyBGHp9Gs4plcdc7mI4EaciU5xdgBnp.NwJxFI2HpRW9Bxeo5qv5oM3yo djeCfw8xx4kAYZDJ2k8K7JFr.FXwnJep2nRzajewK3CX6BwfMI2I39wbIpDi 6w.qx1kcwoI4rFWxOCyT.823496axlAV1M_r6cfZsPq3HcSOoO5WO.1J.pjv hMh31n3oVqsFTHGrBaZI.glOG90UZFt0vCC4NvTdf7ARf6435yU_zakEG9cZ hNS2HkyB_BxUkayC6ILnz1CQGc0HjnLBNwdwvWA1O.meuFFCYdS09amMcn38 x.QUuBBIxLw6VzsRpzA4FXUe6Nb016A-- Received: from [174.48.128.27] by web121602.mail.ne1.yahoo.com via HTTP; Wed, 09 Jan 2013 17:38:39 PST X-Rocket-MIMEInfo: 001.001, DQoNCi0tLSBPbiBXZWQsIDEvOS8xMywgQmFybmV5IENvcmRvYmEgPGJhcm5leV9jb3Jkb2JhQHlhaG9vLmNvbT4gd3JvdGU6DQoNCj4gRnJvbTogQmFybmV5IENvcmRvYmEgPGJhcm5leV9jb3Jkb2JhQHlhaG9vLmNvbT4NCj4gU3ViamVjdDogUmU6IFRvIFNNUCBvciBub3QgdG8gU01QDQo.IFRvOiAiTWFyayBBdGtpbnNvbiIgPGF0a2luOTAxQGdtYWlsLmNvbT4NCj4gQ2M6IGZyZWVic2QtbmV0QGZyZWVic2Qub3JnDQo.IERhdGU6IFdlZG5lc2RheSwgSmFudWFyeSA5LCAyMDEzLCAxOjA4IFBNDQo.IA0KPiABMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.130.494 Message-ID: <1357781919.7451.YahooMailClassic@web121602.mail.ne1.yahoo.com> Date: Wed, 9 Jan 2013 17:38:39 -0800 (PST) From: Barney Cordoba Subject: Re: To SMP or not to SMP To: freebsd-net@freebsd.org In-Reply-To: <1357754924.51744.YahooMailClassic@web121601.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jan 2013 01:38:47 -0000 --- On Wed, 1/9/13, Barney Cordoba wrote: > From: Barney Cordoba > Subject: Re: To SMP or not to SMP > To: "Mark Atkinson" > Cc: freebsd-net@freebsd.org > Date: Wednesday, January 9, 2013, 1:08 PM >=20 >=20 > --- On Tue, 1/8/13, Mark Atkinson > wrote: >=20 > > From: Mark Atkinson > > Subject: Re: To SMP or not to SMP > > To: freebsd-net@freebsd.org > > Date: Tuesday, January 8, 2013, 11:29 AM > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > >=20 > > On 01/07/2013 18:25, Barney Cordoba wrote: > > > I have a situation where I have to run 9.1 on an > old > > single core > > > box. Does anyone have a handle on whether it's > better > > to build a > > > non SMP kernel or to just use a standard SMP build > with > > just the > > > one core? Thanks. > >=20 > > You can build a SMP kernel, but you'll get better > > performance (in my > > experience) with SCHED_4BSD on single cpu than with > ULE. > >=20 >=20 > I've tested the 2 schedulers on an SMP kernel with 1 core. I > don't have > a 1 core system to test with so I'm using an E5520 > with=A0 1 core enabled. >=20 > Bridging a controlled test (curl-loader doing a web-load > test with 100=20 > users that consistently generates 870Mb/s and 77Kpps, I see > the following: >=20 > top -SH >=20 > ULE: >=20 > idle: 74.85% > kernel {em1 que} 17.68% > kernel {em0 que} 5.86% > httpd: .49%=A0=20 >=20 > 4BSD: >=20 > idle: 70.95% > kernel {em1 que} 18.07% > kernel {em0 que} 4.44% > httpd: .93% >=20 > Note that the https is a monitor I'm running. >=20 > so it appears that theres 7% of usage missing (all other > apps show 0% > usage).=20 >=20 > If i had to guess just looking at the numbers, it seems that > 4BSD might=20 > do better with the interrupt level stuff, and not as good > with user=20 > level context switching. I think they're close enough to > stick with ULE > so I can just use a stock kernel. >=20 > One thing that bothers me is the idle sits at 100% when > other tasks are=20 > registering values under light loads, so it's certainly not > all that=20 > accurate. >=20 > BC Ok, thanks to J Baldwin's tip I got a NON-SMP kernel running with some interesting results. Here's all 4 tests: I've tested the 2 schedulers on an SMP kernel with 1 core. I don't have a 1 core system to test with so I'm using an E5520 with 1 core enabled. Bridging a controlled test (curl-loader doing a web-load test with 100=20 users that consistently generates 870Mb/s and 77Kpps, I see the following: top -SH ULE (SMP): idle: 74.85% kernel {em1 que} 17.68% kernel {em0 que} 5.86% httpd: .49% =20 4BSD (SMP): idle: 70.95% kernel {em1 que} 18.07% kernel {em0 que} 4.44% httpd: .93% 4BSD (NON-SMP): idle: 72.95% kernel {em1 que} 15.04% kernel {em0 que} 6.10% httpd: 1.17% ULE (NON-SMP): idle: 76.17% kernel {em1 que} 16.99% kernel {em0 que} 5.18% httpd: 1.66% A kernel with SMP off seems to be a bit more efficient. A better test would be to have more stuff running, but Im about out of time on this project. BC From owner-freebsd-net@FreeBSD.ORG Thu Jan 10 19:37:16 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 09D43D31 for ; Thu, 10 Jan 2013 19:37:16 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 9A082386 for ; Thu, 10 Jan 2013 19:37:14 +0000 (UTC) Received: from server.rulingia.com (c220-239-253-186.belrs5.nsw.optusnet.com.au [220.239.253.186]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id r0AJb5MN095832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Jan 2013 06:37:05 +1100 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id r0AJb06K034573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jan 2013 06:37:00 +1100 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id r0AJax8q034572; Fri, 11 Jan 2013 06:36:59 +1100 (EST) (envelope-from peter) Date: Fri, 11 Jan 2013 06:36:59 +1100 From: Peter Jeremy To: Barney Cordoba Subject: Re: To SMP or not to SMP Message-ID: <20130110193659.GA27156@server.rulingia.com> References: <1357611958.66651.YahooMailClassic@web121603.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline In-Reply-To: <1357611958.66651.YahooMailClassic@web121603.mail.ne1.yahoo.com> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jan 2013 19:37:16 -0000 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2013-Jan-07 18:25:58 -0800, Barney Cordoba wr= ote: >I have a situation where I have to run 9.1 on an old single core >box. Does anyone have a handle on whether it's better to build a non >SMP kernel or to just use a standard SMP build with just the one >core? Another input for this decision is kern/173322. Currently on x86, atomic operations within kernel modules are implemented using calls to code in the kernel, which do or don't use lock prefixes depending on whethur the kernel was built as SMP. My proposed change changes kernel modules to inline atomic operations but always include lock prefixes (effectively reverting r49999). I'm appreciate anyone who feels like testing the impact of this change. --=20 Peter Jeremy --2fHTh5uZTiUOsy+g Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDvGFsACgkQ/opHv/APuIdc3QCgsCHQWw6JG2nFg0iWRQDfbWpQ X8kAnROz6oMevcQVqqGDs22nnj/3aFLW =K4kF -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 10 21:12:40 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6802F6F7 for ; Thu, 10 Jan 2013 21:12:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 45B61948 for ; Thu, 10 Jan 2013 21:12:40 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AE1B7B96B; Thu, 10 Jan 2013 16:12:39 -0500 (EST) From: John Baldwin To: Konstantin Belousov Subject: Re: To SMP or not to SMP Date: Thu, 10 Jan 2013 12:17:07 -0500 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <1357743631.24911.YahooMailClassic@web121605.mail.ne1.yahoo.com> <201301091554.43618.jhb@freebsd.org> <20130109234215.GK2561@kib.kiev.ua> In-Reply-To: <20130109234215.GK2561@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201301101217.07833.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 10 Jan 2013 16:12:39 -0500 (EST) Cc: Barney Cordoba , freebsd-net@freebsd.org, erichsfreebsdlist@alogt.com, jack.vogel@gmail.com, atkin901@gmail.com, sthaug@nethelp.no X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jan 2013 21:12:40 -0000 On Wednesday, January 09, 2013 06:42:15 PM Konstantin Belousov wrote: > On Wed, Jan 09, 2013 at 03:54:43PM -0500, John Baldwin wrote: > > On Wednesday, January 09, 2013 10:00:31 am Barney Cordoba wrote: > > > --- On Wed, 1/9/13, sthaug@nethelp.no wrote: > > > > From: sthaug@nethelp.no > > > > Subject: Re: To SMP or not to SMP > > > > To: erichsfreebsdlist@alogt.com > > > > Cc: barney_cordoba@yahoo.com, freebsd-net@freebsd.org, > > > > jack.vogel@gmail.com, atkin901@gmail.com > > > > > > Date: Wednesday, January 9, 2013, 9:32 AM > > > > > > > > > > 4BSD runs pretty well with > > > > > > > > an SMP kernel. I can test ULE and compare > > > > > > > > > > easily. A no SMP kernel is problematic as the igb > > > > > > > > driver doesn't seem > > > > > > > > > > to work and my onboard NICs are, sadly, igb. > > > > > > > > > > this is bad luck. I know of the kernels as I have had > > > > > > > > SMP and single > > > > > > > > > CPU machines since 4.x times. > > > > > > > > I have had igb working with both SMP and non-SMP kernel for > > > > at least a > > > > year or two, 8.x-STABLE. No specific problems. > > > > > > > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > > > > > > Maybe a problem with "legacy interrupts" on more modern processors? > > > I'm using an E5520 and while the NIC inits ok, it just doesnt seem to > > > gen interrupts. I can't spend much time debugging it.... > > > > > > I notice that HAMMER kernels use MSI/X interrupts whether SMP is > > > enabled or not, while i386 kernels seem to require APIC. Is there some > > > physical reason for this? > > > > MSI always requires APIC. (MSI interrupts on x86 have to be delivered to > > a local APIC, no way to send them to 8259As.) You can build an i386 > > kernel with device apic but without 'options SMP' which is akin to > > leaving SMP out of an amd64 kernel. > > > > Removing SMP on x86 changes the following things: > > - Spin mutexes just disable interrupts on the local CPU and don't use any > > atomic operations at all. All other lock types work the same. > > - atomic operations don't use the "lock" prefix so are cheaper. However, the > > atomic op used for locks (cmpxchg) has an implicit "lock" prefix, so > > this isn't but so much of a gain. > > I do not think that cmpxchg uses implicit lock, and Intel IA32 SDM supports > this view. The absense of the lock prefix makes the instruction decode > faster, and removes the locked bus cycle. > > It is xchg which is implicitely locked, but we no longer use it for unlock. Ah, that's true, for some reason I thought cmpxchg was like xchg in this matter. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Jan 10 23:50:32 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 12C8A752 for ; Thu, 10 Jan 2013 23:50:32 +0000 (UTC) (envelope-from prabhakar.lakhera@gmail.com) Received: from mail-vb0-f52.google.com (mail-vb0-f52.google.com [209.85.212.52]) by mx1.freebsd.org (Postfix) with ESMTP id BBF96159 for ; Thu, 10 Jan 2013 23:50:31 +0000 (UTC) Received: by mail-vb0-f52.google.com with SMTP id ez10so904062vbb.39 for ; Thu, 10 Jan 2013 15:50:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Zka6oO8mbRCXrI3YImJ6V1Q5eTMGDAA2khc3pMHbGKs=; b=H6oB5WZonuus/LC03aEXHUDybeeGVrXqKX18TNvR7Ggrnm6G9iO0KU2MJfNm/iEM32 tYiwG7Iz0KySkoiH8X4qZW5b8CT8U3/LzgfYbq/iDJlsdVDw53Xl785HplU2FGFjTf+e 7Q7lgKZtj2Poq3w9efdhohTinfjXwfZA6pQqLjf49Nf2JbU9s4f8hB11/opAzHEDSGsO aXEzd8M0qd0q1DrljyjJZto16VIJRE3t7jtMD/1sH7nTq5vJu7z8HPBYJCXv5VkYwYEk 5n61BC+4wpPVQOvvbKKi6BY+5jGInROTJslJC0LHA9WuM/aENKNlpEmHCR1LScuSfck/ PAoA== MIME-Version: 1.0 Received: by 10.220.219.145 with SMTP id hu17mr91030101vcb.52.1357861830606; Thu, 10 Jan 2013 15:50:30 -0800 (PST) Received: by 10.58.229.197 with HTTP; Thu, 10 Jan 2013 15:50:30 -0800 (PST) Date: Thu, 10 Jan 2013 15:50:30 -0800 Message-ID: Subject: Why did KAME need ND6_LLINFO_WAITDELETE? From: prabhakar lakhera To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jan 2013 23:50:32 -0000 Hi, I see that* ND6_LLINFO_WAITDELETE *was done away with long time back. I was looking for any historical reasons for why it was needed and what triggered its removal. Any pointers will be much appreciated. Thanks! From owner-freebsd-net@FreeBSD.ORG Fri Jan 11 01:48:52 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B1FF373F for ; Fri, 11 Jan 2013 01:48:52 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 7B5DB788 for ; Fri, 11 Jan 2013 01:48:52 +0000 (UTC) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 5F9D1C9476; Fri, 11 Jan 2013 01:48:46 +0000 (UTC) (envelope-from jinmei@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1357868930; bh=nBApH/cpS88YM+ykHKPAiDmTsN8qjSlJF6KgObpX8Kk=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=OEq/qvVKlEYiaokAvxtClx9MhYh+u4gMC6GaYFw0Kn4nYqS6xOl7MnoSXZDgmZ+yA 3QgOJbHREOOc3N3A0i6wPMKx/H7rI43NWuuPLUDAAhMHS09TZ8QhnGyvLiIk7/WL6H GW9RaVXdE2Xc4+BWOXfHg2l2Z20BewjEBCHuBC0U= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Fri, 11 Jan 2013 01:48:46 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from jmb.jinmei.org (99-105-57-202.lightspeed.sntcca.sbcglobal.net [99.105.57.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 1FBDC216C3B; Fri, 11 Jan 2013 01:48:46 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Thu, 10 Jan 2013 17:48:45 -0800 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: prabhakar lakhera Subject: Re: Why did KAME need ND6_LLINFO_WAITDELETE? In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-DCC--Metrics: post.isc.org; whitelist X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mx.pao1.isc.org Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jan 2013 01:48:52 -0000 At Thu, 10 Jan 2013 15:50:30 -0800, prabhakar lakhera wrote: > I see that* ND6_LLINFO_WAITDELETE *was done away with long time back. > I was looking for any historical reasons for why it was needed and what > triggered its removal. I'd normally change history in the original KAME repository: http://www.kame.net/dev/cvsweb2.cgi/kame/kame/sys/netinet6/nd6.h http://www.kame.net/dev/cvsweb2.cgi/kame/kame/sys/netinet6/nd6.c (search for "ND6_LLINFO_WAITDELETE") It looks like it was me who made this change but I don't remember details:-) and I don't have time to look into it closer right now. If the rationale is still not clear from the logs and specific code diffs please ask again. --- JINMEI, Tatuya Internet Systems Consortium, Inc. From owner-freebsd-net@FreeBSD.ORG Fri Jan 11 02:22:22 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5F8FBD54 for ; Fri, 11 Jan 2013 02:22:22 +0000 (UTC) (envelope-from prabhakar.lakhera@gmail.com) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by mx1.freebsd.org (Postfix) with ESMTP id 1BEEB896 for ; Fri, 11 Jan 2013 02:22:21 +0000 (UTC) Received: by mail-vc0-f170.google.com with SMTP id fl11so1017092vcb.1 for ; Thu, 10 Jan 2013 18:22:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0UTDURanjUEUo1C37xOD/YDMGomyLCzgONgqW6Z6n8o=; b=XWiM71eJZ60A+B5nJ4+aPSwQj+lhTQxrfojBPtQCHPeKUR6scnDTm+8Mr6lU7WKocu UMeDG4xFAhcjGEgVXIQmpA+eretkuzTyAmC0gC5S4FZjuV2TBFw0ZZR2BUsOZHp3FAGm EVMFkiEpONXT/4yd5W+RjwYPFVqpwWEDe3P64K4S1W13JZiXe7LNlfzqIPPqFcaj3mhi JAKf3k5AXOfDJP5gmBO0M2ULFXRSMO41VUdQoUot4A39J72qCc1cq86wDSujEQsdAsp5 50mjRyG+j/huUHwiYz5N7eeO9P9zlOatUGmGh87LdEJBfXSoAAUaISStIwb0uxEUodbI CHuw== MIME-Version: 1.0 Received: by 10.52.180.200 with SMTP id dq8mr80401929vdc.71.1357870941215; Thu, 10 Jan 2013 18:22:21 -0800 (PST) Received: by 10.58.229.197 with HTTP; Thu, 10 Jan 2013 18:22:21 -0800 (PST) In-Reply-To: References: Date: Thu, 10 Jan 2013 18:22:21 -0800 Message-ID: Subject: Re: Why did KAME need ND6_LLINFO_WAITDELETE? From: prabhakar lakhera To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jan 2013 02:22:22 -0000 that is more than helpful :) I myself had a panic because of this state and code in nd6_free because I added an assert to catch connectivity issue.. Found out that it was long gone from stock BSD and kame. Thanks for the pointers!! On Thu, Jan 10, 2013 at 5:48 PM, JINMEI Tatuya / 神明達哉 wrote: > At Thu, 10 Jan 2013 15:50:30 -0800, > prabhakar lakhera wrote: > > > I see that* ND6_LLINFO_WAITDELETE *was done away with long time back. > > I was looking for any historical reasons for why it was needed and what > > triggered its removal. > > I'd normally change history in the original KAME repository: > > http://www.kame.net/dev/cvsweb2.cgi/kame/kame/sys/netinet6/nd6.h > http://www.kame.net/dev/cvsweb2.cgi/kame/kame/sys/netinet6/nd6.c > (search for "ND6_LLINFO_WAITDELETE") > > It looks like it was me who made this change but I don't remember > details:-) and I don't have time to look into it closer right now. > If the rationale is still not clear from the logs and specific code > diffs please ask again. > > --- > JINMEI, Tatuya > Internet Systems Consortium, Inc. > From owner-freebsd-net@FreeBSD.ORG Fri Jan 11 05:46:07 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C3670C40; Fri, 11 Jan 2013 05:46:07 +0000 (UTC) (envelope-from tretuliy2@gmail.com) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by mx1.freebsd.org (Postfix) with ESMTP id 59AC8FC9; Fri, 11 Jan 2013 05:46:06 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id l10so1428766oag.22 for ; Thu, 10 Jan 2013 21:46:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=iLznxLRRWgzttZoFQMWQpy/523xMOJXLc0XEPCzZwhs=; b=Xk/myrUBFMqGkQKt6JvGr4BGfVoAKA5DQ2uB6Zf+wUP1xlIqiUGN8EbBoMWIC/gjAI KLQXXeCNQJ+q+K4Ub12vOjcLAMPPjyfG/PpFdkk3Mu3AwiRttcArZyZTtJophZ9vFBDq YgyC0qNiuOy5kVcYe+LSo2/Pfi4m11paSoi2gGyuOQGryaD6Gg0AFjVW7/wrIqlP2Xk8 NafCn88Hhfr7f5PymaJNPWi/H4aLAP/Cjfq4cjIhzo12VbMV/Mx9N8WlbYFFg5cIzzAW eDahc0ORaHs9+171ZpSK25VE2uRtBEn2ccBEx724S8vptdYXNLrLYqvOLqixdIoYTzhn 5yLw== MIME-Version: 1.0 Received: by 10.60.8.199 with SMTP id t7mr42229176oea.26.1357883166269; Thu, 10 Jan 2013 21:46:06 -0800 (PST) Sender: tretuliy2@gmail.com Received: by 10.76.69.68 with HTTP; Thu, 10 Jan 2013 21:46:05 -0800 (PST) Received: by 10.76.69.68 with HTTP; Thu, 10 Jan 2013 21:46:05 -0800 (PST) In-Reply-To: References: <201301101140.r0ABe1J0004000@freefall.freebsd.org> Date: Fri, 11 Jan 2013 07:46:05 +0200 X-Google-Sender-Auth: CmxXwGcLRdw2KYEg_h4xe7C71lk Message-ID: Subject: RE: kern/174749: Unexpected change of default route From: Vadim Urazaev To: =?ISO-8859-2?Q?Radek_Krej=E8a?= Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jan 2013 05:46:07 -0000 Do some body know how can we debug kernel memory corruption on live system? We need to find out which function/subsystem is cause of this mess. Or maybe is there some way to lock particular memory area, where default gateway lies and watch which subsystem will cause system crash? From owner-freebsd-net@FreeBSD.ORG Fri Jan 11 07:52:25 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 43A133C5; Fri, 11 Jan 2013 07:52:25 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 1CAC47DE; Fri, 11 Jan 2013 07:52:25 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r0B7qO94028382; Fri, 11 Jan 2013 07:52:24 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r0B7qOJ6028378; Fri, 11 Jan 2013 07:52:24 GMT (envelope-from linimon) Date: Fri, 11 Jan 2013 07:52:24 GMT Message-Id: <201301110752.r0B7qOJ6028378@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/175182: [panic] kernel panic on RADIX_MPATH when deleting route X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jan 2013 07:52:25 -0000 Old Synopsis: kernel panic on RADIX_MPATH when deleting route New Synopsis: [panic] kernel panic on RADIX_MPATH when deleting route Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jan 11 07:51:36 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=175182 From owner-freebsd-net@FreeBSD.ORG Fri Jan 11 20:42:03 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 624BC93E for ; Fri, 11 Jan 2013 20:42:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3A6DCF71 for ; Fri, 11 Jan 2013 20:42:03 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A6763B963; Fri, 11 Jan 2013 15:42:02 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: To SMP or not to SMP Date: Fri, 11 Jan 2013 10:39:17 -0500 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <1357611958.66651.YahooMailClassic@web121603.mail.ne1.yahoo.com> <20130110193659.GA27156@server.rulingia.com> In-Reply-To: <20130110193659.GA27156@server.rulingia.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201301111039.17673.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 11 Jan 2013 15:42:02 -0500 (EST) Cc: Barney Cordoba , Peter Jeremy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jan 2013 20:42:03 -0000 On Thursday, January 10, 2013 02:36:59 PM Peter Jeremy wrote: > On 2013-Jan-07 18:25:58 -0800, Barney Cordoba wrote: > >I have a situation where I have to run 9.1 on an old single core > >box. Does anyone have a handle on whether it's better to build a non > >SMP kernel or to just use a standard SMP build with just the one > >core? > > Another input for this decision is kern/173322. Currently on x86, > atomic operations within kernel modules are implemented using calls > to code in the kernel, which do or don't use lock prefixes depending > on whethur the kernel was built as SMP. My proposed change changes > kernel modules to inline atomic operations but always include lock > prefixes (effectively reverting r49999). I'm appreciate anyone who > feels like testing the impact of this change. Presumably a locked atomic op is cheaper than a function call then? The current setup assumes the opposite. I think we should actually do this for atomics in modules on x86: 1) If a module is built standalone, it should do whichever is cheaper: a function call or always use "LOCK". 2) If a module is built as part of the kernel build, it should use inlined atomics that match what the kernel does. Thus, modules built with a non-SMP kernel would use inlined atomic ops that do not use LOCK. We have a way to detect this now (some HAVE_FOO #define added in the past few years) that we didn't back when this bit of atomic.h was written. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Jan 11 23:49:04 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DF53FBE8 for ; Fri, 11 Jan 2013 23:49:04 +0000 (UTC) (envelope-from csjp@sqrt.ca) Received: from sub.sqrt.ca (sub.sqrt.ca [205.200.235.40]) by mx1.freebsd.org (Postfix) with ESMTP id B946DA0D for ; Fri, 11 Jan 2013 23:49:03 +0000 (UTC) Received: by sub.sqrt.ca (Postfix, from userid 58) id 5D2F9B82B; Fri, 11 Jan 2013 17:48:57 -0600 (CST) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sub X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 Received: from [IPv6:::1] (localhost [127.0.0.1]) by sub.sqrt.ca (Postfix) with ESMTP id 69F42B819; Fri, 11 Jan 2013 17:48:53 -0600 (CST) Subject: Re: bpf hold buffer in-use flag Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Christian Peron In-Reply-To: <9C928117-2230-4F01-9B95-B6D945AF4416@gmail.com> Date: Fri, 11 Jan 2013 17:48:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0AAF6A81-2594-449E-A38D-28DE5B055AFF@sqrt.ca> References: <9C928117-2230-4F01-9B95-B6D945AF4416@gmail.com> To: Guy Helmer X-Mailer: Apple Mail (2.1283) Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jan 2013 23:49:04 -0000 Guy, Can you please describe the race and how to reproduce it? When we = introduced zerocopy-bpf, we also introduced bpf_bufheld() and = bpf_bufreclaimed() which are effectively hops for the regular buffer = mode. Maybe we could maintain state there as well? In any case, I would = like to understand the race/and reproduce it Thanks! On 2012-11-13, at 3:40 PM, Guy Helmer wrote: > To try to completely resolve the race in bpfread(), I have put = together these changes to add a flag to indicate when the hold buffer = cannot be modified because it is in use. Since it's my first time using = mtx_sleep() and wakeup(), I wanted to run these past the list to see if = I can get any feedback on the approach. >=20 >=20 > Index: bpf.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- bpf.c (revision 242997) > +++ bpf.c (working copy) > @@ -819,6 +819,7 @@ bpfopen(struct cdev *dev, int flags, int fmt, stru > * particular buffer method. > */ > bpf_buffer_init(d); > + d->bd_hbuf_in_use =3D 0; > d->bd_bufmode =3D BPF_BUFMODE_BUFFER; > d->bd_sig =3D SIGIO; > d->bd_direction =3D BPF_D_INOUT; > @@ -872,6 +873,9 @@ bpfread(struct cdev *dev, struct uio *uio, int iof > callout_stop(&d->bd_callout); > timed_out =3D (d->bd_state =3D=3D BPF_TIMED_OUT); > d->bd_state =3D BPF_IDLE; > + while (d->bd_hbuf_in_use) > + mtx_sleep(&d->bd_hbuf_in_use, &d->bd_lock, > + PRINET|PCATCH, "bd_hbuf", 0); > /* > * If the hold buffer is empty, then do a timed sleep, which > * ends when the timeout expires or when enough packets > @@ -940,27 +944,27 @@ bpfread(struct cdev *dev, struct uio *uio, int = iof > /* > * At this point, we know we have something in the hold slot. > */ > + d->bd_hbuf_in_use =3D 1; > BPFD_UNLOCK(d); >=20 > /* > * Move data from hold buffer into user space. > * We know the entire buffer is transferred since > * we checked above that the read buffer is bpf_bufsize bytes. > - * > - * XXXRW: More synchronization needed here: what if a second = thread > - * issues a read on the same fd at the same time? Don't want = this > - * getting invalidated. > + * > + * We do not have to worry about simultaneous reads because > + * we waited for sole access to the hold buffer above. > */ > error =3D bpf_uiomove(d, d->bd_hbuf, d->bd_hlen, uio); >=20 > BPFD_LOCK(d); > - if (d->bd_hbuf !=3D NULL) { > - /* Free the hold buffer only if it is still valid. */ > - d->bd_fbuf =3D d->bd_hbuf; > - d->bd_hbuf =3D NULL; > - d->bd_hlen =3D 0; > - bpf_buf_reclaimed(d); > - } > + KASSERT(d->bd_hbuf !=3D NULL, ("bpfread: lost bd_hbuf")); > + d->bd_fbuf =3D d->bd_hbuf; > + d->bd_hbuf =3D NULL; > + d->bd_hlen =3D 0; > + bpf_buf_reclaimed(d); > + d->bd_hbuf_in_use =3D 0; > + wakeup(&d->bd_hbuf_in_use); > BPFD_UNLOCK(d); >=20 > return (error); > @@ -1114,6 +1118,9 @@ reset_d(struct bpf_d *d) >=20 > BPFD_LOCK_ASSERT(d); >=20 > + while (d->bd_hbuf_in_use) > + mtx_sleep(&d->bd_hbuf_in_use, &d->bd_lock, PRINET, > + "bd_hbuf", 0); > if ((d->bd_hbuf !=3D NULL) && > (d->bd_bufmode !=3D BPF_BUFMODE_ZBUF || bpf_canfreebuf(d))) = { > /* Free the hold buffer. */ > @@ -1254,6 +1261,9 @@ bpfioctl(struct cdev *dev, u_long cmd, caddr_t = add >=20 > BPFD_LOCK(d); > n =3D d->bd_slen; > + while (d->bd_hbuf_in_use) > + mtx_sleep(&d->bd_hbuf_in_use, = &d->bd_lock, > + PRINET, "bd_hbuf", 0); > if (d->bd_hbuf) > n +=3D d->bd_hlen; > BPFD_UNLOCK(d); > @@ -1967,6 +1977,9 @@ filt_bpfread(struct knote *kn, long hint) > ready =3D bpf_ready(d); > if (ready) { > kn->kn_data =3D d->bd_slen; > + while (d->bd_hbuf_in_use) > + mtx_sleep(&d->bd_hbuf_in_use, &d->bd_lock, > + PRINET, "bd_hbuf", 0); > if (d->bd_hbuf) > kn->kn_data +=3D d->bd_hlen; > } else if (d->bd_rtout > 0 && d->bd_state =3D=3D BPF_IDLE) { > @@ -2299,6 +2312,9 @@ catchpacket(struct bpf_d *d, u_char *pkt, u_int = pk > * spot to do it. > */ > if (d->bd_fbuf =3D=3D NULL && bpf_canfreebuf(d)) { > + while (d->bd_hbuf_in_use) > + mtx_sleep(&d->bd_hbuf_in_use, &d->bd_lock, > + PRINET, "bd_hbuf", 0); > d->bd_fbuf =3D d->bd_hbuf; > d->bd_hbuf =3D NULL; > d->bd_hlen =3D 0; > @@ -2341,6 +2357,9 @@ catchpacket(struct bpf_d *d, u_char *pkt, u_int = pk > ++d->bd_dcount; > return; > } > + while (d->bd_hbuf_in_use) > + mtx_sleep(&d->bd_hbuf_in_use, &d->bd_lock, > + PRINET, "bd_hbuf", 0); > ROTATE_BUFFERS(d); > do_wakeup =3D 1; > curlen =3D 0; > Index: bpf.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- bpf.h (revision 242997) > +++ bpf.h (working copy) > @@ -1235,7 +1235,8 @@ SYSCTL_DECL(_net_bpf); > /* > * Rotate the packet buffers in descriptor d. Move the store buffer = into the > * hold slot, and the free buffer ino the store slot. Zero the length = of the > - * new store buffer. Descriptor lock should be held. > + * new store buffer. Descriptor lock should be held. Hold buffer = must > + * not be marked "in use". > */ > #define ROTATE_BUFFERS(d) do { = \ > (d)->bd_hbuf =3D (d)->bd_sbuf; = \ > Index: bpf_buffer.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- bpf_buffer.c (revision 242997) > +++ bpf_buffer.c (working copy) > @@ -189,6 +189,9 @@ bpf_buffer_ioctl_sblen(struct bpf_d *d, u_int *i) > return (EINVAL); > } >=20 > + while (d->bd_hbuf_in_use) > + mtx_sleep(&d->bd_hbuf_in_use, &d->bd_lock, > + PRINET, "bd_hbuf", 0); > /* Free old buffers if set */ > if (d->bd_fbuf !=3D NULL) > free(d->bd_fbuf, M_BPF); > Index: bpfdesc.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- bpfdesc.h (revision 242997) > +++ bpfdesc.h (working copy) > @@ -63,6 +63,7 @@ struct bpf_d { > caddr_t bd_sbuf; /* store slot */ > caddr_t bd_hbuf; /* hold slot */ > caddr_t bd_fbuf; /* free slot */ > + int bd_hbuf_in_use; /* don't rotate buffers */ > int bd_slen; /* current length of store = buffer */ > int bd_hlen; /* current length of hold buffer = */ >=20 > _______________________________________________ > 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 Jan 11 23:50:28 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EFFE4CE8 for ; Fri, 11 Jan 2013 23:50:28 +0000 (UTC) (envelope-from csjp@sqrt.ca) Received: from sub.sqrt.ca (sub.sqrt.ca [205.200.235.40]) by mx1.freebsd.org (Postfix) with ESMTP id CA29DA29 for ; Fri, 11 Jan 2013 23:50:28 +0000 (UTC) Received: by sub.sqrt.ca (Postfix, from userid 58) id 110C8B82B; Fri, 11 Jan 2013 17:50:28 -0600 (CST) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sub X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 Received: from [IPv6:::1] (localhost [127.0.0.1]) by sub.sqrt.ca (Postfix) with ESMTP id B8B5FB819; Fri, 11 Jan 2013 17:50:23 -0600 (CST) Subject: Re: bpf hold buffer in-use flag Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Christian Peron In-Reply-To: <0AAF6A81-2594-449E-A38D-28DE5B055AFF@sqrt.ca> Date: Fri, 11 Jan 2013 17:50:23 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9C928117-2230-4F01-9B95-B6D945AF4416@gmail.com> <0AAF6A81-2594-449E-A38D-28DE5B055AFF@sqrt.ca> To: Guy Helmer X-Mailer: Apple Mail (2.1283) Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Jan 2013 23:50:29 -0000 I meant "nops" for the regular buffer mode=85 On 2013-01-11, at 5:48 PM, Christian Peron wrote: > Guy, >=20 > Can you please describe the race and how to reproduce it? When we = introduced zerocopy-bpf, we also introduced bpf_bufheld() and = bpf_bufreclaimed() which are effectively hops for the regular buffer = mode. Maybe we could maintain state there as well? In any case, I would = like to understand the race/and reproduce it >=20 > Thanks! >=20 > On 2012-11-13, at 3:40 PM, Guy Helmer wrote: >=20 >> To try to completely resolve the race in bpfread(), I have put = together these changes to add a flag to indicate when the hold buffer = cannot be modified because it is in use. Since it's my first time using = mtx_sleep() and wakeup(), I wanted to run these past the list to see if = I can get any feedback on the approach. >>=20 >>=20 >> Index: bpf.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- bpf.c (revision 242997) >> +++ bpf.c (working copy) >> @@ -819,6 +819,7 @@ bpfopen(struct cdev *dev, int flags, int fmt, = stru >> * particular buffer method. >> */ >> bpf_buffer_init(d); >> + d->bd_hbuf_in_use =3D 0; >> d->bd_bufmode =3D BPF_BUFMODE_BUFFER; >> d->bd_sig =3D SIGIO; >> d->bd_direction =3D BPF_D_INOUT; >> @@ -872,6 +873,9 @@ bpfread(struct cdev *dev, struct uio *uio, int = iof >> callout_stop(&d->bd_callout); >> timed_out =3D (d->bd_state =3D=3D BPF_TIMED_OUT); >> d->bd_state =3D BPF_IDLE; >> + while (d->bd_hbuf_in_use) >> + mtx_sleep(&d->bd_hbuf_in_use, &d->bd_lock, >> + PRINET|PCATCH, "bd_hbuf", 0); >> /* >> * If the hold buffer is empty, then do a timed sleep, which >> * ends when the timeout expires or when enough packets >> @@ -940,27 +944,27 @@ bpfread(struct cdev *dev, struct uio *uio, int = iof >> /* >> * At this point, we know we have something in the hold slot. >> */ >> + d->bd_hbuf_in_use =3D 1; >> BPFD_UNLOCK(d); >>=20 >> /* >> * Move data from hold buffer into user space. >> * We know the entire buffer is transferred since >> * we checked above that the read buffer is bpf_bufsize bytes. >> - * >> - * XXXRW: More synchronization needed here: what if a second = thread >> - * issues a read on the same fd at the same time? Don't want = this >> - * getting invalidated. >> + * >> + * We do not have to worry about simultaneous reads because >> + * we waited for sole access to the hold buffer above. >> */ >> error =3D bpf_uiomove(d, d->bd_hbuf, d->bd_hlen, uio); >>=20 >> BPFD_LOCK(d); >> - if (d->bd_hbuf !=3D NULL) { >> - /* Free the hold buffer only if it is still valid. */ >> - d->bd_fbuf =3D d->bd_hbuf; >> - d->bd_hbuf =3D NULL; >> - d->bd_hlen =3D 0; >> - bpf_buf_reclaimed(d); >> - } >> + KASSERT(d->bd_hbuf !=3D NULL, ("bpfread: lost bd_hbuf")); >> + d->bd_fbuf =3D d->bd_hbuf; >> + d->bd_hbuf =3D NULL; >> + d->bd_hlen =3D 0; >> + bpf_buf_reclaimed(d); >> + d->bd_hbuf_in_use =3D 0; >> + wakeup(&d->bd_hbuf_in_use); >> BPFD_UNLOCK(d); >>=20 >> return (error); >> @@ -1114,6 +1118,9 @@ reset_d(struct bpf_d *d) >>=20 >> BPFD_LOCK_ASSERT(d); >>=20 >> + while (d->bd_hbuf_in_use) >> + mtx_sleep(&d->bd_hbuf_in_use, &d->bd_lock, PRINET, >> + "bd_hbuf", 0); >> if ((d->bd_hbuf !=3D NULL) && >> (d->bd_bufmode !=3D BPF_BUFMODE_ZBUF || bpf_canfreebuf(d))) = { >> /* Free the hold buffer. */ >> @@ -1254,6 +1261,9 @@ bpfioctl(struct cdev *dev, u_long cmd, caddr_t = add >>=20 >> BPFD_LOCK(d); >> n =3D d->bd_slen; >> + while (d->bd_hbuf_in_use) >> + mtx_sleep(&d->bd_hbuf_in_use, = &d->bd_lock, >> + PRINET, "bd_hbuf", 0); >> if (d->bd_hbuf) >> n +=3D d->bd_hlen; >> BPFD_UNLOCK(d); >> @@ -1967,6 +1977,9 @@ filt_bpfread(struct knote *kn, long hint) >> ready =3D bpf_ready(d); >> if (ready) { >> kn->kn_data =3D d->bd_slen; >> + while (d->bd_hbuf_in_use) >> + mtx_sleep(&d->bd_hbuf_in_use, &d->bd_lock, >> + PRINET, "bd_hbuf", 0); >> if (d->bd_hbuf) >> kn->kn_data +=3D d->bd_hlen; >> } else if (d->bd_rtout > 0 && d->bd_state =3D=3D BPF_IDLE) { >> @@ -2299,6 +2312,9 @@ catchpacket(struct bpf_d *d, u_char *pkt, u_int = pk >> * spot to do it. >> */ >> if (d->bd_fbuf =3D=3D NULL && bpf_canfreebuf(d)) { >> + while (d->bd_hbuf_in_use) >> + mtx_sleep(&d->bd_hbuf_in_use, &d->bd_lock, >> + PRINET, "bd_hbuf", 0); >> d->bd_fbuf =3D d->bd_hbuf; >> d->bd_hbuf =3D NULL; >> d->bd_hlen =3D 0; >> @@ -2341,6 +2357,9 @@ catchpacket(struct bpf_d *d, u_char *pkt, u_int = pk >> ++d->bd_dcount; >> return; >> } >> + while (d->bd_hbuf_in_use) >> + mtx_sleep(&d->bd_hbuf_in_use, &d->bd_lock, >> + PRINET, "bd_hbuf", 0); >> ROTATE_BUFFERS(d); >> do_wakeup =3D 1; >> curlen =3D 0; >> Index: bpf.h >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- bpf.h (revision 242997) >> +++ bpf.h (working copy) >> @@ -1235,7 +1235,8 @@ SYSCTL_DECL(_net_bpf); >> /* >> * Rotate the packet buffers in descriptor d. Move the store buffer = into the >> * hold slot, and the free buffer ino the store slot. Zero the length = of the >> - * new store buffer. Descriptor lock should be held. >> + * new store buffer. Descriptor lock should be held. Hold buffer = must >> + * not be marked "in use". >> */ >> #define ROTATE_BUFFERS(d) do { = \ >> (d)->bd_hbuf =3D (d)->bd_sbuf; = \ >> Index: bpf_buffer.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- bpf_buffer.c (revision 242997) >> +++ bpf_buffer.c (working copy) >> @@ -189,6 +189,9 @@ bpf_buffer_ioctl_sblen(struct bpf_d *d, u_int *i) >> return (EINVAL); >> } >>=20 >> + while (d->bd_hbuf_in_use) >> + mtx_sleep(&d->bd_hbuf_in_use, &d->bd_lock, >> + PRINET, "bd_hbuf", 0); >> /* Free old buffers if set */ >> if (d->bd_fbuf !=3D NULL) >> free(d->bd_fbuf, M_BPF); >> Index: bpfdesc.h >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- bpfdesc.h (revision 242997) >> +++ bpfdesc.h (working copy) >> @@ -63,6 +63,7 @@ struct bpf_d { >> caddr_t bd_sbuf; /* store slot */ >> caddr_t bd_hbuf; /* hold slot */ >> caddr_t bd_fbuf; /* free slot */ >> + int bd_hbuf_in_use; /* don't rotate buffers */ >> int bd_slen; /* current length of store = buffer */ >> int bd_hlen; /* current length of hold buffer = */ >>=20 >> _______________________________________________ >> 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 > _______________________________________________ > 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 Sat Jan 12 07:28:56 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 97C53954 for ; Sat, 12 Jan 2013 07:28:56 +0000 (UTC) (envelope-from cvs-src@yandex.ru) Received: from forward5h.mail.yandex.net (forward5h.mail.yandex.net [IPv6:2a02:6b8:0:f05::5]) by mx1.freebsd.org (Postfix) with ESMTP id 4817C907 for ; Sat, 12 Jan 2013 07:28:56 +0000 (UTC) Received: from smtp4h.mail.yandex.net (smtp4h.mail.yandex.net [84.201.186.21]) by forward5h.mail.yandex.net (Yandex) with ESMTP id 9A325D00E0F for ; Sat, 12 Jan 2013 11:28:53 +0400 (MSK) Received: from smtp4h.mail.yandex.net (localhost [127.0.0.1]) by smtp4h.mail.yandex.net (Yandex) with ESMTP id 784742C0293 for ; Sat, 12 Jan 2013 11:28:53 +0400 (MSK) Received: from unknown (unknown [178.76.224.133]) by smtp4h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id SqH8x0FO-SrHKMKoe; Sat, 12 Jan 2013 11:28:53 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1357975733; bh=GjkqA0m+GM0LlKIV04pnOSfQyxZ+f2DOc4ShM7dTBes=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: Content-Type:Content-Transfer-Encoding; b=E6E7z5RxFZc9NrN/n3QEI5PqOcg6KHEHvWZHm9Idn/cYIETqy/f2wTHZmT1hJszuU T5NlPoz9WIKPkinUQWOF9FVYP65V9Q3AvL55pzLRQcqnIZrk2xXyPMhvCQ3c1KvWbZ pGQ84n9FrifyCFFBnqa6La3lBXAnanncXftAM2Iw= Message-ID: <50F110AB.1030107@yandex.ru> Date: Sat, 12 Jan 2013 11:28:43 +0400 From: Ruslan Makhmatkhanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: if_vr(4) and Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jan 2013 07:28:56 -0000 Hello, I bought two D-link DFE520-TX ethernet adapters that supposed to work with if_vr(4) according to man-page. But the driver cannot attach (tested in 9.1-R and pfSense 2.0.2/2.1 (8.1-R and 8.3-R respectively)). none2@pci0:4:0:0: class=0x020000 card=0x11031186 chip=0x42001186 rev=0x10 hdr=0x00 vendor = 'D-Link System Inc' class = network subclass = ethernet Can please anybody suggest proper changes for /sys/dev/vr/if_vrreg.h|if_vr.c (pci ids would be enought, right?) to test if it works. Thanks in advance. -- Regards, Ruslan Tinderboxing kills... the drives. From owner-freebsd-net@FreeBSD.ORG Sat Jan 12 11:27:09 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 98E1221F for ; Sat, 12 Jan 2013 11:27:09 +0000 (UTC) (envelope-from cvs-src@yandex.ru) Received: from forward2h.mail.yandex.net (forward2h.mail.yandex.net [IPv6:2a02:6b8:0:f05::2]) by mx1.freebsd.org (Postfix) with ESMTP id 283C917B for ; Sat, 12 Jan 2013 11:27:08 +0000 (UTC) Received: from smtp1h.mail.yandex.net (smtp1h.mail.yandex.net [84.201.187.144]) by forward2h.mail.yandex.net (Yandex) with ESMTP id 63C6A70074D for ; Sat, 12 Jan 2013 15:27:05 +0400 (MSK) Received: from smtp1h.mail.yandex.net (localhost [127.0.0.1]) by smtp1h.mail.yandex.net (Yandex) with ESMTP id 3D70C13402C4; Sat, 12 Jan 2013 15:27:05 +0400 (MSK) Received: from unknown (unknown [77.66.155.61]) by smtp1h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id R40CWok8-R40mxfUt; Sat, 12 Jan 2013 15:27:05 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1357990025; bh=H5ZeG5ZcKPPydBtT9aYQdS02MBspGlYna84vkSLl8nQ=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=abjxpv64ZTDEsh6DLY6Y5uuCVIA7zGIxmD4LRRnEKFNz5ALalILMS8RBWLObE19eO IrX0V9BUOvL6lvkrx611ixYOTzDs++m5jbYq0VgzPWJeBeon7x/1lBzFqD/UP21AvY jmf/vA3YdagOxpRY5zioFRGoveFvRvPoVcmwh9d4= Message-ID: <50F14880.4090001@yandex.ru> Date: Sat, 12 Jan 2013 15:26:56 +0400 From: Ruslan Makhmatkhanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: if_vr(4) and DFE520-TX References: <50F110AB.1030107@yandex.ru> In-Reply-To: <50F110AB.1030107@yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: cvs-src@yandex.ru X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jan 2013 11:27:09 -0000 Here is also verbose boot log for what it's worth: http://pastebin.com/SnivrtFr Please keep me in cc:, I'm not subscribed. Thanks. Ruslan Makhmatkhanov wrote on 12.01.2013 11:28: > Hello, > > I bought two D-link DFE520-TX ethernet adapters that supposed to work > with if_vr(4) according to man-page. But the driver cannot attach > (tested in 9.1-R and pfSense 2.0.2/2.1 (8.1-R and 8.3-R respectively)). > > none2@pci0:4:0:0: class=0x020000 card=0x11031186 chip=0x42001186 > rev=0x10 hdr=0x00 > vendor = 'D-Link System Inc' > class = network > subclass = ethernet > > Can please anybody suggest proper changes for > /sys/dev/vr/if_vrreg.h|if_vr.c (pci ids would be enought, right?) to > test if it works. Thanks in advance. -- Regards, Ruslan Tinderboxing kills... the drives. From owner-freebsd-net@FreeBSD.ORG Sat Jan 12 14:49:25 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 15BC994F for ; Sat, 12 Jan 2013 14:49:25 +0000 (UTC) (envelope-from cvs-src@yandex.ru) Received: from forward4h.mail.yandex.net (forward4h.mail.yandex.net [IPv6:2a02:6b8:0:f05::4]) by mx1.freebsd.org (Postfix) with ESMTP id 89ED6AEC for ; Sat, 12 Jan 2013 14:49:24 +0000 (UTC) Received: from smtp1h.mail.yandex.net (smtp1h.mail.yandex.net [84.201.187.144]) by forward4h.mail.yandex.net (Yandex) with ESMTP id 247E91B21591 for ; Sat, 12 Jan 2013 18:49:23 +0400 (MSK) Received: from smtp1h.mail.yandex.net (localhost [127.0.0.1]) by smtp1h.mail.yandex.net (Yandex) with ESMTP id E383B13401D2; Sat, 12 Jan 2013 18:49:22 +0400 (MSK) Received: from unknown (unknown [77.66.155.61]) by smtp1h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id nM00R2u7-nM0Olmwc; Sat, 12 Jan 2013 18:49:22 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1358002162; bh=fZsZAOwfNUcuzte6E+uFh060+A3O5zjv/zlTeoIjR10=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type; b=SflkHVFdFclxRJ7m5sPhMiFrWYLSdxV9oVfS8D/JzqWdr7XzLo6Ysku44+0pip4mb lgzT9aOd1jfJHcoTfEKUWrE/7wafbtQrlwLsCiR5qWWKEY3XQ1tF6+3ZweGb3sR8Pq TuZcX5AKaAKH1iOSa/43N5YUT+vCk29Yud+f0gsk= Message-ID: <50F177E9.3040003@yandex.ru> Date: Sat, 12 Jan 2013 18:49:13 +0400 From: Ruslan Makhmatkhanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ruslan Makhmatkhanov Subject: Re: if_vr(4) and DFE520-TX References: <50F110AB.1030107@yandex.ru> <50F14880.4090001@yandex.ru> In-Reply-To: <50F14880.4090001@yandex.ru> Content-Type: multipart/mixed; boundary="------------060106060202080800060809" Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jan 2013 14:49:25 -0000 This is a multi-part message in MIME format. --------------060106060202080800060809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ok, I got some details. It's an DFE-520TX (/C1 or rev. C1). I crafted an patch attached, but whenever kldloading the modified if_vr, I got this: kernel: vr0: port 0xd100-0xd1ff mem 0xf7c11000-0xf7c110ff irq 19 at device 0.0 on pci4 kernel: vr0: Quirks: 0x0 kernel: vr0: Revision: 0x10 kernel: vr0: reset never completed! kernel: vr0: attaching PHYs failed kernel: device_attach: vr0 attach returned 6 kernel: vr0: port 0xd000-0xd0ff mem 0xf7c10000-0xf7c100ff irq 16 at device 1.0 on pci4 kernel: vr0: Quirks: 0x0 kernel: vr0: Revision: 0x10 kernel: vr0: reset never completed! kernel: vr0: attaching PHYs failed kernel: device_attach: vr0 attach returned 6 I also tried to apply VR_Q_NEEDALIGN quirk, but nothing is changed. Any hints? Ruslan Makhmatkhanov wrote on 12.01.2013 15:26: > > Here is also verbose boot log for what it's worth: > http://pastebin.com/SnivrtFr > > Please keep me in cc:, I'm not subscribed. Thanks. > > Ruslan Makhmatkhanov wrote on 12.01.2013 11:28: >> Hello, >> >> I bought two D-link DFE520-TX ethernet adapters that supposed to work >> with if_vr(4) according to man-page. But the driver cannot attach >> (tested in 9.1-R and pfSense 2.0.2/2.1 (8.1-R and 8.3-R respectively)). >> >> none2@pci0:4:0:0: class=0x020000 card=0x11031186 chip=0x42001186 >> rev=0x10 hdr=0x00 >> vendor = 'D-Link System Inc' >> class = network >> subclass = ethernet >> >> Can please anybody suggest proper changes for >> /sys/dev/vr/if_vrreg.h|if_vr.c (pci ids would be enought, right?) to >> test if it works. Thanks in advance. > -- Regards, Ruslan Tinderboxing kills... the drives. --------------060106060202080800060809 Content-Type: text/plain; charset=UTF-8; name="vr-4200.diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vr-4200.diff.txt" diff -uN vr.orig/if_vr.c vr/if_vr.c --- vr.orig/if_vr.c 2013-01-12 13:19:28.000000000 +0400 +++ vr/if_vr.c 2013-01-12 18:42:52.000000000 +0400 @@ -138,6 +138,9 @@ { DELTA_VENDORID, DELTA_DEVICEID_RHINE_II, VR_Q_NEEDALIGN, "Delta Electronics Rhine II 10/100BaseTX" }, + { DLINK_VENDORID, DLINK_DEVICEID_RHINE_II, + 0, + "D-Link System Inc 4200 10/100BaseTX" }, { ADDTRON_VENDORID, ADDTRON_DEVICEID_RHINE_II, VR_Q_NEEDALIGN, "Addtron Technology Rhine II 10/100BaseTX" }, diff -uN vr.orig/if_vrreg.h vr/if_vrreg.h --- vr.orig/if_vrreg.h 2013-01-12 13:19:28.000000000 +0400 +++ vr/if_vrreg.h 2013-01-12 14:29:26.000000000 +0400 @@ -557,6 +557,16 @@ #define DELTA_DEVICEID_RHINE_II 0x1320 /* + * D-Link System Inc device ID. + */ +#define DLINK_VENDORID 0x1186 + +/* + * D-Link System Inc device IDs. + */ +#define DLINK_DEVICEID_RHINE_II 0x4200 + +/* * Addtron vendor ID. */ #define ADDTRON_VENDORID 0x4033 --------------060106060202080800060809--