From owner-freebsd-net@FreeBSD.ORG Sun Apr 26 12:38:47 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D84110656E2; Sun, 26 Apr 2009 12:38:47 +0000 (UTC) (envelope-from anchie@fer.hr) Received: from labs4.cc.fer.hr (labs4.cc.fer.hr [161.53.72.24]) by mx1.freebsd.org (Postfix) with ESMTP id CE08D8FC21; Sun, 26 Apr 2009 12:38:46 +0000 (UTC) (envelope-from anchie@fer.hr) Received: from sluga.fer.hr (sluga.cc.fer.hr [161.53.72.14]) by labs4.cc.fer.hr (8.14.2/8.14.2) with ESMTP id n3QCKaXd027517; Sun, 26 Apr 2009 14:20:37 +0200 (CEST) Received: from ana-kukecs-macbook.local ([89.164.49.202]) by sluga.fer.hr with Microsoft SMTPSVC(6.0.3790.3959); Sun, 26 Apr 2009 14:20:15 +0200 Message-ID: <49F4517E.5080005@fer.hr> Date: Sun, 26 Apr 2009 14:20:14 +0200 From: Ana Kukec User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2009 12:20:15.0400 (UTC) FILETIME=[5ACCB280:01C9C669] X-Scanned-By: MIMEDefang 2.64 on 161.53.72.24 Cc: freebsd-net@freebsd.org Subject: GSoC - SeND X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 12:38:49 -0000 Hi all, I am Ana Kukec, a research assistant and a PhD student at University of Zagreb. I will be working on the IPv6 Secure Neighbor Discovery (SeND - rfc3971, rfc4861) - the implementation of native kernel APIs for FreeBSD, within GSoC, with my mentor Bjoern Zeeb. More informations will be provided on http://wiki.freebsd.org/SOC2009AnaKukec. Regards, Ana From owner-freebsd-net@FreeBSD.ORG Sun Apr 26 14:54:06 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6EDE106564A for ; Sun, 26 Apr 2009 14:54:06 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 9255C8FC14 for ; Sun, 26 Apr 2009 14:54:03 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: by qw-out-2122.google.com with SMTP id 3so1408303qwe.7 for ; Sun, 26 Apr 2009 07:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=RCjEzApPfSik4W6/ua22UoDeTdwKLWN3qG0WVYsYdjw=; b=wL+N9Jz1mXueuip/N9BJN6uu7g56eHQqD+6hdM7E5vkqGCksJEZr9TUUMbEGvCgQU+ Ipz5W1Os8Gdic12RFcAnJc61Byh2qXyc9PUQ5Ki7hkv248gvv7dus+RoANQLp3ObOiQh HA9j2Rfk+kbIysluq3zzWbISUcRTl7/BdQ+Jg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=yCxSvuCgSOz6nRMjSAoaoblvaBmqJs1Cebmfbtvcth6ni3GgJRkz73NyiNpaKTD3Li cy0UCHvjv+biOwIx5TEnoheZ168JpZqw3IH8LBNv5mMJSXfVpZIUozu0zY2UyDeCMXW0 zT3TLDeKbBbTb2f3LrADU5rkYV+jNKO2vPWXw= MIME-Version: 1.0 Received: by 10.220.73.194 with SMTP id r2mr8192700vcj.76.1240756365774; Sun, 26 Apr 2009 07:32:45 -0700 (PDT) Date: Sun, 26 Apr 2009 17:32:45 +0300 Message-ID: From: Maxim Ignatenko To: freebsd-current@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: [dummynet] Several queues connected to one pipe: "dummynet: OUCH! pipe should have been idle!" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 14:54:07 -0000 Hi, I have next dummynet configuration: ipfw pipe 3 bw 3Mbit/s ipfw queue 10 config pipe 3 weight 10 mask src-ip 0xffffffff ipfw queue 11 config pipe 3 weight 10 mask dst-ip 0xffffffff Two queues for different traffic directions connected to one pipe. After update to r191410 my /var/log/messages filled with: Apr 24 16:33:31 imax kernel: dummynet: OUCH! pipe should have been idle! Apr 24 16:33:59 imax last message repeated 8 times Apr 24 16:35:53 imax last message repeated 519 times Apr 24 16:38:55 imax last message repeated 50 times Then I've changed ip_dummynet.c little, to see actual value of pipe->scheduler_heap.elements Here what I've got with one dynamic queue per parent: Apr 25 16:16:34 imax kernel: dummynet: OUCH! pipe should have been idle!SCH len: 2 Apr 25 16:17:05 imax last message repeated 462 times Apr 25 16:18:48 imax last message repeated 1269 times With two queues per parent: Apr 26 16:51:34 imax kernel: dummynet: OUCH! pipe should have been idle!SCH len: 4 Apr 26 16:51:34 imax kernel: dummynet: OUCH! pipe should have been idle!SCH len: 3 Apr 26 16:51:34 imax kernel: dummynet: OUCH! pipe should have been idle!SCH len: 4 Apr 26 16:51:34 imax kernel: dummynet: OUCH! pipe should have been idle!SCH len: 3 Apr 26 16:51:34 imax kernel: dummynet: OUCH! pipe should have been idle!SCH len: 4 Thanks for attention, awaiting your comments and/or suggestions. From owner-freebsd-net@FreeBSD.ORG Sun Apr 26 21:52:33 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF938106564A for ; Sun, 26 Apr 2009 21:52:33 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id B18458FC17 for ; Sun, 26 Apr 2009 21:52:33 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 4B0BF73098; Sun, 26 Apr 2009 23:57:40 +0200 (CEST) Date: Sun, 26 Apr 2009 23:57:40 +0200 From: Luigi Rizzo To: Maxim Ignatenko Message-ID: <20090426215740.GA33188@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, freebsd-current@freebsd.org Subject: Re: [dummynet] Several queues connected to one pipe: "dummynet: OUCH! pipe should have been idle!" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 21:52:34 -0000 On Sun, Apr 26, 2009 at 05:32:45PM +0300, Maxim Ignatenko wrote: > Hi, > > I have next dummynet configuration: > > ipfw pipe 3 bw 3Mbit/s > ipfw queue 10 config pipe 3 weight 10 mask src-ip 0xffffffff > ipfw queue 11 config pipe 3 weight 10 mask dst-ip 0xffffffff > > Two queues for different traffic directions connected to one pipe. > After update to r191410 my /var/log/messages filled with: > Apr 24 16:33:31 imax kernel: dummynet: OUCH! pipe should have been idle! > Apr 24 16:33:59 imax last message repeated 8 times > Apr 24 16:35:53 imax last message repeated 519 times > Apr 24 16:38:55 imax last message repeated 50 times could you give us a few more details on the branch you are using (HEAD or RELENG_7 ?) and what svn revision did you use before the update (which did not show the error) ? thanks luigi From owner-freebsd-net@FreeBSD.ORG Sun Apr 26 22:42:21 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49F84106566C; Sun, 26 Apr 2009 22:42:21 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 07E108FC13; Sun, 26 Apr 2009 22:42:21 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 0ED4473098; Mon, 27 Apr 2009 00:47:29 +0200 (CEST) Date: Mon, 27 Apr 2009 00:47:29 +0200 From: Luigi Rizzo To: Maxim Ignatenko Message-ID: <20090426224729.GA34800@onelab2.iet.unipi.it> References: <20090426215740.GA33188@onelab2.iet.unipi.it> 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, freebsd-current@freebsd.org Subject: Re: [dummynet] Several queues connected to one pipe: "dummynet: OUCH! pipe should have been idle!" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 22:42:21 -0000 On Mon, Apr 27, 2009 at 01:12:55AM +0300, Maxim Ignatenko wrote: > 2009/4/27 Luigi Rizzo : > > > > could you give us a few more details on the branch you > > are using (HEAD or RELENG_7 ?) and what svn revision did > > you use before the update (which did not show the error) ? > > > > Sorry, I've forgot to mention that... > I use HEAD, and before update it was r191201, if I'm not mistaking. ok there seems to be no change related to dummynet between these two versions so I am not sure where to look. Could you double check what is the last working version ? cheers luigi From owner-freebsd-net@FreeBSD.ORG Sun Apr 26 22:45:25 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78D8D10656E2; Sun, 26 Apr 2009 22:45:25 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: from mail-qy0-f105.google.com (mail-qy0-f105.google.com [209.85.221.105]) by mx1.freebsd.org (Postfix) with ESMTP id 176468FC18; Sun, 26 Apr 2009 22:45:24 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: by qyk3 with SMTP id 3so4214576qyk.3 for ; Sun, 26 Apr 2009 15:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xit596j26WvRfOmO5JCVYlwZbROGU/4NaUIuERAdTOM=; b=lAWhExzO26Sp9P54LQfrawxYVastt4YUTU+MjW5QFhlFgbCaDbdTz5JOP5Ucp4OMzK +r/mnt1KolNcM4FpiXUZexcZVD014DtzIWRr+eJ/29LDIde85qwQXyHmKpdy58vZDuE5 JSTRRDJuLEE/aMY/HSbbbpsgDsTsEY4veMM8E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WlmlwOKA/ZKLeDlXUIYVze16LsoCfFw3f08evgGtcXd67cmm/zDR9z5BpkaorpRhoP uzCI0f5QnZoiXit9pSJVEWuBnBht62ATazjH9i9vCHTfQUBwwB1bWMaDkeqgR+aAf2Ux lkAuL6Lh41SYiF0ETR2RO5yXotWL4MhAXd8W8= MIME-Version: 1.0 Received: by 10.220.95.75 with SMTP id c11mr9217280vcn.1.1240783975093; Sun, 26 Apr 2009 15:12:55 -0700 (PDT) In-Reply-To: <20090426215740.GA33188@onelab2.iet.unipi.it> References: <20090426215740.GA33188@onelab2.iet.unipi.it> Date: Mon, 27 Apr 2009 01:12:55 +0300 Message-ID: From: Maxim Ignatenko To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: [dummynet] Several queues connected to one pipe: "dummynet: OUCH! pipe should have been idle!" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 22:45:29 -0000 2009/4/27 Luigi Rizzo : > > could you give us a few more details on the branch you > are using (HEAD or RELENG_7 ?) and what svn revision did > you use before the update (which did not show the error) ? > Sorry, I've forgot to mention that... I use HEAD, and before update it was r191201, if I'm not mistaking. Now I'm just removed queues from ruleset, but I may supply any additional information, if needed. Thanks for attention. From owner-freebsd-net@FreeBSD.ORG Sun Apr 26 23:46:02 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4161B1065711; Sun, 26 Apr 2009 23:46:02 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id D149B8FC18; Sun, 26 Apr 2009 23:46:01 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: by qw-out-2122.google.com with SMTP id 3so1515436qwe.7 for ; Sun, 26 Apr 2009 16:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=N9cng+fsLUwVdXCNYQNwlrYnMQJ7fkXNwPLaf5zLjOA=; b=iNa/cAFrySHk0sQ/XQF9ZYbxa/+QCSc8s6Pb51MccKEmanvcHOcudXeFXPfiCVrsyi SbO35w/YbihcFbZfYWA75XcRt1HN2mWng7VDD3NjK5NUHCQ/3EwYq2oVGjamTJ4U+Jzt W3evEcCm9VmYFSjmwpP3NC8E6VKQz2IrH7htk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DXH+9KKMo5VIuxb6Hd9lZzFpWBAFPHy/FIvyKBi9wffLkWU7EvuYuEfDwJRP/iivlA 1pVHcIvTKfEqIQ3Cdq+O3Czg1GTjYetX+1GeNOvC58YWNKrqN68gPP+xJVduyCYKRLTZ dYVkk3Rvq/U4HRHRUQUNJZjEJH6g/8xjcrpmU= MIME-Version: 1.0 Received: by 10.220.73.194 with SMTP id r2mr9111973vcj.76.1240789561163; Sun, 26 Apr 2009 16:46:01 -0700 (PDT) In-Reply-To: <20090426224729.GA34800@onelab2.iet.unipi.it> References: <20090426215740.GA33188@onelab2.iet.unipi.it> <20090426224729.GA34800@onelab2.iet.unipi.it> Date: Mon, 27 Apr 2009 02:46:01 +0300 Message-ID: From: Maxim Ignatenko To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: [dummynet] Several queues connected to one pipe: "dummynet: OUCH! pipe should have been idle!" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 23:46:03 -0000 2009/4/27 Luigi Rizzo : > On Mon, Apr 27, 2009 at 01:12:55AM +0300, Maxim Ignatenko wrote: >> 2009/4/27 Luigi Rizzo : >> > >> > could you give us a few more details on the branch you >> > are using (HEAD or RELENG_7 ?) and what svn revision did >> > you use before the update (which did not show the error) ? >> > >> >> Sorry, I've forgot to mention that... >> I use HEAD, and before update it was r191201, if I'm not mistaking. > > ok there seems to be no change related to dummynet between these > two versions so I am not sure where to look. > Could you double check what is the last working version ? > > cheers > luigi > OK, I'll try. From owner-freebsd-net@FreeBSD.ORG Mon Apr 27 08:43:44 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A80B1065674; Mon, 27 Apr 2009 08:43:44 +0000 (UTC) (envelope-from raykinsella78@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id B98468FC16; Mon, 27 Apr 2009 08:43:43 +0000 (UTC) (envelope-from raykinsella78@gmail.com) Received: by bwz9 with SMTP id 9so2064852bwz.43 for ; Mon, 27 Apr 2009 01:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=EgL9OfuikxPUuaOQkhhv6hBEs0YxgajW0ZnJZENa4n0=; b=sxaFGPdkm8nw0CSPO4PIhXmMNaMuSrYigaP8I5J37ESCivA7rCooT4PRs5wJZ/6ZlO acbSdBSQSHhJuc5U5tVVO8I1JJN9HT1GFb90DVWtPQx6Z7l9sMZDO8fQxpg09tk7yauF MxR1DgC0VkageEToiqhi4w3JfxocQOhRMaSvU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nHU478wC8tRjwFlDyJ3jSb3PRQ/fNhULLI4bcbOMBzLmGgDL2GzgzHPQzQU3Er4i+O XKmr7z/bQe3qr/IELHoBSGP/CLeEYdkwAGRfTkgSDLSUm0SQmFw2pmmoW4GdsR8sTkik RA1DNdacQ+iU0BA+j9w0Dodurg6d3tj7TxdpI= MIME-Version: 1.0 Received: by 10.239.172.18 with SMTP id y18mr253998hbe.72.1240820320304; Mon, 27 Apr 2009 01:18:40 -0700 (PDT) In-Reply-To: <40bb871a0904241542o3f4d6c6ap62ff71876074bbea@mail.gmail.com> References: <40bb871a0904241542o3f4d6c6ap62ff71876074bbea@mail.gmail.com> Date: Mon, 27 Apr 2009 09:18:40 +0100 Message-ID: <584ec6bb0904270118v37795ee2k24c9262d4c1abd80@mail.gmail.com> From: Ray Kinsella To: Joseph Kuan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, freebsd-performance@freebsd.org, freebsd-threads@freebsd.org Subject: Re: FreeBSD 7.1 taskq em performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 08:43:45 -0000 Joseph, I would recommend that you start with PMCStat and figure where the bottleneck is, Given that you have a two threads and your CPU is at 100%, my a apriori guess would be a contention for a spinlock, so I might also try to use LOCK_PROFILING to handle on this. Regards Ray Kinsella On Fri, Apr 24, 2009 at 11:42 PM, Joseph Kuan wrote: > Hi all, > I have been hitting some barrier with FreeBSD 7.1 network performance. I > have written an application which contains two kernel threads that takes > mbufs directly from a network interface and forwards to another network > interface. This idea is to simulate different network environment. > > I have been using FreeBSD 6.4 amd64 and tested with an Ixia box > (specialised hardware firing very high packet rate). The PC was a Core2 2.6 > GHz with dual ports Intel PCIE Gigabit network card. It can manage up to > 1.2 > million pps. > > I have a higher spec PC with FreeBSD 7.1 amd64 and Quadcore 2.3 GHz and > PCIE Gigabit network card. The performance can only achieve up to 600k pps. > I notice the 'taskq em0' and 'taskq em1' is solid 100% CPU but it is not in > FreeBSD 6.4. > > Any advice? > > Many thanks in advance > > Joe > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to " > freebsd-performance-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Apr 27 11:06:59 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10E90106566B for ; Mon, 27 Apr 2009 11:06:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F0AB38FC13 for ; Mon, 27 Apr 2009 11:06:58 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n3RB6w3p002369 for ; Mon, 27 Apr 2009 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n3RB6wte002365 for freebsd-net@FreeBSD.org; Mon, 27 Apr 2009 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 27 Apr 2009 11:06:58 GMT Message-Id: <200904271106.n3RB6wte002365@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 11:06:59 -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/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) 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/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem o kern/132984 net [netgraph] swi1: net 100% cpu usage f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132715 net [lagg] [panic] Panic when creating vlan's on lagg inte 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/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132625 net [iwn] iwn drivers don't support setting country 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/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o conf/132179 net [patch] /etc/network.subr: ipv6 rtsol on incorrect wla o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us 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 bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw 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 o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation 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/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting 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) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by 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/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card 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/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in 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/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans 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 bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN 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 kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce 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 o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi 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 f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to 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] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel 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/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS 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 kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste 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 a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface 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/114839 net [fxp] fxp looses ability to speak with traffic o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R 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 kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset 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/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads 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/105348 net [ath] ath device stopps TX 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/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac 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 f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in 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 s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate 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 f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting 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/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/87194 net [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress 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 o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern 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/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". 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 o conf/23063 net [arp] [patch] for static ARP tables in rc.network 293 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Apr 27 13:51:20 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 045D6106566B; Mon, 27 Apr 2009 13:51:20 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by mx1.freebsd.org (Postfix) with ESMTP id C45448FC14; Mon, 27 Apr 2009 13:51:19 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: by rv-out-0506.google.com with SMTP id k40so1892458rvb.43 for ; Mon, 27 Apr 2009 06:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=K9kZXc2waraahswZsbYPpi2z31g6TeEZCSVCYg8/M6Q=; b=qsKSBPE4Z8mfCiKzsgsLga1v8tzK9UFjRrG4M281lfis39/5uvHj+jXuI9joarkJ+V LsUrKSK4mw163kQC9MXEyQRKXXudDXwhgoG+W8H43VJrzskXNK+ifkjI3TxwWSDkJY1U ZN6ySCVTwM5XsgpB3jnqsy3nXACHKj0aqSrqY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Ls5aX0pUM3Y6udhg9VhSQt+SOAFKUHmKqRwnx1eywCYS00vl0icGNPYIFE2JJb8LPa +tYobOmmidFzxynK7zVCpWbj4JBHSU1QqKavWJbn2qV+TVdQR1H79wo04LfAs3WlrPrO hqXj+7+MoIsGVbsH3ecu5D4OI6x6w+217blME= MIME-Version: 1.0 Received: by 10.220.77.18 with SMTP id e18mr10498839vck.85.1240840278471; Mon, 27 Apr 2009 06:51:18 -0700 (PDT) In-Reply-To: <20090426224729.GA34800@onelab2.iet.unipi.it> References: <20090426215740.GA33188@onelab2.iet.unipi.it> <20090426224729.GA34800@onelab2.iet.unipi.it> Date: Mon, 27 Apr 2009 16:51:18 +0300 Message-ID: From: Maxim Ignatenko To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: [dummynet] Several queues connected to one pipe: "dummynet: OUCH! pipe should have been idle!" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 13:51:20 -0000 2009/4/27 Luigi Rizzo : > > ok there seems to be no change related to dummynet between these > two versions so I am not sure where to look. > Could you double check what is the last working version ? > Yes, r191201 have this problems too (it seems, i didn't updated for a long time). Now I updated to r190864 (just before last change on ip_dummynet.c) - all works fine. Should I now check r190865? Thanks. From owner-freebsd-net@FreeBSD.ORG Mon Apr 27 13:58:01 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 196F11065672; Mon, 27 Apr 2009 13:58:01 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id CE09E8FC14; Mon, 27 Apr 2009 13:58:00 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id BE61B73098; Mon, 27 Apr 2009 16:03:09 +0200 (CEST) Date: Mon, 27 Apr 2009 16:03:09 +0200 From: Luigi Rizzo To: Maxim Ignatenko Message-ID: <20090427140309.GA62749@onelab2.iet.unipi.it> References: <20090426215740.GA33188@onelab2.iet.unipi.it> <20090426224729.GA34800@onelab2.iet.unipi.it> 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, freebsd-current@freebsd.org Subject: Re: [dummynet] Several queues connected to one pipe: "dummynet: OUCH! pipe should have been idle!" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 13:58:01 -0000 On Mon, Apr 27, 2009 at 04:51:18PM +0300, Maxim Ignatenko wrote: > 2009/4/27 Luigi Rizzo : > > > > ok there seems to be no change related to dummynet between these > > two versions so I am not sure where to look. > > Could you double check what is the last working version ? > > > Yes, r191201 have this problems too (it seems, i didn't updated for a > long time). > Now I updated to r190864 (just before last change on ip_dummynet.c) - > all works fine. Should I now check r190865? yes it would be great if you could identify a specific change that caused the problem. There is one thing particularly tricky in one of the dummynet changes, because some fields changed between 32/64 bits and signed/unsigned. I may have unadvertently introduced some conversion bug. thanks a lot for the feedback cheers luigi From owner-freebsd-net@FreeBSD.ORG Mon Apr 27 14:44:24 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 296111065674; Mon, 27 Apr 2009 14:44:24 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: from mail-qy0-f105.google.com (mail-qy0-f105.google.com [209.85.221.105]) by mx1.freebsd.org (Postfix) with ESMTP id BA2518FC12; Mon, 27 Apr 2009 14:44:23 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: by qyk3 with SMTP id 3so4922306qyk.3 for ; Mon, 27 Apr 2009 07:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=aDS1saeCWxI2pEwFdC7MIWLnd7KMNIRdJ8G9gr7WUSo=; b=h+PoQu4aT4gsVhUysTtXasKT4pqmSyPEfcN3PHbD9sBP2vRSom3d2rrByTZpqzxInO D1U9l0gRpy5cMJogbVbE19N6pnacBDQMnS/laY2bynLucN+HETfov/fXzLmD4hn+3wi0 PIrj38SVnHRyB/NVG4LUbyUmdNuADTJYY0Tw4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NzAtt2iKGKb42X8MxmyoQqGXBPCT9iOqrvPo6LVmwCush7ASbw4dVfhDitphgX21IO ClLYOJM6gTj+2oxgY4KTHifTBeL6DbqkRTx+xDjru4D3KW65xEDJo626Cc73Tz6jlgn0 /jRnreD9/p8yRS6mtHlVpaA0rTazRexkzHAeA= MIME-Version: 1.0 Received: by 10.220.97.75 with SMTP id k11mr10831964vcn.39.1240843462965; Mon, 27 Apr 2009 07:44:22 -0700 (PDT) In-Reply-To: <20090427140309.GA62749@onelab2.iet.unipi.it> References: <20090426215740.GA33188@onelab2.iet.unipi.it> <20090426224729.GA34800@onelab2.iet.unipi.it> <20090427140309.GA62749@onelab2.iet.unipi.it> Date: Mon, 27 Apr 2009 17:44:22 +0300 Message-ID: From: Maxim Ignatenko To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: [dummynet] Several queues connected to one pipe: "dummynet: OUCH! pipe should have been idle!" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 14:44:24 -0000 2009/4/27 Luigi Rizzo : > On Mon, Apr 27, 2009 at 04:51:18PM +0300, Maxim Ignatenko wrote: >> 2009/4/27 Luigi Rizzo : >> > >> > ok there seems to be no change related to dummynet between these >> > two versions so I am not sure where to look. >> > Could you double check what is the last working version ? >> > >> =C2=A0Yes, r191201 have this problems too (it seems, i didn't updated fo= r a >> long time). >> Now =C2=A0I updated to r190864 (just before last change on ip_dummynet.c= ) - >> all works fine. Should I now check r190865? > > yes it would be great if you could identify a specific change that > caused the problem. > There is one thing particularly tricky in one of the dummynet > changes, because some fields changed between 32/64 bits and > signed/unsigned. I may have unadvertently introduced some > conversion bug. > On r190865 problem appeared again. > thanks a lot for the feedback > You welcome :) Thanks. From owner-freebsd-net@FreeBSD.ORG Mon Apr 27 16:11:27 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D8B71065736 for ; Mon, 27 Apr 2009 16:11:27 +0000 (UTC) (envelope-from ddg@yan.com.br) Received: from mail.mastercabo.com.br (mail.mastercabo.com.br [189.91.0.40]) by mx1.freebsd.org (Postfix) with SMTP id 5CD018FC39 for ; Mon, 27 Apr 2009 16:11:17 +0000 (UTC) (envelope-from ddg@yan.com.br) Received: (qmail 81338 invoked by uid 1008); 27 Apr 2009 16:11:15 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-unknown (2008-06-10) on srvmail1 X-Spam-Level: X-Spam-Status: No, score=-1.5 required=4.8 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5-unknown Received: from unknown (HELO ?192.168.0.169?) (daniel@dgnetwork.com.br@189.91.0.65) by mail.mastercabo.com.br with SMTP; 27 Apr 2009 16:11:15 -0000 Message-ID: <49F5D8A3.3050805@yan.com.br> Date: Mon, 27 Apr 2009 13:09:07 -0300 From: =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?= User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Julian Elischer References: <49F06985.1000303@yan.com.br> <49F0A7DD.30206@elischer.org> <49F1DBAE.1080205@yan.com.br> <49F235F4.2030202@elischer.org> In-Reply-To: <49F235F4.2030202@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Re: IPFW MAX RULES COUNT PERFORMANCE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ddg@yan.com.br List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 16:11:40 -0000 Julian, You could give an example of rules with tables? Julian Elischer escreveu: > Daniel Dias Gonçalves wrote: >> Very good thinking, congratulations, but my need is another. >> The objective is a Captive Porrtal that each authentication is >> dynamically created a rule to ALLOW or COUNT IP authenticated, which >> I'm testing is what is the maximum capacity of rules supported, >> therefore simultaneous user. >> >> Understand ? >> > I think so. > > > do not add rules. > have a single rule that looks in a table > and add entries to the table when needed. > >> Thanks, >> >> Daniel >> >> Julian Elischer escreveu: >>> Daniel Dias Gonçalves wrote: >>>> Hi, >>>> >>>> My system is a FreeBSD 7.1R. >>>> When I add rules IPFW COUNT to 254 IPS from my network, one of my >>>> interfaces increases the latency, causing large delays in the >>>> network, when I delete COUNT rules, everything returns to normal, >>>> which can be ? >>>> >>>> My script: >>> >>> of course adding 512 rules, *all of which hav eto be evaluated* will >>> add latency. >>> >>> you have several ways to improve this situation. >>> >>> 1/ use a differnet tool. >>> By using the netgraph netflow module you can get >>> accunting information that may be more useful and less impactful. >>> >>> 2/ you could make your rules smarter.. >>> >>> use skipto rules to make the average packet traverse less rules.. >>> >>> off the top of my head.. (not tested..) >>> >>> Assuming you have machines 10.0.0.1-10.0.0.254.... >>> the rules below have an average packet traversing 19 rules and not >>> 256 for teh SYN packet and 2 rules for others.. >>> you may not be able to do the keep state trick if you use state for >>> other stuff but in that case worst case will still be 19 rules. >>> >>> 2 check-state >>> 5 skipto 10000 ip from not 10.0.0.0/24 to any >>> 10 skipto 2020 ip from not 10.0.0.0/25 to any # 0-128 >>> 20 skipto 1030 ip from not 10.0.0.0/26 to any # 0-64 >>> 30 skipto 240 ip from not 10.0.0.0/27 to any # 0-32 >>> 40 skipto 100 ip from not 10.0.0.0/28 to any # 0-16 >>> [16 count rules for 0-15] >>> 80 skipto 10000 ip from any to any >>> 100 [16 count rules for 16-31] keep-state >>> 140 skipto 10000 ip from any to any >>> 240 skipto 300 ip from not 10.0.0.32/28 >>> [16 rules for 32-47] keep-state >>> 280 skipto 10000 ip from any to any >>> 300 [16 count rules for 48-63] keep-state >>> 340 skipto 10000 ip from any to any >>> 1030 skipto 1240 ip from not 10.0.0.64/27 to any >>> 1040 skipto 1100 ip from not 10.0.0.64/28 to any >>> [16 count rules for 64-79] keep-state >>> 1080 skipto 10000 ip from any to any >>> 1100 [16 rules for 80-95] keep-state >>> 1140 skipto 10000 ip from any to any >>> 1240 skipto 1300 ip from not 10.0.0.96/28 to any >>> [16 count rules for 96-111] keep-state >>> 1280 skipto 10000 ip from any to any >>> 1300 [16 rules for 112-127] keep-state >>> 1340 skipto 10000 ip from any to any >>> 2020 skipto 3030 ip from not 10.0.0.128/26 to any >>> 2030 skipto 2240 ip from not 10.0.0.128/28 to any >>> [16 count rules for 128-143] keep-state >>> 2080 skipto 10000 ip from any to any >>> 2100 [16 rules for 144-159] keep-state >>> 2140 skipto 10000 ip from any to any >>> 2240 skipto 2300 ip from not 10.0.0.32/28 to any >>> [16 count rules for 160-175] keep-state >>> 2280 skipto 10000 ip from any to any >>> 2300 [16 count rules for 176-191] keep-state >>> 2340 skipto 10000 ip from any to any >>> 3030 skipto 3240 ip from not 10.0.0.192/27 to any >>> 3040 skipto 3100 ip from not 10.0.0.192/28 to any >>> [16 count rules for 192-207] keep-state >>> 3080 skipto 10000 ip from any to any >>> 3100 [16 rules for 208-223] keep-state >>> 3240 skipto 10000 ip from any to any >>> 3240 skipto 3300 ip from not 10.0.0.224/28 to any >>> [16 count rules for 224-239] keep-state >>> 3280 skipto 10000 ip from any to any >>> 3300 [16 count rules for 240-255] keep-state >>> 3340 skipto 10000 ip from any to any >>> >>> 10000 #other stuff >>> >>> in fact you could improve it further with: >>> 1/ either going down to a netmask of 29 (8 rules per set) >>> or >>> 2/ instead of having count rules make them skipto >>> so you would have: >>> 3300 skipto 10000 ip from 10.0.0.240 to any >>> 3301 skipto 10000 ip from 10.0.0.241 to any >>> 3302 skipto 10000 ip from 10.0.0.242 to any >>> 3303 skipto 10000 ip from 10.0.0.243 to any >>> 3304 skipto 10000 ip from 10.0.0.244 to any >>> 3305 skipto 10000 ip from 10.0.0.245 to any >>> 3306 skipto 10000 ip from 10.0.0.246 to any >>> 3307 skipto 10000 ip from 10.0.0.247 to any >>> 3308 skipto 10000 ip from 10.0.0.248 to any >>> 3309 skipto 10000 ip from 10.0.0.249 to any >>> 3310 skipto 10000 ip from 10.0.0.240 to any >>> 3311 skipto 10000 ip from 10.0.0.241 to any >>> 3312 skipto 10000 ip from 10.0.0.242 to any >>> 3313 skipto 10000 ip from 10.0.0.243 to any >>> 3314 skipto 10000 ip from 10.0.0.244 to any >>> 3315 skipto 10000 ip from 10.0.0.245 to any >>> >>> thus on average, a packet would traverse half the rules (8). >>> >>> 3/ both the above so on average they would traverse 4 rules plus >>> one extra skipto. >>> >>> you should be able to do the above in a script. >>> I'd love to see it.. >>> >>> (you can also do skipto tablearg in -current (maybe 7.2 too) >>> which may also be good.. (or not)) >>> >>> >>> julian >>> >>> >>> >>> _______________________________________________ >>> 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" >>> >>> > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Mon Apr 27 16:21:40 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC68B106566B for ; Mon, 27 Apr 2009 16:21:40 +0000 (UTC) (envelope-from ddg@yan.com.br) Received: from mail.mastercabo.com.br (mail.mastercabo.com.br [189.91.0.40]) by mx1.freebsd.org (Postfix) with SMTP id 140B08FC0A for ; Mon, 27 Apr 2009 16:21:39 +0000 (UTC) (envelope-from ddg@yan.com.br) Received: (qmail 91718 invoked by uid 1008); 27 Apr 2009 16:21:38 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-unknown (2008-06-10) on srvmail1 X-Spam-Level: X-Spam-Status: No, score=-2.0 required=4.8 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5-unknown Received: from unknown (HELO ?192.168.0.169?) (daniel@dgnetwork.com.br@189.91.0.65) by mail.mastercabo.com.br with SMTP; 27 Apr 2009 16:21:38 -0000 Message-ID: <49F5DB12.7080502@yan.com.br> Date: Mon, 27 Apr 2009 13:19:30 -0300 From: =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?= User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ian Smith References: <49F06985.1000303@yan.com.br> <49F08071.1070905@ibctech.ca> <49F1D992.9000001@yan.com.br> <20090425024635.O89549@sola.nimnet.asn.au> In-Reply-To: <20090425024635.O89549@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw@freebsd.org, Steve Bertrand , freebsd-net@freebsd.org Subject: Re: IPFW MAX RULES COUNT PERFORMANCE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ddg@yan.com.br List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 16:21:41 -0000 What may be happening ? I'm with polling enabled on all interfaces, can you influence ? em0: port 0x7000-0x703f mem 0xdfa00000-0xdfa1ffff irq 16 at device 8.0 on pci4 em1: port 0x7400-0x743f mem 0xdfa20000-0xdfa3ffff irq 17 at device 8.1 on pci4 em2: port 0x8000-0x803f mem 0xdfb00000-0xdfb1ffff irq 16 at device 8.0 on pci5 em3: port 0x8400-0x843f mem 0xdfb20000-0xdfb3ffff irq 17 at device 8.1 on pci5 em4: port 0x9000-0x903f mem 0xdfc00000-0xdfc1ffff irq 16 at device 8.0 on pci7 em5: port 0x9400-0x943f mem 0xdfc20000-0xdfc3ffff irq 17 at device 8.1 on pci7 em6: port 0xa000-0xa03f mem 0xdfd00000-0xdfd1ffff irq 16 at device 8.0 on pci8 em7: port 0xa400-0xa43f mem 0xdfd20000-0xdfd3ffff irq 17 at device 8.1 on pci8 fxp0: port 0xb000-0xb03f mem 0xdfe20000-0xdfe20fff,0xdfe00000-0xdfe1ffff irq 16 at device 4.0 on pci14 If I disable the polling, no network interface work, begins to display "em4 watchdog timeout". Ian Smith escreveu: > On Fri, 24 Apr 2009, Daniel Dias Gonçalves wrote: > > > The latency in the interface em6 increased an average of 10ms to 200 ~ 300ms > > Hardware: > > CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3200.13-MHz 686-class CPU) > > Logical CPUs per core: 2 > > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > > cpu0: on acpi0 > > p4tcc0: on cpu0 > > cpu1: on acpi0 > > p4tcc1: on cpu1 > > cpu2: on acpi0 > > p4tcc2: on cpu2 > > cpu3: on acpi0 > > p4tcc3: on cpu3 > > SMP: AP CPU #1 Launched! > > SMP: AP CPU #3 Launched! > > SMP: AP CPU #2 Launched! > > > > real memory = 9663676416 (9216 MB) > > avail memory = 8396738560 (8007 MB) > > In that case, there really is something else wrong. By my measurements, > rummaging through most of >1000 rules on a old 166MHz Pentium to get to > the icmp allow rules (ridiculous, I know) added about 2ms to local net > pings via that box, ie 1ms each pass for about 900 rules, mostly counts. > > cheers, Ian From owner-freebsd-net@FreeBSD.ORG Mon Apr 27 16:24:22 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 808F4106566B for ; Mon, 27 Apr 2009 16:24:22 +0000 (UTC) (envelope-from ddg@yan.com.br) Received: from mail.mastercabo.com.br (mail.mastercabo.com.br [189.91.0.40]) by mx1.freebsd.org (Postfix) with SMTP id D39638FC15 for ; Mon, 27 Apr 2009 16:24:21 +0000 (UTC) (envelope-from ddg@yan.com.br) Received: (qmail 93547 invoked by uid 1008); 27 Apr 2009 16:24:19 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-unknown (2008-06-10) on srvmail3 X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.8 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.5-unknown Received: from unknown (HELO ?192.168.0.169?) (daniel@dgnetwork.com.br@189.91.0.65) by mail.mastercabo.com.br with SMTP; 27 Apr 2009 16:24:19 -0000 Message-ID: <49F5DBB3.6030500@yan.com.br> Date: Mon, 27 Apr 2009 13:22:11 -0300 From: =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?= User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Adrian Chadd References: <49F06985.1000303@yan.com.br> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Re: IPFW MAX RULES COUNT PERFORMANCE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ddg@yan.com.br List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 16:24:22 -0000 Going to another example. If I wanted that each authentication (username and password) in captive portal, set up rules limiting the speed of the user's IP, as I do? I can create two rules for the in / out for each user associated with a pipe? When simulating this with a script adding hundreds of rules, the latency also increases, as resolve this ? Adrian Chadd escreveu: > You'd almost certainly be better off hacking up an extension to ipfw > which lets you count a /24 in one rule. > > As in, the count rule would match on the subnet/netmask, have 256 32 > (or 64 bit) integers allocated to record traffic in, and then do an > O(1) operation using the last octet of the v4 address to map it into > this 256 slot array to update counters for. > > It'd require a little tool hackery to extend ipfw in userland/kernel > space to do it but it would work and be (very almost) just as fast as > a single rule. > > 2c, > > > > Adrian > > 2009/4/23 Daniel Dias Gonçalves : > >> Hi, >> >> My system is a FreeBSD 7.1R. >> When I add rules IPFW COUNT to 254 IPS from my network, one of my interfaces >> increases the latency, causing large delays in the network, when I delete >> COUNT rules, everything returns to normal, which can be ? >> >> My script: >> >> ipcount.php >> -- CUT -- >> > $c=0; >> $a=50100; >> for($x=0;$x<=0;$x++) { >> for($y=1;$y<=254;$y++) { >> $ip = "192.168.$x.$y"; >> system("/sbin/ipfw -q add $a count { tcp or udp } from any to >> $ip/32"); >> system("/sbin/ipfw -q add $a count { tcp or udp } from $ip/32 >> to any"); >> #system("/sbin/ipfw delete $a"); >> $c++; >> $a++; >> } >> } >> echo "\n\nTotal: $c\n"; >> ?> >> -- CUT -- >> >> net.inet.ip.fw.dyn_keepalive: 1 >> net.inet.ip.fw.dyn_short_lifetime: 5 >> net.inet.ip.fw.dyn_udp_lifetime: 10 >> net.inet.ip.fw.dyn_rst_lifetime: 1 >> net.inet.ip.fw.dyn_fin_lifetime: 1 >> net.inet.ip.fw.dyn_syn_lifetime: 20 >> net.inet.ip.fw.dyn_ack_lifetime: 300 >> net.inet.ip.fw.static_count: 262 >> net.inet.ip.fw.dyn_max: 10000 >> net.inet.ip.fw.dyn_count: 0 >> net.inet.ip.fw.curr_dyn_buckets: 256 >> net.inet.ip.fw.dyn_buckets: 10000 >> net.inet.ip.fw.default_rule: 65535 >> net.inet.ip.fw.verbose_limit: 0 >> net.inet.ip.fw.verbose: 1 >> net.inet.ip.fw.debug: 0 >> net.inet.ip.fw.one_pass: 1 >> net.inet.ip.fw.autoinc_step: 100 >> net.inet.ip.fw.enable: 1 >> net.link.ether.ipfw: 1 >> net.link.bridge.ipfw: 0 >> net.link.bridge.ipfw_arp: 0 >> >> Thanks, >> >> Daniel >> _______________________________________________ >> 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" >> >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > From owner-freebsd-net@FreeBSD.ORG Mon Apr 27 19:14:58 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D7FF106566C; Mon, 27 Apr 2009 19:14:58 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id EF23F8FC27; Mon, 27 Apr 2009 19:14:57 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: by qw-out-2122.google.com with SMTP id 3so84094qwe.7 for ; Mon, 27 Apr 2009 12:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=j3ywqWfUAUG4hl5N/nREF24xMAoy9dZlJ0LjJrUpE+w=; b=RpHsK4bkE2tIrpEFBTmse2VqRlNkWolIKqpO6tb/yFlC18MlK/OaohyhRxi4lj1jRa oFEQ6KexVZIJdaY6anjx57/bC9jIsvGs048h2WVGAayG9v9Xbw2hPH14F5x/xJA7uNh3 1Jrst32leMVMcDE0wnUbJjK27OQ61/Nbnd7K0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XvDh8WusT26jAkbR0cRejWrp4LiUw+BFDuzuR7mVzRBtUpfhTPG7tbuGy/YgIJOLKJ 0dCpoiss0YFSSBIYQiBjgTuk/A2BUHeu37NvyWfZRqFvuCt2Na3YP9ijHGaORNXRF2t/ 42p1x6ByTi5xbngd11F1tw41CC8Irb+Yn5UHs= MIME-Version: 1.0 Received: by 10.220.77.18 with SMTP id e18mr11083941vck.85.1240859697214; Mon, 27 Apr 2009 12:14:57 -0700 (PDT) In-Reply-To: <20090427190854.GA36459@lath.rinet.ru> References: <20090426215740.GA33188@onelab2.iet.unipi.it> <20090426224729.GA34800@onelab2.iet.unipi.it> <20090427140309.GA62749@onelab2.iet.unipi.it> <20090427190854.GA36459@lath.rinet.ru> Date: Mon, 27 Apr 2009 22:14:57 +0300 Message-ID: From: Maxim Ignatenko To: Oleg Bulyzhin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Luigi Rizzo Subject: Re: [dummynet] Several queues connected to one pipe: "dummynet: OUCH! pipe should have been idle!" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 19:14:58 -0000 2009/4/27 Oleg Bulyzhin : > > Perhaps you stepped on this: > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=879027+0+archive/2009/svn-src-all/20090419.svn-src-all > > You can try to change type of dn_pipe.numbytes to int64_t (instead of dn_key). > (ip_dummynet.h:341) > This is exactly what is done by patch sent by Luigi to me. And yes, it helped. Thanks. From owner-freebsd-net@FreeBSD.ORG Mon Apr 27 19:23:21 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA6AC10656CD; Mon, 27 Apr 2009 19:23:21 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id 9FE168FC08; Mon, 27 Apr 2009 19:23:21 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: by lath.rinet.ru (Postfix, from userid 222) id D2F71704C; Mon, 27 Apr 2009 23:08:54 +0400 (MSD) Date: Mon, 27 Apr 2009 23:08:54 +0400 From: Oleg Bulyzhin To: Maxim Ignatenko Message-ID: <20090427190854.GA36459@lath.rinet.ru> References: <20090426215740.GA33188@onelab2.iet.unipi.it> <20090426224729.GA34800@onelab2.iet.unipi.it> <20090427140309.GA62749@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Luigi Rizzo Subject: Re: [dummynet] Several queues connected to one pipe: "dummynet: OUCH! pipe should have been idle!" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 19:23:23 -0000 On Mon, Apr 27, 2009 at 05:44:22PM +0300, Maxim Ignatenko wrote: > 2009/4/27 Luigi Rizzo : > > On Mon, Apr 27, 2009 at 04:51:18PM +0300, Maxim Ignatenko wrote: > >> 2009/4/27 Luigi Rizzo : > >> > > >> > ok there seems to be no change related to dummynet between these > >> > two versions so I am not sure where to look. > >> > Could you double check what is the last working version ? > >> > > >> šYes, r191201 have this problems too (it seems, i didn't updated for a > >> long time). > >> Now šI updated to r190864 (just before last change on ip_dummynet.c) - > >> all works fine. Should I now check r190865? > > > > yes it would be great if you could identify a specific change that > > caused the problem. > > There is one thing particularly tricky in one of the dummynet > > changes, because some fields changed between 32/64 bits and > > signed/unsigned. I may have unadvertently introduced some > > conversion bug. > > > > On r190865 problem appeared again. > > > thanks a lot for the feedback > > > > You welcome :) > > Thanks. > _______________________________________________ > 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" Perhaps you stepped on this: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=879027+0+archive/2009/svn-src-all/20090419.svn-src-all You can try to change type of dn_pipe.numbytes to int64_t (instead of dn_key). (ip_dummynet.h:341) -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ From owner-freebsd-net@FreeBSD.ORG Mon Apr 27 21:29:51 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D3FE1065672; Mon, 27 Apr 2009 21:29:51 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 288F78FC21; Mon, 27 Apr 2009 21:29:51 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 8E36F73098; Mon, 27 Apr 2009 23:35:00 +0200 (CEST) Date: Mon, 27 Apr 2009 23:35:00 +0200 From: Luigi Rizzo To: Oleg Bulyzhin Message-ID: <20090427213500.GA77622@onelab2.iet.unipi.it> References: <20090426215740.GA33188@onelab2.iet.unipi.it> <20090426224729.GA34800@onelab2.iet.unipi.it> <20090427140309.GA62749@onelab2.iet.unipi.it> <20090427190854.GA36459@lath.rinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090427190854.GA36459@lath.rinet.ru> User-Agent: Mutt/1.4.2.3i Cc: Maxim Ignatenko , freebsd-current@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: [dummynet] Several queues connected to one pipe: "dummynet: OUCH! pipe should have been idle!" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 21:29:51 -0000 On Mon, Apr 27, 2009 at 11:08:54PM +0400, Oleg Bulyzhin wrote: > On Mon, Apr 27, 2009 at 05:44:22PM +0300, Maxim Ignatenko wrote: ... > > > yes it would be great if you could identify a specific change that > > > caused the problem. > > > There is one thing particularly tricky in one of the dummynet > > > changes, because some fields changed between 32/64 bits and > > > signed/unsigned. I may have unadvertently introduced some > > > conversion bug. > > > > > > > On r190865 problem appeared again. > > > > > thanks a lot for the feedback > > > > > > > You welcome :) > > > > Thanks. > > _______________________________________________ > > 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" > > Perhaps you stepped on this: > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=879027+0+archive/2009/svn-src-all/20090419.svn-src-all > > You can try to change type of dn_pipe.numbytes to int64_t (instead of dn_key). > (ip_dummynet.h:341) good catch Oleg, sorry if i missed your email above. cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Apr 28 03:40:49 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 433161065670; Tue, 28 Apr 2009 03:40:49 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qy0-f105.google.com (mail-qy0-f105.google.com [209.85.221.105]) by mx1.freebsd.org (Postfix) with ESMTP id D62F68FC19; Tue, 28 Apr 2009 03:40:48 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by qyk3 with SMTP id 3so723256qyk.3 for ; Mon, 27 Apr 2009 20:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=U1Taw6rg38DV4UiX+yKbevTRWu+NTeKOJ4UOE4M5Qzw=; b=QkaDm6qR6puuaxymm+Emgedr7DuxD+twrtxpDP9oOkfWWuHjMY3HeEhp3s0Mxif9JK l6dmnXkWWitAlO11wCuCmF56nJYW4MUytDR9GHhnCwUh1mBvKEDpbHIPncpuw6rZv9ww anCdhuOkfTmpJwhEiSfH0bFs0a0xzNVF+sQlA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=RKGve2mLzD2KFK13vx7y6GtkF3+pAdQWFz4LXxJ4Uo2kFRhMrrCSEnFx/Ir6nB7quJ 6hYxxNdxQt3DWAcgKthHgapkwUD5y4EHkSSCa7ttnDACWZjZSd1RBd4BoarXpCtpAbHl /A33g9Ql7dZwpQA9eA2CyWasJMXCXEra1/jlM= MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.229.96.1 with SMTP id f1mr3346976qcn.103.1240890048184; Mon, 27 Apr 2009 20:40:48 -0700 (PDT) In-Reply-To: <49F5DBB3.6030500@yan.com.br> References: <49F06985.1000303@yan.com.br> <49F5DBB3.6030500@yan.com.br> Date: Tue, 28 Apr 2009 11:40:48 +0800 X-Google-Sender-Auth: 125868ae51dbce0c Message-ID: From: Adrian Chadd To: ddg@yan.com.br Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Re: IPFW MAX RULES COUNT PERFORMANCE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 03:40:49 -0000 You may want to investigate using pf; i'm not sure whether they handle this better. Me, I'd investigate writing a "tree" ipfw rule type. Ie, instead of having a list of rules, all evaluated one at a time, I'd create a rule implementing a subrule match on ip/netmask with some kind of action (allow, deny, count, pipe, etc) rather than having it all be evaluated O(n) style. 2c, Adrian 2009/4/28 Daniel Dias Gon=E7alves : > Going to another example. > If I wanted that each authentication (username and password) in captive > portal, set up rules limiting the speed of the user's IP, as I do? I can > create two rules for the in / out for each user associated with a pipe? W= hen > simulating this with a script adding hundreds of rules, the latency also > increases, as resolve this ? > > Adrian Chadd escreveu: >> >> You'd almost certainly be better off hacking up an extension to ipfw >> which lets you count a /24 in one rule. >> >> As in, the count rule would match on the subnet/netmask, have 256 32 >> (or 64 bit) integers allocated to record traffic in, and then do an >> O(1) operation using the last octet of the v4 address to map it into >> this 256 slot array to update counters for. >> >> It'd require a little tool hackery to extend ipfw in userland/kernel >> space to do it but it would work and be (very almost) just as fast as >> a single rule. >> >> 2c, >> >> >> >> Adrian >> >> 2009/4/23 Daniel Dias Gon=E7alves : >> >>> >>> Hi, >>> >>> My system is a FreeBSD 7.1R. >>> When I add rules IPFW COUNT to 254 IPS from my network, one of my >>> interfaces >>> increases the latency, causing large delays in the network, when I dele= te >>> COUNT rules, everything returns to normal, which can be ? >>> >>> My script: >>> >>> ipcount.php >>> -- CUT -- >>> >> $c=3D0; >>> $a=3D50100; >>> for($x=3D0;$x<=3D0;$x++) { >>> =A0 =A0 =A0for($y=3D1;$y<=3D254;$y++) { >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0$ip =3D "192.168.$x.$y"; >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0system("/sbin/ipfw -q add $a count { tcp or = udp } from any >>> to >>> $ip/32"); >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0system("/sbin/ipfw -q add $a count { tcp or = udp } from >>> $ip/32 >>> to any"); >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0#system("/sbin/ipfw delete $a"); >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0$c++; >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0$a++; >>> =A0 =A0 =A0} >>> } >>> echo "\n\nTotal: $c\n"; >>> ?> >>> -- CUT -- >>> >>> net.inet.ip.fw.dyn_keepalive: 1 >>> net.inet.ip.fw.dyn_short_lifetime: 5 >>> net.inet.ip.fw.dyn_udp_lifetime: 10 >>> net.inet.ip.fw.dyn_rst_lifetime: 1 >>> net.inet.ip.fw.dyn_fin_lifetime: 1 >>> net.inet.ip.fw.dyn_syn_lifetime: 20 >>> net.inet.ip.fw.dyn_ack_lifetime: 300 >>> net.inet.ip.fw.static_count: 262 >>> net.inet.ip.fw.dyn_max: 10000 >>> net.inet.ip.fw.dyn_count: 0 >>> net.inet.ip.fw.curr_dyn_buckets: 256 >>> net.inet.ip.fw.dyn_buckets: 10000 >>> net.inet.ip.fw.default_rule: 65535 >>> net.inet.ip.fw.verbose_limit: 0 >>> net.inet.ip.fw.verbose: 1 >>> net.inet.ip.fw.debug: 0 >>> net.inet.ip.fw.one_pass: 1 >>> net.inet.ip.fw.autoinc_step: 100 >>> net.inet.ip.fw.enable: 1 >>> net.link.ether.ipfw: 1 >>> net.link.bridge.ipfw: 0 >>> net.link.bridge.ipfw_arp: 0 >>> >>> Thanks, >>> >>> Daniel >>> _______________________________________________ >>> 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" >>> >>> >> >> _______________________________________________ >> 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" >> >> >> > > _______________________________________________ > 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 Apr 28 04:52:32 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81D44106566B for ; Tue, 28 Apr 2009 04:52:32 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id C1D2A8FC16 for ; Tue, 28 Apr 2009 04:52:30 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id n3S4XaSZ022453; Tue, 28 Apr 2009 14:33:38 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 28 Apr 2009 14:33:36 +1000 (EST) From: Ian Smith To: =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?= In-Reply-To: <49F5DB12.7080502@yan.com.br> Message-ID: <20090428135053.Y89549@sola.nimnet.asn.au> References: <49F06985.1000303@yan.com.br> <49F08071.1070905@ibctech.ca> <49F1D992.9000001@yan.com.br> <20090425024635.O89549@sola.nimnet.asn.au> <49F5DB12.7080502@yan.com.br> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1620027708-1240893216=:89549" Cc: freebsd-ipfw@freebsd.org, Steve Bertrand , freebsd-net@freebsd.org Subject: Re: IPFW MAX RULES COUNT PERFORMANCE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 04:52:32 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1620027708-1240893216=:89549 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Mon, 27 Apr 2009, Daniel Dias Gonçalves wrote: > What may be happening ? I'm with polling enabled on all interfaces, can you > influence ? > > em0: port 0x7000-0x703f mem > 0xdfa00000-0xdfa1ffff irq 16 at device 8.0 on pci4 > em1: port 0x7400-0x743f mem > 0xdfa20000-0xdfa3ffff irq 17 at device 8.1 on pci4 > em2: port 0x8000-0x803f mem > 0xdfb00000-0xdfb1ffff irq 16 at device 8.0 on pci5 > em3: port 0x8400-0x843f mem > 0xdfb20000-0xdfb3ffff irq 17 at device 8.1 on pci5 > em4: port 0x9000-0x903f mem > 0xdfc00000-0xdfc1ffff irq 16 at device 8.0 on pci7 > em5: port 0x9400-0x943f mem > 0xdfc20000-0xdfc3ffff irq 17 at device 8.1 on pci7 > em6: port 0xa000-0xa03f mem > 0xdfd00000-0xdfd1ffff irq 16 at device 8.0 on pci8 > em7: port 0xa400-0xa43f mem > 0xdfd20000-0xdfd3ffff irq 17 at device 8.1 on pci8 > fxp0: port 0xb000-0xb03f mem > 0xdfe20000-0xdfe20fff,0xdfe00000-0xdfe1ffff irq 16 at device 4.0 on pci14 > > If I disable the polling, no network interface work, begins to display "em4 > watchdog timeout". Sorry, no ideas about polling, but this doesn't smell like just an IPFW issue. I was pointing out that despite 20 times the CPU clock rate, probably at least 30 times CPU throughput and likely 10 times the tick rate, you appear to be suffering something like 30 to 900 times the increased latency to be expected by traversing 'too many' ipfw rules. > Ian Smith escreveu: > > On Fri, 24 Apr 2009, Daniel Dias Gonçalves wrote: > > > > > The latency in the interface em6 increased an average of 10ms to 200 ~ > > 300ms > > > Hardware: > > > CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3200.13-MHz 686-class CPU) > > > Logical CPUs per core: 2 > > > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > > > cpu0: on acpi0 > > > p4tcc0: on cpu0 > > > cpu1: on acpi0 > > > p4tcc1: on cpu1 > > > cpu2: on acpi0 > > > p4tcc2: on cpu2 > > > cpu3: on acpi0 > > > p4tcc3: on cpu3 > > > SMP: AP CPU #1 Launched! > > > SMP: AP CPU #3 Launched! > > > SMP: AP CPU #2 Launched! > > > > real memory = 9663676416 (9216 MB) > > > avail memory = 8396738560 (8007 MB) > > > > In that case, there really is something else wrong. By my measurements, > > rummaging through most of >1000 rules on a old 166MHz Pentium to get to the > > icmp allow rules (ridiculous, I know) added about 2ms to local net pings > > via that box, ie 1ms each pass for about 900 rules, mostly counts. cheers, Ian --0-1620027708-1240893216=:89549-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 28 06:52:00 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE9E3106566B for ; Tue, 28 Apr 2009 06:52:00 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outP.internet-mail-service.net (outp.internet-mail-service.net [216.240.47.239]) by mx1.freebsd.org (Postfix) with ESMTP id 55AC08FC0C for ; Tue, 28 Apr 2009 06:51:59 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 6E02F14DDAD; Mon, 27 Apr 2009 23:51:59 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 62B7E2D6229; Mon, 27 Apr 2009 23:51:58 -0700 (PDT) Message-ID: <49F6A796.4060100@elischer.org> Date: Mon, 27 Apr 2009 23:52:06 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: ddg@yan.com.br References: <49F06985.1000303@yan.com.br> <49F0A7DD.30206@elischer.org> <49F1DBAE.1080205@yan.com.br> <49F235F4.2030202@elischer.org> <49F5D8A3.3050805@yan.com.br> In-Reply-To: <49F5D8A3.3050805@yan.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Re: IPFW MAX RULES COUNT PERFORMANCE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 06:52:01 -0000 Daniel Dias Gonçalves wrote: > Julian, > > You could give an example of rules with tables? I'm sorry I forgot that you want to count packets from each client. tables won't work for that. for counting I suggest the technique I show below, but for just allowing, you can add allowable addresses to a table, e.g. table 1 add 1.2.3.4 and test it with allow ip from table (1) to any > > Julian Elischer escreveu: >> Daniel Dias Gonçalves wrote: >>> Very good thinking, congratulations, but my need is another. >>> The objective is a Captive Porrtal that each authentication is >>> dynamically created a rule to ALLOW or COUNT IP authenticated, which >>> I'm testing is what is the maximum capacity of rules supported, >>> therefore simultaneous user. >>> >>> Understand ? >>> >> I think so. >> >> >> do not add rules. >> have a single rule that looks in a table >> and add entries to the table when needed. >> >>> Thanks, >>> >>> Daniel >>> >>> Julian Elischer escreveu: >>>> Daniel Dias Gonçalves wrote: >>>>> Hi, >>>>> >>>>> My system is a FreeBSD 7.1R. >>>>> When I add rules IPFW COUNT to 254 IPS from my network, one of my >>>>> interfaces increases the latency, causing large delays in the >>>>> network, when I delete COUNT rules, everything returns to normal, >>>>> which can be ? >>>>> >>>>> My script: >>>> >>>> of course adding 512 rules, *all of which hav eto be evaluated* will >>>> add latency. >>>> >>>> you have several ways to improve this situation. >>>> >>>> 1/ use a differnet tool. >>>> By using the netgraph netflow module you can get >>>> accunting information that may be more useful and less impactful. >>>> >>>> 2/ you could make your rules smarter.. >>>> >>>> use skipto rules to make the average packet traverse less rules.. >>>> >>>> off the top of my head.. (not tested..) >>>> >>>> Assuming you have machines 10.0.0.1-10.0.0.254.... >>>> the rules below have an average packet traversing 19 rules and not >>>> 256 for teh SYN packet and 2 rules for others.. >>>> you may not be able to do the keep state trick if you use state for >>>> other stuff but in that case worst case will still be 19 rules. >>>> >>>> 2 check-state >>>> 5 skipto 10000 ip from not 10.0.0.0/24 to any >>>> 10 skipto 2020 ip from not 10.0.0.0/25 to any # 0-128 >>>> 20 skipto 1030 ip from not 10.0.0.0/26 to any # 0-64 >>>> 30 skipto 240 ip from not 10.0.0.0/27 to any # 0-32 >>>> 40 skipto 100 ip from not 10.0.0.0/28 to any # 0-16 >>>> [16 count rules for 0-15] >>>> 80 skipto 10000 ip from any to any >>>> 100 [16 count rules for 16-31] keep-state >>>> 140 skipto 10000 ip from any to any >>>> 240 skipto 300 ip from not 10.0.0.32/28 >>>> [16 rules for 32-47] keep-state >>>> 280 skipto 10000 ip from any to any >>>> 300 [16 count rules for 48-63] keep-state >>>> 340 skipto 10000 ip from any to any >>>> 1030 skipto 1240 ip from not 10.0.0.64/27 to any >>>> 1040 skipto 1100 ip from not 10.0.0.64/28 to any >>>> [16 count rules for 64-79] keep-state >>>> 1080 skipto 10000 ip from any to any >>>> 1100 [16 rules for 80-95] keep-state >>>> 1140 skipto 10000 ip from any to any >>>> 1240 skipto 1300 ip from not 10.0.0.96/28 to any >>>> [16 count rules for 96-111] keep-state >>>> 1280 skipto 10000 ip from any to any >>>> 1300 [16 rules for 112-127] keep-state >>>> 1340 skipto 10000 ip from any to any >>>> 2020 skipto 3030 ip from not 10.0.0.128/26 to any >>>> 2030 skipto 2240 ip from not 10.0.0.128/28 to any >>>> [16 count rules for 128-143] keep-state >>>> 2080 skipto 10000 ip from any to any >>>> 2100 [16 rules for 144-159] keep-state >>>> 2140 skipto 10000 ip from any to any >>>> 2240 skipto 2300 ip from not 10.0.0.32/28 to any >>>> [16 count rules for 160-175] keep-state >>>> 2280 skipto 10000 ip from any to any >>>> 2300 [16 count rules for 176-191] keep-state >>>> 2340 skipto 10000 ip from any to any >>>> 3030 skipto 3240 ip from not 10.0.0.192/27 to any >>>> 3040 skipto 3100 ip from not 10.0.0.192/28 to any >>>> [16 count rules for 192-207] keep-state >>>> 3080 skipto 10000 ip from any to any >>>> 3100 [16 rules for 208-223] keep-state >>>> 3240 skipto 10000 ip from any to any >>>> 3240 skipto 3300 ip from not 10.0.0.224/28 to any >>>> [16 count rules for 224-239] keep-state >>>> 3280 skipto 10000 ip from any to any >>>> 3300 [16 count rules for 240-255] keep-state >>>> 3340 skipto 10000 ip from any to any >>>> >>>> 10000 #other stuff >>>> >>>> in fact you could improve it further with: >>>> 1/ either going down to a netmask of 29 (8 rules per set) >>>> or >>>> 2/ instead of having count rules make them skipto >>>> so you would have: >>>> 3300 skipto 10000 ip from 10.0.0.240 to any >>>> 3301 skipto 10000 ip from 10.0.0.241 to any >>>> 3302 skipto 10000 ip from 10.0.0.242 to any >>>> 3303 skipto 10000 ip from 10.0.0.243 to any >>>> 3304 skipto 10000 ip from 10.0.0.244 to any >>>> 3305 skipto 10000 ip from 10.0.0.245 to any >>>> 3306 skipto 10000 ip from 10.0.0.246 to any >>>> 3307 skipto 10000 ip from 10.0.0.247 to any >>>> 3308 skipto 10000 ip from 10.0.0.248 to any >>>> 3309 skipto 10000 ip from 10.0.0.249 to any >>>> 3310 skipto 10000 ip from 10.0.0.240 to any >>>> 3311 skipto 10000 ip from 10.0.0.241 to any >>>> 3312 skipto 10000 ip from 10.0.0.242 to any >>>> 3313 skipto 10000 ip from 10.0.0.243 to any >>>> 3314 skipto 10000 ip from 10.0.0.244 to any >>>> 3315 skipto 10000 ip from 10.0.0.245 to any >>>> >>>> thus on average, a packet would traverse half the rules (8). >>>> >>>> 3/ both the above so on average they would traverse 4 rules plus >>>> one extra skipto. >>>> >>>> you should be able to do the above in a script. >>>> I'd love to see it.. >>>> >>>> (you can also do skipto tablearg in -current (maybe 7.2 too) >>>> which may also be good.. (or not)) >>>> >>>> >>>> julian >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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" >>>> >>>> >> >> _______________________________________________ >> 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 Apr 28 08:40:52 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71130106566C; Tue, 28 Apr 2009 08:40:52 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from netasq.netasq.com (netasq.netasq.com [213.30.137.178]) by mx1.freebsd.org (Postfix) with ESMTP id C58998FC16; Tue, 28 Apr 2009 08:40:51 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from [10.2.1.5] (unknown [10.0.0.126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by netasq.netasq.com (Postfix) with ESMTP id B35B31CD08; Tue, 28 Apr 2009 10:10:01 +0200 (CEST) Message-Id: From: Fabien Thomas To: barney_cordoba@yahoo.com In-Reply-To: <160513.83122.qm@web63904.mail.re1.yahoo.com> Content-Type: multipart/signed; boundary=Apple-Mail-148-605993175; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 28 Apr 2009 10:09:57 +0200 References: <160513.83122.qm@web63904.mail.re1.yahoo.com> X-Mailer: Apple Mail (2.930.3) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Ed Maste Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fabient@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 08:40:52 -0000 --Apple-Mail-148-605993175 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit To share my results: I have done at work modification to the polling code to do SMP polling (previously posted to this ml). SMP polling (dynamic group of interface binded to CPU) does not significantly improve the throughput (lock contention seems to be the cause here). The main advantage of polling with modern interface is not the PPS (which is nearly the same) but the global efficiency of the system when using multiple interfaces (which is the case for Firewall). The best configuration we have found with FreeBSD 6.3 is to do polling on one CPU and keep the other CPU free for other processing. In this configuration the whole system is more efficient than with interrupt where all the CPU are busy processing interrupt thread. Regards, Fabien --Apple-Mail-148-605993175-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 28 09:27:07 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4C2910656FD for ; Tue, 28 Apr 2009 09:27:07 +0000 (UTC) (envelope-from p.pisati@oltrelinux.com) Received: from contactlab34-bk-3.contactlab.it (contactlab34-bk-3.contactlab.it [93.94.34.3]) by mx1.freebsd.org (Postfix) with ESMTP id 531318FC0A for ; Tue, 28 Apr 2009 09:27:07 +0000 (UTC) (envelope-from p.pisati@oltrelinux.com) DKIM-Signature: v=1; a=rsa-sha1; d=contactlab.it; s=s768; c=simple/simple; q=dns/txt; i=@contactlab.it; t=1240909531; h=From:Subject:Date:To:MIME-Version:Content-Type; bh=xVEzPb+kpUNrN2JRWbK9JOJ7Ydg=; b=CFE1cObEcx/w0W7Snr8L6UeMNO1yt6/VX7NrOw3r37ezB7/u0VypD9Wt0Xb4AcLv mELUDpsb5eNXc34jDLZOX5Iz/48syeAGAU6RPrATt4cOiGJfC70HlGIWIvoS2yEr; Received: from [213.92.0.53] ([213.92.0.53:62358] helo=mail0.tomato.it) by vmta3.contactlab.it (envelope-from ) (ecelerity 2.2.2.37 r(28822M)) with ESMTP id FB/4D-20286-BD6C6F94; Tue, 28 Apr 2009 11:05:31 +0200 Received: from ferret.tomato.lan (fast.tomato.it [62.101.64.91]) by mail0.tomato.it (Postfix) with ESMTP id AE2E72840C; Tue, 28 Apr 2009 11:06:41 +0200 (CEST) Message-ID: <49F6C6B4.4080108@oltrelinux.com> Date: Tue, 28 Apr 2009 11:04:52 +0200 From: Paolo Pisati User-Agent: Thunderbird 2.0.0.19 (X11/20090226) MIME-Version: 1.0 To: fabient@freebsd.org References: <160513.83122.qm@web63904.mail.re1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: barney_cordoba@yahoo.com, Ed Maste , freebsd-net@freebsd.org Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 09:27:08 -0000 Fabien Thomas wrote: > > To share my results: > > I have done at work modification to the polling code to do SMP polling > (previously posted to this ml). > > SMP polling (dynamic group of interface binded to CPU) does not > significantly improve the throughput (lock contention seems to be the > cause here). > The main advantage of polling with modern interface is not the PPS > (which is nearly the same) but the global efficiency of the system > when using multiple interfaces (which is the case for Firewall). > The best configuration we have found with FreeBSD 6.3 is to do polling > on one CPU and keep the other CPU free for other processing. In this > configuration the whole system > is more efficient than with interrupt where all the CPU are busy > processing interrupt thread. out of curiosity: did you try polling on 4.x? i know it doesn't "support" SMP over there, but last time i tried polling on 7.x (or was it 6.x? i don't remember...) i found it didn't gave any benefit, while switching the system to 4.x showed a huge improvement. -- bye, P. From owner-freebsd-net@FreeBSD.ORG Tue Apr 28 09:49:29 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A44801065679 for ; Tue, 28 Apr 2009 09:49:29 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from netasq.netasq.com (netasq.netasq.com [213.30.137.178]) by mx1.freebsd.org (Postfix) with ESMTP id 1F2B08FC1C for ; Tue, 28 Apr 2009 09:49:28 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from [10.2.1.5] (unknown [10.0.0.126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by netasq.netasq.com (Postfix) with ESMTP id B172A722F7; Tue, 28 Apr 2009 11:49:27 +0200 (CEST) Message-Id: <36906055-E1AE-486B-BA77-D260E0609BBB@netasq.com> From: Fabien Thomas To: Paolo Pisati In-Reply-To: <49F6C6B4.4080108@oltrelinux.com> Content-Type: multipart/signed; boundary=Apple-Mail-154-611962325; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 28 Apr 2009 11:49:27 +0200 References: <160513.83122.qm@web63904.mail.re1.yahoo.com> <49F6C6B4.4080108@oltrelinux.com> X-Mailer: Apple Mail (2.930.3) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Net Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fabient@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 09:49:30 -0000 --Apple-Mail-154-611962325 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Le 28 avr. 09 =E0 11:04, Paolo Pisati a =E9crit : > Fabien Thomas wrote: >> >> To share my results: >> >> I have done at work modification to the polling code to do SMP =20 >> polling (previously posted to this ml). >> >> SMP polling (dynamic group of interface binded to CPU) does not =20 >> significantly improve the throughput (lock contention seems to be =20 >> the cause here). >> The main advantage of polling with modern interface is not the PPS =20= >> (which is nearly the same) but the global efficiency of the system =20= >> when using multiple interfaces (which is the case for Firewall). >> The best configuration we have found with FreeBSD 6.3 is to do =20 >> polling on one CPU and keep the other CPU free for other =20 >> processing. In this configuration the whole system >> is more efficient than with interrupt where all the CPU are busy =20 >> processing interrupt thread. > out of curiosity: did you try polling on 4.x? i know it doesn't =20 > "support" SMP over there, but last time i tried polling on 7.x (or =20 > was it 6.x? i don't remember...) > i found it didn't gave any benefit, while switching the system to =20 > 4.x showed a huge improvement. > yes rewriting the core polling code started at half because the =20 polling code on 6.x and up perform badly (in our env) regarding =20 performance. today 4.x is unbeatable regarding network perf (6.2 -> 7.0 at least, =20= i need to do more test on 7_stable and 8). the other half of the work was to explore the SMP scaling of the =20 polling code to gain what we loose with fine grained SMP kernel. > --=20 > > bye, > P. > > --Apple-Mail-154-611962325-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 28 10:28:02 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40896106567A for ; Tue, 28 Apr 2009 10:28:02 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mail.giulioferro.it (mail.giulioferro.it [85.18.102.52]) by mx1.freebsd.org (Postfix) with ESMTP id F237D8FC18 for ; Tue, 28 Apr 2009 10:28:01 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from localhost (localhost [127.0.0.1]) by mail.giulioferro.it (Postfix) with ESMTP id AFE9C33C70 for ; Tue, 28 Apr 2009 12:10:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at giulioferro.it Received: from mail.giulioferro.it ([127.0.0.1]) by localhost (aurynwork1sv1.giulioferro.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7Med2JuUyHV for ; Tue, 28 Apr 2009 12:10:29 +0200 (CEST) Received: from aurynmob2.giulioferro.it (localhost [127.0.0.1]) (Authenticated sender: gferro@giulioferro.it) by mail.giulioferro.it (Postfix) with ESMTP id 0023033C0E for ; Tue, 28 Apr 2009 12:10:28 +0200 (CEST) Message-ID: <49F6D598.6040503@zirakzigil.org> Date: Tue, 28 Apr 2009 12:08:24 +0200 From: Giulio Ferro User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: IPSEC NAT traversal X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 10:28:02 -0000 What's the status of NATT patch in 8 current? Is it usable? Thanks. From owner-freebsd-net@FreeBSD.ORG Tue Apr 28 12:00:13 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32D481065677 for ; Tue, 28 Apr 2009 12:00:13 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id E0D7E8FC20 for ; Tue, 28 Apr 2009 12:00:11 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id 16DE92798BD; Tue, 28 Apr 2009 14:00:11 +0200 (CEST) Received: by astro.zen.inc (Postfix, from userid 1000) id 5EBAE1705A; Tue, 28 Apr 2009 14:07:51 +0200 (CEST) Date: Tue, 28 Apr 2009 14:07:51 +0200 From: VANHULLEBUS Yvan To: Giulio Ferro Message-ID: <20090428120751.GA68471@zeninc.net> References: <49F6D598.6040503@zirakzigil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49F6D598.6040503@zirakzigil.org> User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-net@freebsd.org Subject: Re: IPSEC NAT traversal X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 12:00:13 -0000 On Tue, Apr 28, 2009 at 12:08:24PM +0200, Giulio Ferro wrote: > What's the status of NATT patch in 8 current? Is it usable? Hi. See recent archives, there is actually an issue with the patchset, as there are no more available bits in struct inp's flags. We're working on that to find and implement the best solution. Yvan. From owner-freebsd-net@FreeBSD.ORG Tue Apr 28 14:26:42 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 378021065672 for ; Tue, 28 Apr 2009 14:26:42 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63901.mail.re1.yahoo.com (web63901.mail.re1.yahoo.com [69.147.97.116]) by mx1.freebsd.org (Postfix) with SMTP id E42618FC19 for ; Tue, 28 Apr 2009 14:26:41 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 74719 invoked by uid 60001); 28 Apr 2009 14:26:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240928801; bh=dHIdjw0HhEpSXkucAmxqcr2IzQroe2EokFC6M+AryaA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=sRJO8z6+uTGLG/XaR11yIDfoAf6CfP02tSL/xgD01Vd7y8haG4oNQ203OI9MpcWDWL29JHCd5vTRAprkFpmAF4fng5pSFI4pw5425IZ/80m9lBVjTRQN79jiHPaWMhsS/U4OmvTKQhpN7Q4oUTlGk2G/34CLwlbTE/cUdY6HOR8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mYovNidGtTjZ8gB4o52kb/tqgSnddy0HI5KE6b/74BAuEWDdTj9zUBXxypQpBW6KWl4RJiNCVaMBGgyhPQdb/PRO6xAp/XsLyGh5FER+lTCCfSaWAiNYz/pCeSZHSs8vocs6aKBfkBLQ7+S62/Jp/7dAP6qGXhUlq4B9ZFWjvOc=; Message-ID: <50451.74235.qm@web63901.mail.re1.yahoo.com> X-YMail-OSG: TAI4whMVM1lqiU2r8oaZ5YbrdsbuHV_6vy0HU2kFfpAM06YbNPj605ElyFhqXUeJFJz_KuhY96W_ZCc2q0yTUp30Ph3R.JpOROv1Ot8QGps_kqt8OmQGkSiz_TAR5YwHI1hEoXIvB6cQGKFHBJJmk5Lqv5cmmmHmkfPXccgqdv1Q6cI.gsbcXLlI93scyQM9xYwL_lo2tfOEKUzGuDLCdps_y7URp95oqENdmVma.Cmkwz7p8VkvInvp8ubaILaBUcFlkKPvy1PCGQbBTTgEx9rItbAhj1VmRZzzrXoKBganTwAZ_oG64CMyDIO_Ssmfnk48fjvsAvCI4A-- Received: from [98.242.223.106] by web63901.mail.re1.yahoo.com via HTTP; Tue, 28 Apr 2009 07:26:40 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Tue, 28 Apr 2009 07:26:40 -0700 (PDT) From: Barney Cordoba To: Paolo Pisati , fabient@freebsd.org In-Reply-To: <36906055-E1AE-486B-BA77-D260E0609BBB@netasq.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 14:26:42 -0000 --- On Tue, 4/28/09, Fabien Thomas wrote: > From: Fabien Thomas > Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) > To: "Paolo Pisati" > Cc: "FreeBSD Net" > Date: Tuesday, April 28, 2009, 5:49 AM > Le 28 avr. 09 =E0 11:04, Paolo Pisati a =E9crit : >=20 > > Fabien Thomas wrote: > >>=20 > >> To share my results: > >>=20 > >> I have done at work modification to the polling > code to do SMP polling (previously posted to this ml). > >>=20 > >> SMP polling (dynamic group of interface binded to > CPU) does not significantly improve the throughput (lock > contention seems to be the cause here). > >> The main advantage of polling with modern > interface is not the PPS (which is nearly the same) but the > global efficiency of the system when using multiple > interfaces (which is the case for Firewall). > >> The best configuration we have found with FreeBSD > 6.3 is to do polling on one CPU and keep the other CPU free > for other processing. In this configuration the whole system > >> is more efficient than with interrupt where all > the CPU are busy processing interrupt thread. > > out of curiosity: did you try polling on 4.x? i know > it doesn't "support" SMP over there, but last > time i tried polling on 7.x (or was it 6.x? i don't > remember...) > > i found it didn't gave any benefit, while > switching the system to 4.x showed a huge improvement. > >=20 >=20 > yes rewriting the core polling code started at half because > the polling code on 6.x and up perform badly (in our env) > regarding performance. > today 4.x is unbeatable regarding network perf (6.2 -> > 7.0 at least, i need to do more test on 7_stable and 8). >=20 > the other half of the work was to explore the SMP scaling > of the polling code to gain what we loose with fine grained > SMP kernel. The problem with all of this "analysis" is that it assumes that SMP coding scales intuitively; when the opposite is actually true.=20 What you fail to address is the basic fact that moderated interrupts (ie holding off interrupts to a set number of ints/second) is exactly the same as polling, as on an active system you'll get exactly X interrupts per second at equal intervals. So all of this chatter about polling being more efficient is simply bunk. The truth is that polling requires additional overhead to the system while interrupts do not. So if polling did better for you, its simply because=20 either=20 1) The polling code in the driver is better or 2) You tuned polling better than you tuned interrupt moderation. Barney=0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Tue Apr 28 15:02:29 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DA4D106566B for ; Tue, 28 Apr 2009 15:02:29 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id E421E8FC0A for ; Tue, 28 Apr 2009 15:02:28 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 346D273098; Tue, 28 Apr 2009 17:07:39 +0200 (CEST) Date: Tue, 28 Apr 2009 17:07:39 +0200 From: Luigi Rizzo To: Barney Cordoba Message-ID: <20090428150739.GC8430@onelab2.iet.unipi.it> References: <36906055-E1AE-486B-BA77-D260E0609BBB@netasq.com> <50451.74235.qm@web63901.mail.re1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50451.74235.qm@web63901.mail.re1.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net , fabient@freebsd.org Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 15:02:29 -0000 On Tue, Apr 28, 2009 at 07:26:40AM -0700, Barney Cordoba wrote: ... > The problem with all of this "analysis" is that it assumes that SMP > coding scales intuitively; when the opposite is actually true. > > What you fail to address is the basic fact that moderated interrupts > (ie holding off interrupts to a set number of ints/second) is exactly > the same as polling, as on an active system you'll get exactly X > interrupts per second at equal intervals. So all of this chatter about > polling being more efficient is simply bunk. > > The truth is that polling requires additional overhead to the system while > interrupts do not. So if polling did better for you, its simply because > either > > 1) The polling code in the driver is better > > or > > 2) You tuned polling better than you tuned interrupt moderation. > If i am not mistaken we don't have generic support for interrupt moderation in the kernel but that's a specific NIC feature: it works if the hardware supports it, and it doesn't otherwise. Of course it would be possible to modify polling to implement generic interrupt mitigation even without hardware support, so you get the best of the two worlds. cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Apr 28 15:51:11 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B8DF106566B; Tue, 28 Apr 2009 15:51:11 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from netasq.netasq.com (netasq.netasq.com [213.30.137.178]) by mx1.freebsd.org (Postfix) with ESMTP id 8E7D28FC25; Tue, 28 Apr 2009 15:51:10 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from [10.2.1.5] (unknown [10.0.0.126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by netasq.netasq.com (Postfix) with ESMTP id 2B1C92405B; Tue, 28 Apr 2009 17:51:09 +0200 (CEST) Message-Id: <3B579474-23FD-4A9F-970B-98AA17B31EC7@netasq.com> From: Fabien Thomas To: barney_cordoba@yahoo.com In-Reply-To: <50451.74235.qm@web63901.mail.re1.yahoo.com> Content-Type: multipart/signed; boundary=Apple-Mail-6-633662438; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 28 Apr 2009 17:51:07 +0200 References: <50451.74235.qm@web63901.mail.re1.yahoo.com> X-Mailer: Apple Mail (2.930.3) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Net , fabient@freebsd.org Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 15:51:11 -0000 --Apple-Mail-6-633662438 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit >>>> >>>> I have done at work modification to the polling >> code to do SMP polling (previously posted to this ml). >>>> >>>> SMP polling (dynamic group of interface binded to >> CPU) does not significantly improve the throughput (lock >> contention seems to be the cause here). >>>> The main advantage of polling with modern >> interface is not the PPS (which is nearly the same) but the >> global efficiency of the system when using multiple >> interfaces (which is the case for Firewall). >>>> The best configuration we have found with FreeBSD >> 6.3 is to do polling on one CPU and keep the other CPU free >> for other processing. In this configuration the whole system >>>> is more efficient than with interrupt where all >> the CPU are busy processing interrupt thread. >>> out of curiosity: did you try polling on 4.x? i know >> it doesn't "support" SMP over there, but last >> time i tried polling on 7.x (or was it 6.x? i don't >> remember...) >>> i found it didn't gave any benefit, while >> switching the system to 4.x showed a huge improvement. >>> >> >> yes rewriting the core polling code started at half because >> the polling code on 6.x and up perform badly (in our env) >> regarding performance. >> today 4.x is unbeatable regarding network perf (6.2 -> >> 7.0 at least, i need to do more test on 7_stable and 8). >> >> the other half of the work was to explore the SMP scaling >> of the polling code to gain what we loose with fine grained >> SMP kernel. > > The problem with all of this "analysis" is that it assumes that SMP > coding scales intuitively; when the opposite is actually true. > > What you fail to address is the basic fact that moderated interrupts > (ie holding off interrupts to a set number of ints/second) is exactly > the same as polling, as on an active system you'll get exactly X > interrupts per second at equal intervals. So all of this chatter about > polling being more efficient is simply bunk. I agree with you with one interface. When you use ten interface it is not the case. > > > The truth is that polling requires additional overhead to the system > while > interrupts do not. So if polling did better for you, its simply > because > either > > 1) The polling code in the driver is better > > or > > 2) You tuned polling better than you tuned interrupt moderation. > > > Barney > > > > _______________________________________________ > 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" > --Apple-Mail-6-633662438-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 28 16:15:38 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5A7F106564A; Tue, 28 Apr 2009 16:15:38 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from mail-bw0-f165.google.com (mail-bw0-f165.google.com [209.85.218.165]) by mx1.freebsd.org (Postfix) with ESMTP id 2C5528FC08; Tue, 28 Apr 2009 16:15:37 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by bwz9 with SMTP id 9so635849bwz.43 for ; Tue, 28 Apr 2009 09:15:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=R0r/NbQjei7lXmiP23NjN81+cEWHFlUl332/VP4Pr/k=; b=oxBo7+ASajE4LxOKJ12GAr7hMI0A8/GT7V+kdvU74PWoMJvnAnMRdlqMPc3wWcRAoA 3gcm/Qy/4p9c9kxTvP+SnPFC8opSpcMg+/dakh51C527SRrmoOfQIsl/e+giaL0EnqdW gVpzObCA1uPPztnQyUZWaHN6ZHBeAysjkBOtM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=S2muwVZuy9G0NrDSIy8PskHt2zTBD3xAjjhAoeY94YQjkVf5Qyp3VWTitDy/rHwWTs 51jbyzafn/liAVaFos2smWNn9oIRmluMQgZhugeVwmJ3+7YJlzvaPGJtQNEjWBGHDTG+ lSaGKxXJs5XTvXH+2X6QyXpGgj7sQosOlRQjY= MIME-Version: 1.0 Received: by 10.103.241.15 with SMTP id t15mr4018213mur.85.1240935336151; Tue, 28 Apr 2009 09:15:36 -0700 (PDT) In-Reply-To: <20090428120751.GA68471@zeninc.net> References: <49F6D598.6040503@zirakzigil.org> <20090428120751.GA68471@zeninc.net> From: Scott Ullrich Date: Tue, 28 Apr 2009 12:15:16 -0400 Message-ID: To: VANHULLEBUS Yvan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Giulio Ferro Subject: Re: IPSEC NAT traversal X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 16:15:39 -0000 On Tue, Apr 28, 2009 at 8:07 AM, VANHULLEBUS Yvan wrote: > See recent archives, there is actually an issue with the patchset, as > there are no more available bits in struct inp's flags. > We're working on that to find and implement the best solution. Hi, Ermal Luci recently whipped the pfSense's NATT patch into shape: http://cvs.pfsense.com/~sullrich/NATT.RELENG_8.diff I am not sure if this is how Yvan wants to solve it for the long term but it does seem to work OK for the short term until the patch is brought up to speed. Scott From owner-freebsd-net@FreeBSD.ORG Tue Apr 28 16:52:33 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF58E106564A for ; Tue, 28 Apr 2009 16:52:33 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outS.internet-mail-service.net (outs.internet-mail-service.net [216.240.47.242]) by mx1.freebsd.org (Postfix) with ESMTP id B45A48FC15 for ; Tue, 28 Apr 2009 16:52:33 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 8B0FF14E1F2; Tue, 28 Apr 2009 09:53:08 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 3EEA12D6167; Tue, 28 Apr 2009 09:52:33 -0700 (PDT) Message-ID: <49F73459.9080803@elischer.org> Date: Tue, 28 Apr 2009 09:52:41 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: fabient@freebsd.org References: <160513.83122.qm@web63904.mail.re1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: barney_cordoba@yahoo.com, Ed Maste , freebsd-net@freebsd.org Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 16:52:34 -0000 Fabien Thomas wrote: > > To share my results: > > I have done at work modification to the polling code to do SMP polling > (previously posted to this ml). > > SMP polling (dynamic group of interface binded to CPU) does not > significantly improve the throughput (lock contention seems to be the > cause here). > The main advantage of polling with modern interface is not the PPS > (which is nearly the same) but the global efficiency of the system when > using multiple interfaces (which is the case for Firewall). > The best configuration we have found with FreeBSD 6.3 is to do polling > on one CPU and keep the other CPU free for other processing. In this > configuration the whole system > is more efficient than with interrupt where all the CPU are busy > processing interrupt thread. > so it would (might) be worth while working out a framework by which this could be achieved. > Regards, > Fabien > From owner-freebsd-net@FreeBSD.ORG Tue Apr 28 17:30:09 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A362D106566C for ; Tue, 28 Apr 2009 17:30:09 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 575B98FC19 for ; Tue, 28 Apr 2009 17:30:09 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 147B341C690; Tue, 28 Apr 2009 19:30:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 7bsfH2DPna6M; Tue, 28 Apr 2009 19:30:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 9236C41C67B; Tue, 28 Apr 2009 19:30:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 26F514448E6; Tue, 28 Apr 2009 17:28:00 +0000 (UTC) Date: Tue, 28 Apr 2009 17:28:00 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Scott Ullrich In-Reply-To: Message-ID: <20090428170638.P15361@maildrop.int.zabbadoz.net> References: <49F6D598.6040503@zirakzigil.org> <20090428120751.GA68471@zeninc.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, VANHULLEBUS Yvan Subject: Re: IPSEC NAT traversal X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 17:30:09 -0000 On Tue, 28 Apr 2009, Scott Ullrich wrote: > On Tue, Apr 28, 2009 at 8:07 AM, VANHULLEBUS Yvan wrote: >> See recent archives, there is actually an issue with the patchset, as >> there are no more available bits in struct inp's flags. >> We're working on that to find and implement the best solution. > > Hi, > > Ermal Luci recently whipped the pfSense's NATT patch into shape: > http://cvs.pfsense.com/~sullrich/NATT.RELENG_8.diff > > I am not sure if this is how Yvan wants to solve it for the long term > but it does seem to work OK for the short term until the patch is > brought up to speed. Ermal is using inp_flags2 that Kip has recently added to the inpcb. The easy way to fix it for the next day. We considered that option. The long term is that we'll have an UDP control block (patch currently circulating for review and test but possibly committed the next two days). Considering the fact that the in kernel udp tunneling callback already (ab)used the pointer and that NAT-T needs to dedicated UDP flags and we've found someone already using an udpcb we decided that now was the time to add it so that we wouldn't possibly be stuck in FreeBSD 8.x. I have NAT-T on top of that. And I am currently doing the whatever you'll call it 'final pass', will send it back to Yvan once I am done with the last 2 items and last 400 lines of key.c . After that I assume someone will commit it. As I am pretty sure you'll want to test it before it goes into the tree so you'll get a copy as well; thanks for volunteering;-p It's not yet going to use the new in kernel tunnel callback and I am not yet sure if we can actually use it due to the placing of the callback, but if we can, the change will not be visible to userland. Thus we'll be able to do it any time. It will also not yet support transport mode NAT-T that I found another person needing it the other weekend while he was debugging NAT-T and I was busy with something else; but thanks to Yvan's last patch the infrastructure to support it is in place already, so that support can be added at a later point w/o breaking the kernel/userland API/ABI or anything else (I hope at this point;). /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Tue Apr 28 17:40:04 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 376491065687 for ; Tue, 28 Apr 2009 17:40:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 257918FC18 for ; Tue, 28 Apr 2009 17:40:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n3SHe350009455 for ; Tue, 28 Apr 2009 17:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n3SHe3k2009454; Tue, 28 Apr 2009 17:40:03 GMT (envelope-from gnats) Date: Tue, 28 Apr 2009 17:40:03 GMT Message-Id: <200904281740.n3SHe3k2009454@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Maxim Ignatenko Cc: Subject: Re: kern/132715: [lagg] [panic] Panic when creating vlan's on lagg interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Maxim Ignatenko List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 17:40:04 -0000 The following reply was made to PR kern/132715; it has been noted by GNATS. From: Maxim Ignatenko To: bug-followup@freebsd.org, gdef@wp.pl Cc: freebsd-current@freebsd.org Subject: Re: kern/132715: [lagg] [panic] Panic when creating vlan's on lagg interface Date: Tue, 28 Apr 2009 20:32:37 +0300 --0016363b88a65766ad0468a0d95b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit em(4), igb(4) and ixgbe(4) registers EVENTHANDLER vlan_config, but don't do any checks that this event generated by adding vlan on top of their devices. I'm don't completely sure what the right way to fix this issue, but attached patch works for me. --0016363b88a65766ad0468a0d95b Content-Type: text/plain; charset=US-ASCII; name="patch.txt" Content-Disposition: attachment; filename="patch.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fu2vk99w0 SW5kZXg6IGUxMDAwL2lmX2lnYi5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGUxMDAwL2lmX2lnYi5jCShyZXZp c2lvbiAxOTEyMDEpCisrKyBlMTAwMC9pZl9pZ2IuYwkod29ya2luZyBjb3B5KQpAQCAtNDI3NCw2 ICs0Mjc0LDggQEAKIAlzdHJ1Y3QgYWRhcHRlcgkqYWRhcHRlciA9IGlmcC0+aWZfc29mdGM7CiAJ dTMyCQljdHJsLCByY3RsLCBpbmRleCwgdmZ0YTsKIAorCWlmIChzdHJjbXAoImlnYiIsaWZwLT5p Zl9kbmFtZSkpIHJldHVybjsKKwogCWN0cmwgPSBFMTAwMF9SRUFEX1JFRygmYWRhcHRlci0+aHcs IEUxMDAwX0NUUkwpOwogCWN0cmwgfD0gRTEwMDBfQ1RSTF9WTUU7CiAJRTEwMDBfV1JJVEVfUkVH KCZhZGFwdGVyLT5odywgRTEwMDBfQ1RSTCwgY3RybCk7CkBAIC00MzA2LDYgKzQzMDgsOCBAQAog CXN0cnVjdCBhZGFwdGVyCSphZGFwdGVyID0gaWZwLT5pZl9zb2Z0YzsKIAl1MzIJCWluZGV4LCB2 ZnRhOwogCisJaWYgKHN0cmNtcCgiaWdiIixpZnAtPmlmX2RuYW1lKSkgcmV0dXJuOworCiAJLyog UmVtb3ZlIGVudHJ5IGluIHRoZSBoYXJkd2FyZSBmaWx0ZXIgdGFibGUgKi8KIAlpbmRleCA9ICgo dnRhZyA+PiA1KSAmIDB4N0YpOwogCXZmdGEgPSBFMTAwMF9SRUFEX1JFR19BUlJBWSgmYWRhcHRl ci0+aHcsIEUxMDAwX1ZGVEEsIGluZGV4KTsKSW5kZXg6IGUxMDAwL2lmX2VtLmMKPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQotLS0gZTEwMDAvaWZfZW0uYwkocmV2aXNpb24gMTkxMjAxKQorKysgZTEwMDAvaWZfZW0uYwko d29ya2luZyBjb3B5KQpAQCAtNDc3MSw2ICs0NzcxLDggQEAKIAlzdHJ1Y3QgYWRhcHRlcgkqYWRh cHRlciA9IGlmcC0+aWZfc29mdGM7CiAJdTMyCQljdHJsLCByY3RsLCBpbmRleCwgdmZ0YTsKIAor CWlmIChzdHJjbXAoImVtIixpZnAtPmlmX2RuYW1lKSkgcmV0dXJuOworCiAJY3RybCA9IEUxMDAw X1JFQURfUkVHKCZhZGFwdGVyLT5odywgRTEwMDBfQ1RSTCk7CiAJY3RybCB8PSBFMTAwMF9DVFJM X1ZNRTsKIAlFMTAwMF9XUklURV9SRUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9DVFJMLCBjdHJsKTsK QEAgLTQ4MDMsNiArNDgwNSw4IEBACiAJc3RydWN0IGFkYXB0ZXIJKmFkYXB0ZXIgPSBpZnAtPmlm X3NvZnRjOwogCXUzMgkJaW5kZXgsIHZmdGE7CiAKKwlpZiAoc3RyY21wKCJlbSIsaWZwLT5pZl9k bmFtZSkpIHJldHVybjsKKwogCS8qIFJlbW92ZSBlbnRyeSBpbiB0aGUgaGFyZHdhcmUgZmlsdGVy IHRhYmxlICovCiAJaW5kZXggPSAoKHZ0YWcgPj4gNSkgJiAweDdGKTsKIAl2ZnRhID0gRTEwMDBf UkVBRF9SRUdfQVJSQVkoJmFkYXB0ZXItPmh3LCBFMTAwMF9WRlRBLCBpbmRleCk7CkluZGV4OiBp eGdiZS9peGdiZS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGl4Z2JlL2l4Z2JlLmMJKHJldmlzaW9uIDE5MTIw MSkKKysrIGl4Z2JlL2l4Z2JlLmMJKHdvcmtpbmcgY29weSkKQEAgLTQwMzEsNiArNDAzMSw4IEBA CiAJc3RydWN0IGFkYXB0ZXIJKmFkYXB0ZXIgPSBpZnAtPmlmX3NvZnRjOwogCXUzMgkJY3RybCwg cmN0bCwgaW5kZXgsIHZmdGE7CiAKKwlpZiAoc3RyY21wKCJpeGdiZSIsaWZwLT5pZl9kbmFtZSkp IHJldHVybjsKKwogCWN0cmwgPSBJWEdCRV9SRUFEX1JFRygmYWRhcHRlci0+aHcsIElYR0JFX1ZM TkNUUkwpOwogCWN0cmwgfD0gSVhHQkVfVkxOQ1RSTF9WTUUgfCBJWEdCRV9WTE5DVFJMX1ZGRTsK IAljdHJsICY9IH5JWEdCRV9WTE5DVFJMX0NGSUVOOwpAQCAtNDA1MCw2ICs0MDUyLDggQEAKIAlz dHJ1Y3QgYWRhcHRlcgkqYWRhcHRlciA9IGlmcC0+aWZfc29mdGM7CiAJdTMyCQlpbmRleCwgdmZ0 YTsKIAorCWlmIChzdHJjbXAoIml4Z2JlIixpZnAtPmlmX2RuYW1lKSkgcmV0dXJuOworCiAJLyog UmVtb3ZlIGVudHJ5IGluIHRoZSBoYXJkd2FyZSBmaWx0ZXIgdGFibGUgKi8KIAlpeGdiZV9zZXRf dmZ0YSgmYWRhcHRlci0+aHcsIHZ0YWcsIDAsIEZBTFNFKTsKIAo= --0016363b88a65766ad0468a0d95b-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 28 17:50:03 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24ED61065670 for ; Tue, 28 Apr 2009 17:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 131108FC18 for ; Tue, 28 Apr 2009 17:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n3SHo2xt022402 for ; Tue, 28 Apr 2009 17:50:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n3SHo2pX022401; Tue, 28 Apr 2009 17:50:02 GMT (envelope-from gnats) Date: Tue, 28 Apr 2009 17:50:02 GMT Message-Id: <200904281750.n3SHo2pX022401@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Maxim Ignatenko Cc: Subject: Re: kern/132715: [lagg] [panic] Panic when creating vlan's on lagg interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Maxim Ignatenko List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 17:50:03 -0000 The following reply was made to PR kern/132715; it has been noted by GNATS. From: Maxim Ignatenko To: bug-followup@freebsd.org, gdef@wp.pl Cc: freebsd-current@freebsd.org Subject: Re: kern/132715: [lagg] [panic] Panic when creating vlan's on lagg interface Date: Tue, 28 Apr 2009 20:47:29 +0300 --0016363b7c7089f2430468a10e5a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sorry, here is patch done relatively to root of source tree. (previous was done relatively to sys/dev) --0016363b7c7089f2430468a10e5a Content-Type: text/plain; charset=US-ASCII; name="patch.txt" Content-Disposition: attachment; filename="patch.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fu2w3wuo1 SW5kZXg6IGUxMDAwL2lmX2lnYi5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGUxMDAwL2lmX2lnYi5jCShyZXZp c2lvbiAxOTEyMDEpCisrKyBlMTAwMC9pZl9pZ2IuYwkod29ya2luZyBjb3B5KQpAQCAtNDI3NCw2 ICs0Mjc0LDggQEAKIAlzdHJ1Y3QgYWRhcHRlcgkqYWRhcHRlciA9IGlmcC0+aWZfc29mdGM7CiAJ dTMyCQljdHJsLCByY3RsLCBpbmRleCwgdmZ0YTsKIAorCWlmIChzdHJjbXAoImlnYiIsaWZwLT5p Zl9kbmFtZSkpIHJldHVybjsKKwogCWN0cmwgPSBFMTAwMF9SRUFEX1JFRygmYWRhcHRlci0+aHcs IEUxMDAwX0NUUkwpOwogCWN0cmwgfD0gRTEwMDBfQ1RSTF9WTUU7CiAJRTEwMDBfV1JJVEVfUkVH KCZhZGFwdGVyLT5odywgRTEwMDBfQ1RSTCwgY3RybCk7CkBAIC00MzA2LDYgKzQzMDgsOCBAQAog CXN0cnVjdCBhZGFwdGVyCSphZGFwdGVyID0gaWZwLT5pZl9zb2Z0YzsKIAl1MzIJCWluZGV4LCB2 ZnRhOwogCisJaWYgKHN0cmNtcCgiaWdiIixpZnAtPmlmX2RuYW1lKSkgcmV0dXJuOworCiAJLyog UmVtb3ZlIGVudHJ5IGluIHRoZSBoYXJkd2FyZSBmaWx0ZXIgdGFibGUgKi8KIAlpbmRleCA9ICgo dnRhZyA+PiA1KSAmIDB4N0YpOwogCXZmdGEgPSBFMTAwMF9SRUFEX1JFR19BUlJBWSgmYWRhcHRl ci0+aHcsIEUxMDAwX1ZGVEEsIGluZGV4KTsKSW5kZXg6IGUxMDAwL2lmX2VtLmMKPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQotLS0gZTEwMDAvaWZfZW0uYwkocmV2aXNpb24gMTkxMjAxKQorKysgZTEwMDAvaWZfZW0uYwko d29ya2luZyBjb3B5KQpAQCAtNDc3MSw2ICs0NzcxLDggQEAKIAlzdHJ1Y3QgYWRhcHRlcgkqYWRh cHRlciA9IGlmcC0+aWZfc29mdGM7CiAJdTMyCQljdHJsLCByY3RsLCBpbmRleCwgdmZ0YTsKIAor CWlmIChzdHJjbXAoImVtIixpZnAtPmlmX2RuYW1lKSkgcmV0dXJuOworCiAJY3RybCA9IEUxMDAw X1JFQURfUkVHKCZhZGFwdGVyLT5odywgRTEwMDBfQ1RSTCk7CiAJY3RybCB8PSBFMTAwMF9DVFJM X1ZNRTsKIAlFMTAwMF9XUklURV9SRUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9DVFJMLCBjdHJsKTsK QEAgLTQ4MDMsNiArNDgwNSw4IEBACiAJc3RydWN0IGFkYXB0ZXIJKmFkYXB0ZXIgPSBpZnAtPmlm X3NvZnRjOwogCXUzMgkJaW5kZXgsIHZmdGE7CiAKKwlpZiAoc3RyY21wKCJlbSIsaWZwLT5pZl9k bmFtZSkpIHJldHVybjsKKwogCS8qIFJlbW92ZSBlbnRyeSBpbiB0aGUgaGFyZHdhcmUgZmlsdGVy IHRhYmxlICovCiAJaW5kZXggPSAoKHZ0YWcgPj4gNSkgJiAweDdGKTsKIAl2ZnRhID0gRTEwMDBf UkVBRF9SRUdfQVJSQVkoJmFkYXB0ZXItPmh3LCBFMTAwMF9WRlRBLCBpbmRleCk7CkluZGV4OiBp eGdiZS9peGdiZS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGl4Z2JlL2l4Z2JlLmMJKHJldmlzaW9uIDE5MTIw MSkKKysrIGl4Z2JlL2l4Z2JlLmMJKHdvcmtpbmcgY29weSkKQEAgLTQwMzEsNiArNDAzMSw4IEBA CiAJc3RydWN0IGFkYXB0ZXIJKmFkYXB0ZXIgPSBpZnAtPmlmX3NvZnRjOwogCXUzMgkJY3RybCwg cmN0bCwgaW5kZXgsIHZmdGE7CiAKKwlpZiAoc3RyY21wKCJpeGdiZSIsaWZwLT5pZl9kbmFtZSkp IHJldHVybjsKKwogCWN0cmwgPSBJWEdCRV9SRUFEX1JFRygmYWRhcHRlci0+aHcsIElYR0JFX1ZM TkNUUkwpOwogCWN0cmwgfD0gSVhHQkVfVkxOQ1RSTF9WTUUgfCBJWEdCRV9WTE5DVFJMX1ZGRTsK IAljdHJsICY9IH5JWEdCRV9WTE5DVFJMX0NGSUVOOwpAQCAtNDA1MCw2ICs0MDUyLDggQEAKIAlz dHJ1Y3QgYWRhcHRlcgkqYWRhcHRlciA9IGlmcC0+aWZfc29mdGM7CiAJdTMyCQlpbmRleCwgdmZ0 YTsKIAorCWlmIChzdHJjbXAoIml4Z2JlIixpZnAtPmlmX2RuYW1lKSkgcmV0dXJuOworCiAJLyog UmVtb3ZlIGVudHJ5IGluIHRoZSBoYXJkd2FyZSBmaWx0ZXIgdGFibGUgKi8KIAlpeGdiZV9zZXRf dmZ0YSgmYWRhcHRlci0+aHcsIHZ0YWcsIDAsIEZBTFNFKTsKIAo= --0016363b7c7089f2430468a10e5a-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 28 18:10:07 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 128CC106567D for ; Tue, 28 Apr 2009 18:10:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DD45D8FC20 for ; Tue, 28 Apr 2009 18:10:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n3SIA6XG048082 for ; Tue, 28 Apr 2009 18:10:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n3SIA6hb048081; Tue, 28 Apr 2009 18:10:06 GMT (envelope-from gnats) Date: Tue, 28 Apr 2009 18:10:06 GMT Message-Id: <200904281810.n3SIA6hb048081@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Maxim Ignatenko Cc: Subject: Re: kern/132715: [lagg] [panic] Panic when creating vlan's on lagg interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Maxim Ignatenko List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 18:10:09 -0000 The following reply was made to PR kern/132715; it has been noted by GNATS. From: Maxim Ignatenko To: bug-followup@freebsd.org, gdef@wp.pl Cc: freebsd-current@freebsd.org Subject: Re: kern/132715: [lagg] [panic] Panic when creating vlan's on lagg interface Date: Tue, 28 Apr 2009 21:05:34 +0300 GMail sent attach in very strange way, so it does not displayed correctly on website. -------------- cut here -------------- Index: sys/dev/e1000/if_em.c =================================================================== --- sys/dev/e1000/if_em.c (revision 191201) +++ sys/dev/e1000/if_em.c (working copy) @@ -4771,6 +4771,8 @@ struct adapter *adapter = ifp->if_softc; u32 ctrl, rctl, index, vfta; + if (strcmp("em",ifp->if_dname)) return; + ctrl = E1000_READ_REG(&adapter->hw, E1000_CTRL); ctrl |= E1000_CTRL_VME; E1000_WRITE_REG(&adapter->hw, E1000_CTRL, ctrl); @@ -4803,6 +4805,8 @@ struct adapter *adapter = ifp->if_softc; u32 index, vfta; + if (strcmp("em",ifp->if_dname)) return; + /* Remove entry in the hardware filter table */ index = ((vtag >> 5) & 0x7F); vfta = E1000_READ_REG_ARRAY(&adapter->hw, E1000_VFTA, index); Index: sys/dev/e1000/if_igb.c =================================================================== --- sys/dev/e1000/if_igb.c (revision 191201) +++ sys/dev/e1000/if_igb.c (working copy) @@ -4274,6 +4274,8 @@ struct adapter *adapter = ifp->if_softc; u32 ctrl, rctl, index, vfta; + if (strcmp("igb",ifp->if_dname)) return; + ctrl = E1000_READ_REG(&adapter->hw, E1000_CTRL); ctrl |= E1000_CTRL_VME; E1000_WRITE_REG(&adapter->hw, E1000_CTRL, ctrl); @@ -4306,6 +4308,8 @@ struct adapter *adapter = ifp->if_softc; u32 index, vfta; + if (strcmp("igb",ifp->if_dname)) return; + /* Remove entry in the hardware filter table */ index = ((vtag >> 5) & 0x7F); vfta = E1000_READ_REG_ARRAY(&adapter->hw, E1000_VFTA, index); Index: sys/dev/ixgbe/ixgbe.c =================================================================== --- sys/dev/ixgbe/ixgbe.c (revision 191201) +++ sys/dev/ixgbe/ixgbe.c (working copy) @@ -4031,6 +4031,8 @@ struct adapter *adapter = ifp->if_softc; u32 ctrl, rctl, index, vfta; + if (strcmp("ixgbe",ifp->if_dname)) return; + ctrl = IXGBE_READ_REG(&adapter->hw, IXGBE_VLNCTRL); ctrl |= IXGBE_VLNCTRL_VME | IXGBE_VLNCTRL_VFE; ctrl &= ~IXGBE_VLNCTRL_CFIEN; @@ -4050,6 +4052,8 @@ struct adapter *adapter = ifp->if_softc; u32 index, vfta; + if (strcmp("ixgbe",ifp->if_dname)) return; + /* Remove entry in the hardware filter table */ ixgbe_set_vfta(&adapter->hw, vtag, 0, FALSE); -------------- cut here -------------- From owner-freebsd-net@FreeBSD.ORG Tue Apr 28 18:39:59 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70B691065679; Tue, 28 Apr 2009 18:39:59 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from mail-fx0-f162.google.com (mail-fx0-f162.google.com [209.85.220.162]) by mx1.freebsd.org (Postfix) with ESMTP id CA0798FC12; Tue, 28 Apr 2009 18:39:58 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by fxm6 with SMTP id 6so726511fxm.43 for ; Tue, 28 Apr 2009 11:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=NZgm2qLEt6bGRmlKthv783jp3cxtANaaxMyUfKXHF+E=; b=wS75wp8Fuw2OYqPQc6NaT76TIpn00gPUsZXnCy2XK+DslzcsvbY7dBn7l8vLrhyADJ ZqQL9awlq0anWBU46Fc6Nhb7AodI1oO5JyxnXk5xVyk1mb2RdsYFKprhaVxGlMH/dYJn qbu1Dx3k05o35iKFi0Cl9gETRF995mU5aRoko= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=wkL9Tqq7QgP5iNIEp7s6LRxwGVwVX2CdlW10wFxMFeKwXGirecIoJ3qoSmYxj9b8kB jN0nzZDSl/ck6FzFXiRtScrybCHpd/pJWgJb5aTWXt1S2VxSPTmLT3duqL6oTzuN/t/+ il09dNYgGOyjsFvEsfxSruFzK60IEeRESpEiI= MIME-Version: 1.0 Received: by 10.103.224.2 with SMTP id b2mr4134576mur.2.1240943997351; Tue, 28 Apr 2009 11:39:57 -0700 (PDT) In-Reply-To: <20090428170638.P15361@maildrop.int.zabbadoz.net> References: <49F6D598.6040503@zirakzigil.org> <20090428120751.GA68471@zeninc.net> <20090428170638.P15361@maildrop.int.zabbadoz.net> From: Scott Ullrich Date: Tue, 28 Apr 2009 14:39:37 -0400 Message-ID: To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, VANHULLEBUS Yvan Subject: Re: IPSEC NAT traversal X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 18:39:59 -0000 On Tue, Apr 28, 2009 at 1:28 PM, Bjoern A. Zeeb wrote: > On Tue, 28 Apr 2009, Scott Ullrich wrote: [snip] > I have NAT-T on top of that. And I am currently doing the whatever > you'll call it 'final pass', will send it back to Yvan once I am done > with the last 2 items and last 400 lines of key.c . After that I > assume someone will commit it. > As I am pretty sure you'll want to test it before it goes into the > tree so you'll get a copy as well; thanks for volunteering;-p Hey that is great news. I will be ready to test the patch as soon as you are all ready. Thanks for the update Scott From owner-freebsd-net@FreeBSD.ORG Tue Apr 28 18:40:13 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AC291065672 for ; Tue, 28 Apr 2009 18:40:13 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63904.mail.re1.yahoo.com (web63904.mail.re1.yahoo.com [69.147.97.119]) by mx1.freebsd.org (Postfix) with SMTP id C8DF18FC1B for ; Tue, 28 Apr 2009 18:40:12 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 80595 invoked by uid 60001); 28 Apr 2009 18:40:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240944012; bh=Y3BMRXql6likJrhhDFSZqztYLA34kzYiC9yMXVeifYw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=xuXhW9tDq6qMlgqJ3fot89a//EDtKSA0AwYMiepEQeJ+uiupnUeBgqE327XEZ+r1mnFTB7LMSVqIiLnqw3sn9nrkNwlYtodwAnXqH6hsLRxx2d8DVo/7GDUzSBB+vASzFn5FXZl4ujNpVfKY9GOBk5OchC9FaW543Xmk3YGGdcI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=u0lIzBZJ+WBCdKWmdPtOlN0K4+fbMBi9OVmTFE8zYCs8uzWQaTiH9IxGxNYq5ff0LOzSw2ZpgKhp/nba/f4dJtpTo5phM1J6woO7NpdPzkV+bFAhbGn7BFXUNczy+fGDUJNUCdH7jpvmytk0Hadb08hNWnizyelPDgVBnJ6YxvI=; Message-ID: <230101.78323.qm@web63904.mail.re1.yahoo.com> X-YMail-OSG: QcbwtiMVM1mGCaauMTZUE96zwMPFWbvBWiB7tUs8Q2R_huHYUxdr3KAGeSJnDl_MMZySDV7FT5Cq3kOrl64yPiR7fSqCXT4Ud7TvLbNN1XkBAbvg3J6UUSwLjD.hzASLBLDEAMVMGjhAxGAiX_u4f..QMX05SC5eTbiFQo0ZHVy69dCmKqHFTUW2vWO6YHnEHS7sW4o6BD9y0W.mP6s8upKU5dF9MhTE0p5_n7IjUv2V1maO.OXc.hZw47foFxeP.euZbhy.GFwm7uP7UqGmbmxbGQAtqqnCwbrqvzREUokDEbFhDNvnrcsDiiYm2a5Z2OORjxxPUm.n5Xc3Oi4- Received: from [98.242.223.106] by web63904.mail.re1.yahoo.com via HTTP; Tue, 28 Apr 2009 11:40:12 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Tue, 28 Apr 2009 11:40:12 -0700 (PDT) From: Barney Cordoba To: Luigi Rizzo In-Reply-To: <20090428150739.GC8430@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: FreeBSD Net , fabient@freebsd.org Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 18:40:13 -0000 --- On Tue, 4/28/09, Luigi Rizzo wrote: > From: Luigi Rizzo > Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) > To: "Barney Cordoba" > Cc: "Paolo Pisati" , fabient@freebsd.org, "FreeBSD Net" > Date: Tuesday, April 28, 2009, 11:07 AM > On Tue, Apr 28, 2009 at 07:26:40AM -0700, Barney Cordoba > wrote: > ... > > The problem with all of this "analysis" is > that it assumes that SMP > > coding scales intuitively; when the opposite is > actually true. > > > > What you fail to address is the basic fact that > moderated interrupts > > (ie holding off interrupts to a set number of > ints/second) is exactly > > the same as polling, as on an active system you'll > get exactly X > > interrupts per second at equal intervals. So all of > this chatter about > > polling being more efficient is simply bunk. > > > > The truth is that polling requires additional overhead > to the system while > > interrupts do not. So if polling did better for you, > its simply because > > either > > > > 1) The polling code in the driver is better > > > > or > > > > 2) You tuned polling better than you tuned interrupt > moderation. > > > > If i am not mistaken we don't have generic support for > interrupt moderation > in the kernel but that's a specific NIC feature: it > works if the > hardware supports it, and it doesn't otherwise. Well its the silly integrator who uses whatever hardware he has lying around. You don't try to squeeze performance out of crap hardware. You get hardware that has the features you need. The point of polling was to avoid livelock. So the question is why is it still around in 7 and 8, along with the propaganda that its any better than just using a decent controller. BC From owner-freebsd-net@FreeBSD.ORG Tue Apr 28 21:25:39 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C47A106566B for ; Tue, 28 Apr 2009 21:25:39 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (email.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 3AE958FC14 for ; Tue, 28 Apr 2009 21:25:38 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id DCC9417899; Wed, 29 Apr 2009 07:10:34 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from [10.1.50.60] (ppp121-44-112-205.lns10.syd6.internode.on.net [121.44.112.205]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 7372F17178; Wed, 29 Apr 2009 07:10:30 +1000 (EST) Message-ID: <49F7709F.1020409@modulus.org> Date: Wed, 29 Apr 2009 07:09:51 +1000 From: Andrew Snow User-Agent: Thunderbird 2.0.0.14 (X11/20080523) MIME-Version: 1.0 To: Luigi Rizzo References: <36906055-E1AE-486B-BA77-D260E0609BBB@netasq.com> <50451.74235.qm@web63901.mail.re1.yahoo.com> <20090428150739.GC8430@onelab2.iet.unipi.it> In-Reply-To: <20090428150739.GC8430@onelab2.iet.unipi.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 21:25:39 -0000 Luigi Rizzo wrote: > If i am not mistaken we don't have generic support for interrupt moderation > in the kernel but that's a specific NIC feature: it works if the > hardware supports it, and it doesn't otherwise. > > Of course it would be possible to modify polling to implement > generic interrupt mitigation even without hardware support, so > you get the best of the two worlds. It seems to me that you're wasting your time if you are trying to achieve a high throughput in FreeBSD without using an Intel Pro/1000 or 10gbe networking card. So I don't know if anyone would really miss out if generic polling support was completely removed from the kernel and all efforts were then placed into improving other parts of network flow in the kernel which need more help. - Andrew From owner-freebsd-net@FreeBSD.ORG Tue Apr 28 21:26:30 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9D86106564A for ; Tue, 28 Apr 2009 21:26:30 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 7E1BE8FC0C for ; Tue, 28 Apr 2009 21:26:30 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 71D12730A4; Tue, 28 Apr 2009 23:31:41 +0200 (CEST) Date: Tue, 28 Apr 2009 23:31:41 +0200 From: Luigi Rizzo To: Andrew Snow Message-ID: <20090428213141.GC20530@onelab2.iet.unipi.it> References: <36906055-E1AE-486B-BA77-D260E0609BBB@netasq.com> <50451.74235.qm@web63901.mail.re1.yahoo.com> <20090428150739.GC8430@onelab2.iet.unipi.it> <49F7709F.1020409@modulus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49F7709F.1020409@modulus.org> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 21:26:31 -0000 On Wed, Apr 29, 2009 at 07:09:51AM +1000, Andrew Snow wrote: > Luigi Rizzo wrote: > >If i am not mistaken we don't have generic support for interrupt moderation > >in the kernel but that's a specific NIC feature: it works if the > >hardware supports it, and it doesn't otherwise. > > > >Of course it would be possible to modify polling to implement > >generic interrupt mitigation even without hardware support, so > >you get the best of the two worlds. > > It seems to me that you're wasting your time if you are trying to > achieve a high throughput in FreeBSD without using an Intel Pro/1000 or > 10gbe networking card. this is a very partial view of the world. the point is not getting a speed record but making the system work well on a wide variety of hardware. improving other parts of the network flow is nice and useful but it still does not address livelock and the problems that interrupt mitigation or polling are dealing with. cheers luigi > So I don't know if anyone would really miss out if generic polling > support was completely removed from the kernel and all efforts were then > placed into improving other parts of network flow in the kernel which > need more help. > > > - Andrew From owner-freebsd-net@FreeBSD.ORG Wed Apr 29 05:58:43 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07155106564A; Wed, 29 Apr 2009 05:58:43 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D125D8FC0C; Wed, 29 Apr 2009 05:58:42 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n3T5wgaa007168; Wed, 29 Apr 2009 05:58:42 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n3T5wgUX007164; Wed, 29 Apr 2009 05:58:42 GMT (envelope-from linimon) Date: Wed, 29 Apr 2009 05:58:42 GMT Message-Id: <200904290558.n3T5wgUX007164@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/134079: [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8.0) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 05:58:43 -0000 Old Synopsis: "em0: Invalid MAC address" in FreeBSD-Current ( 8.0) New Synopsis: [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8.0) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Apr 29 05:58:30 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=134079 From owner-freebsd-net@FreeBSD.ORG Wed Apr 29 07:13:55 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A4F6106566B for ; Wed, 29 Apr 2009 07:13:55 +0000 (UTC) (envelope-from miki.bsd@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 058B18FC13 for ; Wed, 29 Apr 2009 07:13:54 +0000 (UTC) (envelope-from miki.bsd@gmail.com) Received: by ewy19 with SMTP id 19so1005606ewy.43 for ; Wed, 29 Apr 2009 00:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=MJmTauD/4x2xxI9bT+34csgW3rTCYpAo+3cWLBK5mNc=; b=SiU/hoazOSMnWZ+mGEXh6YTcwcgDd3x2ygIWr24o2yy25m9CI/R/QL9CY2rC7xdHY2 ZyGDmKt657RmyGhsta5W9IQfWJhsbX2ozCDZJsh02wtOBP7i2KQG/hQ3bBr1XLQUGq9d qZmHamuLqYOpgTgqQNKBYm8y1jLBRBAxeSMG0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=MnzCpb4EH4P475+cRsobxt73q/Ji/XsGAxu8k9sJgBtynmVo9whayzWPBTYOImSRPd KYzSptdUh8MYmo+i9z6+yx/IUBoZiMsgF49ieaATgDGU8Y7R8HWA+n61h2PTT4rjSEbd S5K1MD9bsrf56wlSHfwey5zK7gNS6lPXklXrM= MIME-Version: 1.0 Received: by 10.216.18.212 with SMTP id l62mr1046507wel.76.1240987355471; Tue, 28 Apr 2009 23:42:35 -0700 (PDT) Date: Wed, 29 Apr 2009 08:42:35 +0200 Message-ID: <261c29700904282342q62828573hf2631a7f79a10581@mail.gmail.com> From: miki miki To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: [ed] link state constantly going down and up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 07:13:56 -0000 Hi, I have a problem with a D-Link DFE-670TXD which is handled by if_ed : the link state is constantly going down and up : Apr 28 14:21:33 iut-mir-o kernel: ed0: link state changed to DOWN Apr 28 14:21:35 iut-mir-o kernel: ed0: link state changed to UP Apr 28 14:21:40 iut-mir-o kernel: ed0: link state changed to DOWN Apr 28 14:21:42 iut-mir-o kernel: ed0: link state changed to UP Apr 28 14:22:51 iut-mir-o kernel: ed0: link state changed to DOWN Apr 28 14:22:53 iut-mir-o kernel: ed0: link state changed to UP I've double checked that there are no wire/switch/hub problems. The card used to work fine with previous version of FreeBSD, the problem appear with the following commit : SVN rev 190643 on 2009-04-02 16:58:45Z by imp (CVS rev 1.126) I do not see any link state change if I revert the commit. FreeBSD [hostname] 8.0-CURRENT FreeBSD 8.0-CURRENT #6 r191614M: Tue Apr 28 07:57:07 CEST 2009 user@hostname:/usr/obj/usr/src/sys/LETHE amd64 ed0: at port 0x100-0x11f irq 19 function 0 config 32 on pccard0 ed0: WARNING: using obsoleted if_watchdog interface ed0: Ethernet address: 00:0d:88:21:54:e2 miibus1: on ed0 nsphyter0: PHY 1 on miibus1 nsphyter0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dev.ed.0.type: DL10022 dev.ed.0.TxMem: 4608 dev.ed.0.RxMem: 19968 dev.ed.0.Mem: 24576 dev.ed.0.%desc: D-Link DFE-670TXD dev.ed.0.%driver: ed dev.ed.0.%location: function=0 dev.ed.0.%pnpinfo: manufacturer=0x0149 product=0x4530 cisvendor="D-Link" cisproduct="DFE-670TXD" function_type=6 dev.ed.0.%parent: pccard0 Should I submit a PR ? Thanks for your support, Miki From owner-freebsd-net@FreeBSD.ORG Wed Apr 29 12:46:33 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 520441065690 for ; Wed, 29 Apr 2009 12:46:33 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63907.mail.re1.yahoo.com (web63907.mail.re1.yahoo.com [69.147.97.122]) by mx1.freebsd.org (Postfix) with SMTP id EF24C8FC18 for ; Wed, 29 Apr 2009 12:46:32 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 41710 invoked by uid 60001); 29 Apr 2009 12:46:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1241009192; bh=kr8/TfH7DP/iwWGW8TqJPdwZNEkwSk39x4sd+MJWxIg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=xwSD4yC4wVXawB3M8cj42TQ+THrU/4CiMikO6ec7qJdfEZ6usMek53xveaAevjsMbZw1UnJ+wma9zGURsZjCqITd0CA53AaxRVzWF+sj/sFuMKjlAwhFqz/nsduPk394i5YFRmb9DEiqz8qPNJ7bUprdmWzAngMlQRhc2tFqcTI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nuUybDqFMLz1bjkCSNBG6vJrPVGKC/jk7mTfs76i5XuMV+ZoXvPSxi+9JYDZuMbrxP+Ch4c9mKh6QqNBXmtBQIUvoif1zeUXgZwiMt6bege6e59X/5FFTalGWfX36fu3otX1d+2tJ7UydCCPEayjDenmvJjRpSG5lL+irIf/+Ps=; Message-ID: <172091.41695.qm@web63907.mail.re1.yahoo.com> X-YMail-OSG: dW1.4WMVM1kHPEELwJi5fPXVi3emgZrpb0fOp64_bZC2I6frMnpMh7ET7Vyp08h2m.qYg8iFqbVpEDOTTzQ2Gc_1_d9mJRrTTXy7xvUCfNDsMYE7yi_8PYJMsyAMjuLgIWO.z2GDTcuTralulGSoymHukkU6sp3wF6xOE_bOpaRdZhMgzOckr19QmSsSgBOMgZlQ.5NrDGEOdo837Q7D4RfL1eKNZUSXnq16SWcngalSgp6.bTiQJ0TR3rFs7pSt371YQmHiWyh67Arm9Azi5hHsswtqbbqJNUdg Received: from [98.242.223.106] by web63907.mail.re1.yahoo.com via HTTP; Wed, 29 Apr 2009 05:46:32 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Wed, 29 Apr 2009 05:46:32 -0700 (PDT) From: Barney Cordoba To: Luigi Rizzo , Andrew Snow In-Reply-To: <49F7709F.1020409@modulus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: FreeBSD Net Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 12:46:33 -0000 --- On Tue, 4/28/09, Andrew Snow wrote: > From: Andrew Snow > Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) > To: "Luigi Rizzo" > Cc: "FreeBSD Net" > Date: Tuesday, April 28, 2009, 5:09 PM > Luigi Rizzo wrote: > > If i am not mistaken we don't have generic support > for interrupt moderation > > in the kernel but that's a specific NIC feature: > it works if the > > hardware supports it, and it doesn't otherwise. > > > > Of course it would be possible to modify polling to > implement > > generic interrupt mitigation even without hardware > support, so > > you get the best of the two worlds. > > It seems to me that you're wasting your time if you are > trying to achieve a high throughput in FreeBSD without using > an Intel Pro/1000 or 10gbe networking card. > > So I don't know if anyone would really miss out if > generic polling support was completely removed from the > kernel and all efforts were then placed into improving other > parts of network flow in the kernel which need more help. > > > - Andrew I'm not sure if those specific NICs are the "only" choices. But I am concerned that so much brainpower is being put to extending the life of antiquated science projects and so little (maybe none?) is being put to improving drivers and the general network threading and performance. You spend 3 years redesigning the kernel, yet there are no resources to create a decent 10gb/s solution, to get rid of netgraph and to do network integration properly, or to improve the large number of mediocre drivers that were written what might as well be 100 years ago. When the collective answer to better network performance is polling, it makes it appear as if the FreeBSD project is a bunch of dudes working on stuff they feel like doing, rather than there being some centralized plan to make the project successful. Barney From owner-freebsd-net@FreeBSD.ORG Wed Apr 29 13:32:22 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAD42106567E for ; Wed, 29 Apr 2009 13:32:22 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id 7EB238FC28 for ; Wed, 29 Apr 2009 13:32:22 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by qw-out-2122.google.com with SMTP id 3so868381qwe.7 for ; Wed, 29 Apr 2009 06:32:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :x-pgp-agent:x-mailer; bh=meXY6oyh6RBEbR8uaOxdtu69Kmw8YpIjUkrqILwUhSc=; b=osHH64+OENWoTNOiopE4NLWFhFybfyc4pCJae0ABrEzoK1nR0sDiu5020sIh18in0Z atrERlQQBVwL2wnKI4O+JquUYXs0V3/mRBDtHAEgjG5mBwVmX/HzEurhGmRCFcB46Czy 06OLB9HG495fwugTCBrr29MZdxh2LaTC/E0eo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-pgp-agent:x-mailer; b=GoxPvW0ok8YInXBlYrEcBb9r1Q2ELTxecTpWMo9bq41/1603xidGBhiL7kSMNsRhQv M2VO3Y8w6ox+PqDOSqHuvTNKFFI8KNkmOasquJXfogIdUanVQRgNXuN2NoH5hRZKt78i Zbyov6+uo59O9hgNzQzlDssCismK6j7HkGicg= Received: by 10.231.19.75 with SMTP id z11mr159565iba.0.1241009944457; Wed, 29 Apr 2009 05:59:04 -0700 (PDT) Received: from ndenev.cmotd.com (blah.sun-fish.com [217.18.249.150]) by mx.google.com with ESMTPS id 5sm3142891yxt.44.2009.04.29.05.59.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 29 Apr 2009 05:59:03 -0700 (PDT) Message-Id: <5E915E92-2B82-4331-9493-739568CC6E8C@gmail.com> From: Nikolay Denev To: freebsd-net@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 29 Apr 2009 15:58:57 +0300 X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.930.3) Subject: bce(4) sees all incoming frames as 2026 bytes in length X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 13:32:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I have the following problem with the new bce(4) driver on a 7.2-=20 PRERELEASE from a few days ago. When I run tcpdump on the bce interface on the machine, all incoming =20 frames are shown as 2026 in size, but on the sending machine tcpdump reports that it's sending frames of =20= the correct size. This looks very strange because I don't have enabled Jumbo Frames on =20 this bce interface , and it is still with it's default MTU of 1500 =20 bytes. When I tried to capture the packets, they are zero padded to the 2026 =20= frame size. The checksums are correct, so I suspect a driver bug? P.S.: I experience this problem on several machines with bce =20 interfaces, and on all of them tcpdump sees all incoming frames with =20 length of 2026 bytes. Regards, Niki Denev -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (Darwin) iEYEARECAAYFAkn4TxIACgkQHNAJ/fLbfrmBKgCgkJ6j//+lLrrb+dL3HcLmDxym 4mQAn1qaY41CxWHiVthhCs6lYblX6UMd =3D+9XA -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Wed Apr 29 13:37:48 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B02A7106566B for ; Wed, 29 Apr 2009 13:37:48 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 411B28FC1D for ; Wed, 29 Apr 2009 13:37:47 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-255-48-78.bredband.comhem.se ([83.255.48.78]:54294 helo=falcon.midgard.homeip.net) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1Lz9jc-0000DU-6I for freebsd-net@freebsd.org; Wed, 29 Apr 2009 15:22:03 +0200 Received: (qmail 3158 invoked from network); 29 Apr 2009 15:21:56 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 29 Apr 2009 15:21:56 +0200 Received: (qmail 42828 invoked by uid 1001); 29 Apr 2009 15:21:56 +0200 Date: Wed, 29 Apr 2009 15:21:56 +0200 From: Erik Trulsson To: Barney Cordoba Message-ID: <20090429132156.GA42816@owl.midgard.homeip.net> References: <49F7709F.1020409@modulus.org> <172091.41695.qm@web63907.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <172091.41695.qm@web63907.mail.re1.yahoo.com> User-Agent: Mutt/1.5.19 (2009-01-05) X-Originating-IP: 83.255.48.78 X-Scan-Result: No virus found in message 1Lz9jc-0000DU-6I. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1Lz9jc-0000DU-6I 51c4abd22e7425fa44b2471c6670029e Cc: FreeBSD Net , Luigi Rizzo , Andrew Snow Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 13:37:49 -0000 On Wed, Apr 29, 2009 at 05:46:32AM -0700, Barney Cordoba wrote: > > > > > --- On Tue, 4/28/09, Andrew Snow wrote: > > > From: Andrew Snow > > Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) > > To: "Luigi Rizzo" > > Cc: "FreeBSD Net" > > Date: Tuesday, April 28, 2009, 5:09 PM > > Luigi Rizzo wrote: > > > If i am not mistaken we don't have generic support > > for interrupt moderation > > > in the kernel but that's a specific NIC feature: > > it works if the > > > hardware supports it, and it doesn't otherwise. > > > > > > Of course it would be possible to modify polling to > > implement > > > generic interrupt mitigation even without hardware > > support, so > > > you get the best of the two worlds. > > > > It seems to me that you're wasting your time if you are > > trying to achieve a high throughput in FreeBSD without using > > an Intel Pro/1000 or 10gbe networking card. > > > > So I don't know if anyone would really miss out if > > generic polling support was completely removed from the > > kernel and all efforts were then placed into improving other > > parts of network flow in the kernel which need more help. > > > > > > - Andrew > > I'm not sure if those specific NICs are the "only" choices. But I am > concerned that so much brainpower is being put to extending the life > of antiquated science projects and so little (maybe none?) is being > put to improving drivers and the general network threading and > performance. > > You spend 3 years redesigning the kernel, yet there are no resources to > create a decent 10gb/s solution, to get rid of netgraph and to do > network integration properly, or to improve the large number of mediocre > drivers that were written what might as well be 100 years ago. If you think that more resources should be applied on certain areas, then feel free to provide said resources yourself. Other people are unlikely to change what they work on just because you want them to. > > When the collective answer to better network performance is polling, it > makes it appear as if the FreeBSD project is a bunch of dudes working on > stuff they feel like doing, rather than there being some centralized plan > to make the project successful. That appearance is probably due to the fact the the FreeBSD project actually is a bunch of dudes working on what they feel like doing (or in a few cases on what they get paid for doing), and that there is very little centralized planning being done. (And even if there was, there is no way of enforcing that people work according to such a plan.) -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-net@FreeBSD.ORG Wed Apr 29 13:52:11 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09AAC106566B for ; Wed, 29 Apr 2009 13:52:11 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id C11CB8FC0C for ; Wed, 29 Apr 2009 13:52:10 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id E21F7730A1; Wed, 29 Apr 2009 15:57:22 +0200 (CEST) Date: Wed, 29 Apr 2009 15:57:22 +0200 From: Luigi Rizzo To: Erik Trulsson Message-ID: <20090429135722.GB51674@onelab2.iet.unipi.it> References: <49F7709F.1020409@modulus.org> <172091.41695.qm@web63907.mail.re1.yahoo.com> <20090429132156.GA42816@owl.midgard.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090429132156.GA42816@owl.midgard.homeip.net> User-Agent: Mutt/1.4.2.3i Cc: Barney Cordoba , Andrew Snow , FreeBSD Net Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 13:52:11 -0000 On Wed, Apr 29, 2009 at 03:21:56PM +0200, Erik Trulsson wrote: > On Wed, Apr 29, 2009 at 05:46:32AM -0700, Barney Cordoba wrote: ... > > When the collective answer to better network performance is polling, it > > makes it appear as if the FreeBSD project is a bunch of dudes working on > > stuff they feel like doing, rather than there being some centralized plan > > to make the project successful. > > That appearance is probably due to the fact the the FreeBSD project actually > is a bunch of dudes working on what they feel like doing (or in a few cases > on what they get paid for doing), and that there is very little centralized > planning being done. (And even if there was, there is no way of enforcing > that people work according to such a plan.) not to mention that very little if any work has been done on polling recently: i developed the base system in 2001-2002, and since then there has been just some basic maintainance (at least in the tree). cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Apr 29 14:00:00 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B07D9106566B for ; Wed, 29 Apr 2009 14:00:00 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.186]) by mx1.freebsd.org (Postfix) with ESMTP id 2E59C8FC16 for ; Wed, 29 Apr 2009 13:59:59 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by gv-out-0910.google.com with SMTP id n8so752gve.39 for ; Wed, 29 Apr 2009 06:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9xUgPcCnK98YjXMpfM5fbIjrzngVRnqTQMvvhVHfnEE=; b=UwaTV9A3s4nME/pA2sxJhU9gBUz7/IrqnVxs6mpwuYi2agCJAuXvThN9YtUOlX+9pC uvBwLuaLEcBy8Hu5iF90Km+coLphxrY3M8XmPiaGgj86UCWlb0cQks0VApNDUhkufoS4 9cUAXFuQktTf/XVmVMAlzxBHJeHHRPSD9OshQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=F9vyxXts401syRt/pNJXGWal0sdMDUYo1EP+JOIEP0/gi2iryEUk+lIe65vGmcurEa yrTlYBCL/P2r9DVYzGTKSSd1vg51oozshBamkaYZr9QE6KC8kKbnACG/a/9bmHJxbnvT 1LpOIdo4OpX5XYiEulZhZ/APSltAL8HVbxsW0= MIME-Version: 1.0 Received: by 10.103.213.19 with SMTP id p19mr259670muq.9.1241013598541; Wed, 29 Apr 2009 06:59:58 -0700 (PDT) In-Reply-To: <5E915E92-2B82-4331-9493-739568CC6E8C@gmail.com> References: <5E915E92-2B82-4331-9493-739568CC6E8C@gmail.com> Date: Wed, 29 Apr 2009 17:59:58 +0400 Message-ID: From: pluknet To: Nikolay Denev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: bce(4) sees all incoming frames as 2026 bytes in length X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 14:00:00 -0000 2009/4/29 Nikolay Denev : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > I have the following problem with the new bce(4) driver on a 7.2-PRERELEASE > from a few days ago. > When I run tcpdump on the bce interface on the machine, all incoming frames > are shown as 2026 in size, > but on the sending machine tcpdump reports that it's sending frames of the > correct size. > This looks very strange because I don't have enabled Jumbo Frames on this > bce interface , and it is still with it's default MTU of 1500 bytes. > When I tried to capture the packets, they are zero padded to the 2026 frame > size. The checksums are correct, so I suspect a driver bug? > > P.S.: I experience this problem on several machines with bce interfaces, and > on all of them tcpdump sees all incoming frames with length of 2026 bytes. hi. Please, give us more details. What is your network card model ? Share ifconfig, dmesg... I have a similar setup, except the frame size - mine are with expected values. -- wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Wed Apr 29 14:33:22 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5023D1065672 for ; Wed, 29 Apr 2009 14:33:22 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-fx0-f162.google.com (mail-fx0-f162.google.com [209.85.220.162]) by mx1.freebsd.org (Postfix) with ESMTP id A463F8FC17 for ; Wed, 29 Apr 2009 14:33:21 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by fxm6 with SMTP id 6so1213307fxm.43 for ; Wed, 29 Apr 2009 07:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1QauAWoi0+qukwNWvQ9M9vqmCI1PQB8U3W0i894jkwk=; b=K6osPdJ1wNTTnRtCzWuUOldHlxl7JK4vmUyJiACE3Rl1DlaFlg0GUTlG4q59QDLUPZ zKuo8XPx9XwU9R+KPQXMTbDDggoPCu425EaWbsjIqvF81JcHgx/kjA3eQUKemfq5unG5 yXGAfRBHnmsF4W5vdbglqT+ux2jTKQKg4E8nA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=T4pKS5xU6H4vrvoViW3PRpvBvNz+7UTZikcRaeXCdK4onBpxZ0C6vX1rzBc5BVX0TF 2xJyH1smom3ULvkctN6A5QYho0M4RfqwpZTYhOWgqnU+vtENVioxIKcRPWkRe2uISPdq VHzwRHButABsXMbzO8S7/T27dymhzsNFlZs04= MIME-Version: 1.0 Received: by 10.223.108.196 with SMTP id g4mr254215fap.36.1241015600551; Wed, 29 Apr 2009 07:33:20 -0700 (PDT) In-Reply-To: References: <5E915E92-2B82-4331-9493-739568CC6E8C@gmail.com> Date: Wed, 29 Apr 2009 17:33:18 +0300 Message-ID: <2e77fc10904290733m4858172ayd96654f3a9a3a8a@mail.gmail.com> From: Niki Denev To: pluknet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: bce(4) sees all incoming frames as 2026 bytes in length X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 14:33:22 -0000 On Wed, Apr 29, 2009 at 4:59 PM, pluknet wrote: > 2009/4/29 Nikolay Denev : >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hello, >> >> I have the following problem with the new bce(4) driver on a 7.2-PRERELEASE >> from a few days ago. >> When I run tcpdump on the bce interface on the machine, all incoming frames >> are shown as 2026 in size, >> but on the sending machine tcpdump reports that it's sending frames of the >> correct size. >> This looks very strange because I don't have enabled Jumbo Frames on this >> bce interface , and it is still with it's default MTU of 1500 bytes. >> When I tried to capture the packets, they are zero padded to the 2026 frame >> size. The checksums are correct, so I suspect a driver bug? >> >> P.S.: I experience this problem on several machines with bce interfaces, and >> on all of them tcpdump sees all incoming frames with length of 2026 bytes. > > hi. > > Please, give us more details. What is your network card model ? > Share ifconfig, dmesg... > I have a similar setup, except the frame size - mine are with expected values. > > -- > wbr, > pluknet > Hi, Here is one of the cards that have this problem : bce1: mem 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci3 bce1: Ethernet address: 00:22:19:xx:xx:xx bce1: [ITHREAD] bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (0x04040105); Flags( MFW MSI ) bce1: flags=8843 metric 0 mtu 1500 options=1bb ether 00:22:19:xx:xx:xx inet 10.18.2.1 netmask 0xffffff00 broadcast 10.18.2.255 media: Ethernet autoselect (1000baseTX ) status: active And here is a tcpdump that shows the problem : 16:27:32.593808 00:22:19:yy:yy:yy > 00:22:19:xx:xx:xx, ethertype IPv4 (0x0800), length 2026: (tos 0x0, ttl 64, id 45347, offset 0, flags [none], proto ICMP (1), length 84) 10.18.2.2 > 10.18.2.1: ICMP echo request, id 13578, seq 36, length 64 16:27:32.593817 00:22:19:xx:xx:xx > 00:22:19:yy:yy:yy, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 18415, offset 0, flags [none], proto ICMP (1), length 84) 10.18.2.1 > 10.18.2.2: ICMP echo reply, id 13578, seq 36, length 64 16:27:33.596569 00:22:19:yy:yy:yy > 00:22:19:xx:xx:xx, ethertype IPv4 (0x0800), length 2026: (tos 0x0, ttl 64, id 45349, offset 0, flags [none], proto ICMP (1), length 84) 10.18.2.2 > 10.18.2.1: ICMP echo request, id 13578, seq 37, length 64 16:27:33.596575 00:22:19:xx:xx:xx > 00:22:19:yy:yy:yy, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 18421, offset 0, flags [none], proto ICMP (1), length 84) 10.18.2.1 > 10.18.2.2: ICMP echo reply, id 13578, seq 37, length 64 16:27:34.599332 00:22:19:yy:yy:yy > 00:22:19:xx:xx:xx, ethertype IPv4 (0x0800), length 2026: (tos 0x0, ttl 64, id 45351, offset 0, flags [none], proto ICMP (1), length 84) 10.18.2.2 > 10.18.2.1: ICMP echo request, id 13578, seq 38, length 64 16:27:34.599338 00:22:19:xx:xx:xx > 00:22:19:yy:yy:yy, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 18427, offset 0, flags [none], proto ICMP (1), length 84) 10.18.2.1 > 10.18.2.2: ICMP echo reply, id 13578, seq 38, length 64 16:27:35.545001 00:22:19:yy:yy:yy > 01:00:5e:00:00:05, ethertype IPv4 (0x0800), length 2026: (tos 0xc0, ttl 1, id 45353, offset 0, flags [none], proto OSPF (89), length 68) 10.18.2.2 > 224.0.0.5: OSPFv2, Hello, length: 48 16:27:35.545062 00:22:19:xx:xx:xx > 01:00:5e:00:00:05, ethertype IPv4 (0x0800), length 82: (tos 0xc0, ttl 1, id 18432, offset 0, flags [none], proto OSPF (89), length 68) 10.18.2.1 > 224.0.0.5: OSPFv2, Hello, length: 48 There is nothing special about the setup, a few machines connected to a gigabit switch, and some of them have cross connects. I'm seeing this on all bce(4) interfaces, regardless of what they are connected to (other bce(4) interface, or GigE switch). -- Regards, Niki From owner-freebsd-net@FreeBSD.ORG Wed Apr 29 16:04:28 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B04011065672 for ; Wed, 29 Apr 2009 16:04:28 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 399B38FC16 for ; Wed, 29 Apr 2009 16:04:27 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by bwz9 with SMTP id 9so1250873bwz.43 for ; Wed, 29 Apr 2009 09:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3f8L6XAekd8ZMGv/75zDXGuhKAXk+UKt/Hi9Ud/yxjw=; b=pC6s/py3+89IVtNxzcZhH2KWu4wxknqSiSZy5BegiObtZCxP1MpJ3gpO1/KNwjl4m4 cZ4FUpohwkQDYHYZGH48DDeZepxpFaOiQM5539iFTvVoql6/W8oFj29bC+4FGpVZJ6GT lBnKDSQl5e8L7tZyP8SlNAGTFb7xy5AspUKZU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jY9SSS270rl7QHUvxqABOYDwGZLOTAMjCwE9QvC09da+B0Lp5xm2KodIHAbeE0ntIm LgRgMHPhvTyarV+w+fspKgcXgf+3DbUQ+wzj8pp0kfF+UmWRatiI9KdronRexxWLkSuc Kr3qHCINPQzorlUD0UIeGUOrUIF8thZo+3mtU= MIME-Version: 1.0 Received: by 10.103.117.9 with SMTP id u9mr328229mum.55.1241021067053; Wed, 29 Apr 2009 09:04:27 -0700 (PDT) In-Reply-To: <2e77fc10904290733m4858172ayd96654f3a9a3a8a@mail.gmail.com> References: <5E915E92-2B82-4331-9493-739568CC6E8C@gmail.com> <2e77fc10904290733m4858172ayd96654f3a9a3a8a@mail.gmail.com> Date: Wed, 29 Apr 2009 20:04:26 +0400 Message-ID: From: pluknet To: Niki Denev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: bce(4) sees all incoming frames as 2026 bytes in length X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 16:04:29 -0000 2009/4/29 Niki Denev : > bce1: mem > 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci3 > bce1: Ethernet address: 00:22:19:xx:xx:xx > bce1: [ITHREAD] > bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C > (0x04040105); Flags( MFW MSI ) > > bce1: flags=8843 metric 0 mtu 1500 > options=1bb > ether 00:22:19:xx:xx:xx > inet 10.18.2.1 netmask 0xffffff00 broadcast 10.18.2.255 > media: Ethernet autoselect (1000baseTX ) > status: active > > And here is a tcpdump that shows the problem : > > 16:27:32.593808 00:22:19:yy:yy:yy > 00:22:19:xx:xx:xx, ethertype IPv4 > (0x0800), length 2026: (tos 0x0, ttl 64, id 45347, offset 0, flags > [none], proto ICMP (1), length 84) 10.18.2.2 > 10.18.2.1: ICMP echo > request, id 13578, seq 36, length 64 > 16:27:32.593817 00:22:19:xx:xx:xx > 00:22:19:yy:yy:yy, ethertype IPv4 > (0x0800), length 98: (tos 0x0, ttl 64, id 18415, offset 0, flags > [none], proto ICMP (1), length 84) 10.18.2.1 > 10.18.2.2: ICMP echo > reply, id 13578, seq 36, length 64 Ok, now I see. A link level length is 2026 for me too for some sort of packets (in opposite to proto's len where all is ok). Mine nic is (same as yours). Looks like a regression. I just also tested 7.1-R and it shows expected LL-length. -- wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Wed Apr 29 19:05:01 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFEF010656EC for ; Wed, 29 Apr 2009 19:05:01 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63901.mail.re1.yahoo.com (web63901.mail.re1.yahoo.com [69.147.97.116]) by mx1.freebsd.org (Postfix) with SMTP id 536BC8FC12 for ; Wed, 29 Apr 2009 19:05:01 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 55271 invoked by uid 60001); 29 Apr 2009 19:05:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1241031900; bh=CIRSDEGLwc2LdpQLTtvJ6TCuQO+QGS9VwGdI0HZPQTI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=mDKAFugxrgv8MT1ZJYTijG9XFFvcPMqJpHCSPrGIJardk7KnPR6mcQjkIf6UJR0voOMp0B4QgOqY2PsQ/fA8V5FDvUWBF22pPzCWLeV2Zt0ycBZU2AOQzZJvptPb0aKVr2ZPm5v1tB94KULBntxtbnTim6XqTgwNo50inB/2NO8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=txg0X9Pom7KrrsdQA6jf/7C9yUzWGkMYqdHFl6df7fzkmRow8rASgDKL8Zv3rdA8FTnxRtHcLydMBJzoJ967V7jCohxDJcxjHLuqsAEmiP6yVMK3JW+0U6bGuUaHBDxrHmdcdoha70yj391sXyIznBX0o/QWuKouaAk+LXatxrM=; Message-ID: <628939.54925.qm@web63901.mail.re1.yahoo.com> X-YMail-OSG: vmeablUVM1nZcEWUuZqSGh3H37qKTRcqKjf3FVvLzpLAOC._HGXCHkyfs9VoNcs2kunJkXe9G1ZnTe7vTogGZJ4PZagik63RNUnGssG8LLAvaR2otitv6xaqLK.PePW.d6TuHhN3F_rQeCjWJs.ZtvDuGIFfKCnXw1VsKZR2kaLI_Ok4l5ptjho_YR7izcNL8rwdw6ipxQRXxcImA0WDt9RS5eCEF9O17LaIwjQ3Eefj9GLl0eA.ScSDmDoXXtr2xoMnVATqSh2PTvyR3RXAldc3iHS5m0bIsJxUlJMeKYn0nw5LMiEcQxkhd.22aHp89uwHO1dC74PTbzJ_wAKL8lf_8URR61BMb4XofIE- Received: from [98.242.223.106] by web63901.mail.re1.yahoo.com via HTTP; Wed, 29 Apr 2009 12:05:00 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Wed, 29 Apr 2009 12:05:00 -0700 (PDT) From: Barney Cordoba To: Erik Trulsson In-Reply-To: <20090429132156.GA42816@owl.midgard.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: FreeBSD Net , Luigi Rizzo , Andrew Snow Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 19:05:02 -0000 --- On Wed, 4/29/09, Erik Trulsson wrote: > From: Erik Trulsson > Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) > To: "Barney Cordoba" > Cc: "FreeBSD Net" , "Luigi Rizzo" , "Andrew Snow" > Date: Wednesday, April 29, 2009, 9:21 AM > On Wed, Apr 29, 2009 at 05:46:32AM -0700, Barney Cordoba > wrote: > > > > > > > > > > --- On Tue, 4/28/09, Andrew Snow > wrote: > > > > > From: Andrew Snow > > > Subject: Re: Interrupts + Polling mode (similar > to Linux's NAPI) > > > To: "Luigi Rizzo" > > > > Cc: "FreeBSD Net" > > > > Date: Tuesday, April 28, 2009, 5:09 PM > > > Luigi Rizzo wrote: > > > > If i am not mistaken we don't have > generic support > > > for interrupt moderation > > > > in the kernel but that's a specific NIC > feature: > > > it works if the > > > > hardware supports it, and it doesn't > otherwise. > > > > > > > > Of course it would be possible to modify > polling to > > > implement > > > > generic interrupt mitigation even without > hardware > > > support, so > > > > you get the best of the two worlds. > > > > > > It seems to me that you're wasting your time > if you are > > > trying to achieve a high throughput in FreeBSD > without using > > > an Intel Pro/1000 or 10gbe networking card. > > > > > > So I don't know if anyone would really miss > out if > > > generic polling support was completely removed > from the > > > kernel and all efforts were then placed into > improving other > > > parts of network flow in the kernel which need > more help. > > > > > > > > > - Andrew > > > > I'm not sure if those specific NICs are the > "only" choices. But I am > > concerned that so much brainpower is being put to > extending the life > > of antiquated science projects and so little (maybe > none?) is being > > put to improving drivers and the general network > threading and > > performance. > > > > You spend 3 years redesigning the kernel, yet there > are no resources to > > create a decent 10gb/s solution, to get rid of > netgraph and to do > > network integration properly, or to improve the large > number of mediocre > > drivers that were written what might as well be 100 > years ago. > > If you think that more resources should be applied on > certain areas, then > feel free to provide said resources yourself. Other people > are unlikely to > change what they work on just because you want them to. > > > > > When the collective answer to better network > performance is polling, it > > makes it appear as if the FreeBSD project is a bunch > of dudes working on > > stuff they feel like doing, rather than there being > some centralized plan > > to make the project successful. > > That appearance is probably due to the fact the the FreeBSD > project actually > is a bunch of dudes working on what they feel like doing > (or in a few cases > on what they get paid for doing), and that there is very > little centralized > planning being done. (And even if there was, there is no > way of enforcing > that people work according to such a plan.) Its one of the sad truths of FreeBSD. You'd think with such a large number of commercial users you'd be able to get plenty of funding for the things that really need to be done, rather then taking whatever bread crumbs are thrown your way. Perhaps you need fewer bearded academics and a few more suits to run the project more like a business than an extended masters thesis? BC From owner-freebsd-net@FreeBSD.ORG Wed Apr 29 19:07:37 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 285CE106564A for ; Wed, 29 Apr 2009 19:07:37 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63907.mail.re1.yahoo.com (web63907.mail.re1.yahoo.com [69.147.97.122]) by mx1.freebsd.org (Postfix) with SMTP id BED7B8FC08 for ; Wed, 29 Apr 2009 19:07:36 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 37688 invoked by uid 60001); 29 Apr 2009 19:07:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1241032055; bh=5K4OXwnzTGqmewJ6CwSmjmg5ty1VJ3I+xCQckDV4f4M=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VdhHN3mcRDSnz0s+2f4HiE4JcaYQs8+DutBQnpvffTBoTISLFDhv9EtL7QMvPkWsxVIjbP5CCXwmxeUEw+en6fsLG4wgj5B206skNYmvbgBggYNk4vsLJn8x5mAGjWG7KFcygnXe5jbshlVM2WSlYkVYDIasL3eoSWC7QnuDnXM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=t4cC5nZzdFdSe6cL9rJjk/TUsMCrfBS94eKaDjQ0LrFuRIecftrqdS3WDrFnme6sjT1VI83gStxfvX6Pr6xKFC0goZnVVOsJyJTD+iG91npGeWY+1Uytm5V9qLtjR1ftVl/5+g/TR5lXYPyYD2wrMhYcvM7MuwuMgaTot7o2eH4=; Message-ID: <606440.37646.qm@web63907.mail.re1.yahoo.com> X-YMail-OSG: srL38nsVM1l62wL55OYTesGonvCdXAT2_c.I5_0652R2qYiL8S61NIrgJjKjlqPfaMZI3GqdY4z5gnhLW3n2NtH2qi7TYo9gfLyeaPk68eddd.Fi3EEy6VWZLgTN5mfgi4yWSMH2uQsEaWH3EQYyhs6oHYwzH2NFv1ArExKKZ2KFpnPFc3rbECbxC1O9.bAh3eL73x53ijmaaOyr_XQWvcg5F7hPkYbpG1FO0XNBdz62cM2wiWe6Nug6CJbgoTxu6bvEUEzCy2mz1cuf1SFubxDtyqW6GzCbZoHckOOOrzCKWctdtZeVoY7k418cIu5OMcf.qDhiY6.LDuNitQpg5XDl Received: from [98.242.223.106] by web63907.mail.re1.yahoo.com via HTTP; Wed, 29 Apr 2009 12:07:35 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Wed, 29 Apr 2009 12:07:35 -0700 (PDT) From: Barney Cordoba To: Erik Trulsson , Luigi Rizzo In-Reply-To: <20090429135722.GB51674@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: FreeBSD Net , Andrew Snow Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 19:07:37 -0000 --- On Wed, 4/29/09, Luigi Rizzo wrote: > From: Luigi Rizzo > Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) > To: "Erik Trulsson" > Cc: "Barney Cordoba" , "Andrew Snow" , "FreeBSD Net" > Date: Wednesday, April 29, 2009, 9:57 AM > On Wed, Apr 29, 2009 at 03:21:56PM +0200, Erik Trulsson > wrote: > > On Wed, Apr 29, 2009 at 05:46:32AM -0700, Barney > Cordoba wrote: > ... > > > When the collective answer to better network > performance is polling, it > > > makes it appear as if the FreeBSD project is a > bunch of dudes working on > > > stuff they feel like doing, rather than there > being some centralized plan > > > to make the project successful. > > > > That appearance is probably due to the fact the the > FreeBSD project actually > > is a bunch of dudes working on what they feel like > doing (or in a few cases > > on what they get paid for doing), and that there is > very little centralized > > planning being done. (And even if there was, there is > no way of enforcing > > that people work according to such a plan.) > > not to mention that very little if any work has been done > on polling recently: i developed the base system in > 2001-2002, > and since then there has been just some basic maintainance > (at least in the tree). > > cheers > luigi Obviously someone has ported it to 5, 6 and 7, and the pat answer to performance questions about a driver is "have you tried polling"? Its counterproductive and gives people an excuse not to create any mechanisms to properly tune drivers and to write them correctly for SMP kernels. Barney From owner-freebsd-net@FreeBSD.ORG Wed Apr 29 20:12:50 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5C88106564A for ; Wed, 29 Apr 2009 20:12:50 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 5259E8FC19 for ; Wed, 29 Apr 2009 20:12:50 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n3TKA1vt097260; Wed, 29 Apr 2009 14:10:01 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 29 Apr 2009 14:10:02 -0600 (MDT) Message-Id: <20090429.141002.-720655694.imp@bsdimp.com> To: miki miki From: "M. Warner Losh" in-reply-to: <261c29700904282342q62828573hf2631a7f79a10581@mail.gmail.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: [ed] link state constantly going down and up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 20:12:50 -0000 : I have a problem with a D-Link DFE-670TXD which is handled by if_ed : : the link state is constantly going down and up : : Apr 28 14:21:33 iut-mir-o kernel: ed0: link state changed to DOWN : Apr 28 14:21:35 iut-mir-o kernel: ed0: link state changed to UP ... : the problem appear with the following commit : : SVN rev 190643 on 2009-04-02 16:58:45Z by imp (CVS rev 1.126) : I do not see any link state change if I revert the commit. Doh! I needed to force auto negotiation for other cards to work. Let me see if I can dig up the DFE-670TXD and go from there... Are you also seeing really horrible network performance as well? Do you see this only under load, or just at idle? Warner From owner-freebsd-net@FreeBSD.ORG Wed Apr 29 23:30:07 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BED5106564A for ; Wed, 29 Apr 2009 23:30:07 +0000 (UTC) (envelope-from vinnix.bsd@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id BC7278FC12 for ; Wed, 29 Apr 2009 23:30:06 +0000 (UTC) (envelope-from vinnix.bsd@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so928427yxb.13 for ; Wed, 29 Apr 2009 16:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=lt9MseX5G9Gb9zrI9WEehmnEWlRIhhmfHGDsR2uvjBk=; b=tyHy/OLy2FW4qz5sfr5clJbYT+0bogNgca9z6LEmgopEjtJn2VEnkHRjQS7T/Cj+OC QL2Vv1wJZs9+oC0veC4miGC6xHdmbisPjttDj5KONPwauknSktZC8h+w7oRXiSDG0BtH eaAdzwhyJxSK3NlIsMibzLttgy/G1mhaSB0x8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=mwbjq76F/JKZ2Df7NgOuh3aoj7zEFMSpcu4Y2xq3pXHt2jammnyqECxOvjiVv309e8 IDNFyygz4AzdueiiaJDW0qoZYgtUt3HwSZVr+m6l1WMirM5Eyu0fdusrBnva6wYsJKyv GNqAs5uUkIxu9M0fFC4UTL7w2JJp4VV+4t/cs= MIME-Version: 1.0 Received: by 10.231.32.70 with SMTP id b6mr1105241ibd.23.1241046348218; Wed, 29 Apr 2009 16:05:48 -0700 (PDT) Date: Wed, 29 Apr 2009 20:05:48 -0300 Message-ID: <1e31c7980904291605h55244aech10a7725d59fd0cd@mail.gmail.com> From: Vinicius Abrahao To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Problem with lagg failover (using bge0 and wpi0 interfaces) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 23:30:07 -0000 Hi people: I'm testing RELENG_7 ( 7.2-PRERELEASE, actualized and built today) and I'm fouding some issues with lagg(4). My problem happens when I disconnect the cable from bge0. The packets are sending by wpi0 but they don't income back. See tcpdump log above: # tcpdump -i bge0 host 192.168.1.1 tcpdump: WARNING: bge0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bge0, link-type EN10MB (Ethernet), capture size 96 bytes 19:29:19.608811 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 3, length 64 19:29:19.610150 IP 192.168.1.1 > 192.168.1.60: ICMP echo reply, id 45355, seq 3, length 64 19:29:20.609807 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 4, length 64 19:29:20.610948 IP 192.168.1.1 > 192.168.1.60: ICMP echo reply, id 45355, seq 4, length 64 19:29:21.597787 arp who-has 192.168.1.60 tell 192.168.1.1 19:29:21.597811 arp reply 192.168.1.60 is-at 00:19:b9:79:f0:af (oui Unknown) 19:29:21.610813 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 5, length 64 19:29:21.611992 IP 192.168.1.1 > 192.168.1.60: ICMP echo reply, id 45355, seq 5, length 64 19:29:22.611815 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 6, length 64 19:29:22.612982 IP 192.168.1.1 > 192.168.1.60: ICMP echo reply, id 45355, seq 6, length 64 19:29:23.612819 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 7, length 64 19:29:23.613947 IP 192.168.1.1 > 192.168.1.60: ICMP echo reply, id 45355, seq 7, length 64 19:29:24.613823 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 8, length 64 19:29:24.614983 IP 192.168.1.1 > 192.168.1.60: ICMP echo reply, id 45355, seq 8, length 64 19:29:25.614823 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 9, length 64 19:29:25.615953 IP 192.168.1.1 > 192.168.1.60: ICMP echo reply, id 45355, seq 9, length 64 19:29:26.615830 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 10, length 64 19:29:26.616991 IP 192.168.1.1 > 192.168.1.60: ICMP echo reply, id 45355, seq 10, length 64 19:29:27.616826 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 11, length 64 19:29:27.618165 IP 192.168.1.1 > 192.168.1.60: ICMP echo reply, id 45355, seq 11, length 64 19:29:28.617826 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 12, length 64 19:29:28.618951 IP 192.168.1.1 > 192.168.1.60: ICMP echo reply, id 45355, seq 12, length 64 19:29:29.618828 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 13, length 64 19:29:29.620001 IP 192.168.1.1 > 192.168.1.60: ICMP echo reply, id 45355, seq 13, length 64 19:29:30.619830 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 14, length 64 19:29:30.620996 IP 192.168.1.1 > 192.168.1.60: ICMP echo reply, id 45355, seq 14, length 64 19:29:31.620840 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 15, length 64 19:29:31.622008 IP 192.168.1.1 > 192.168.1.60: ICMP echo reply, id 45355, seq 15, length 64 19:29:32.621837 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 16, length 64 19:29:32.623013 IP 192.168.1.1 > 192.168.1.60: ICMP echo reply, id 45355, seq 16, length 64 19:29:33.622838 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 17, length 64 19:29:33.624002 IP 192.168.1.1 > 192.168.1.60: ICMP echo reply, id 45355, seq 17, length 64 19:29:34.623841 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 18, length 64 19:29:34.625012 IP 192.168.1.1 > 192.168.1.60: ICMP echo reply, id 45355, seq 18, length 64 19:29:35.624842 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 19, length 64 19:29:35.625977 IP 192.168.1.1 > 192.168.1.60: ICMP echo reply, id 45355, seq 19, length 64 Now I disconnect the cable from bge0 and one second after We see at other tcpdump log, that packets are become sending by wpi0 but, without reply. # tcpdump -i wpi0 host 192.168.1.1 tcpdump: WARNING: wpi0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wpi0, link-type EN10MB (Ethernet), capture size 96 bytes 19:29:36.625849 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 20, length 64 19:29:37.626843 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 21, length 64 19:29:38.627845 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 22, length 64 19:29:39.628846 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 23, length 64 19:29:40.629848 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 24, length 64 19:29:41.630861 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 25, length 64 19:29:42.631854 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 26, length 64 19:29:43.632858 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 27, length 64 19:29:44.633860 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 28, length 64 19:29:45.634860 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 29, length 64 19:29:46.635866 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 30, length 64 19:29:47.639367 IP 192.168.1.60 > 192.168.1.1: ICMP echo request, id 45355, seq 31, length 64 Here is my configurations: # route get 192.168.1.1 route to: 192.168.1.1 destination: 192.168.1.1 interface: lagg0 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1500 1095 # ifconfig wpi0 wpi0: flags=8843 metric 0 mtu 1500 ether 00:19:b9:79:f0:af media: IEEE 802.11 Wireless Ethernet autoselect (DS/1Mbps) status: associated ssid triarius-wifi channel 6 (2437 Mhz 11g) bssid 00:18:39:39:5b:0f authmode OPEN privacy OFF txpower 50 bmiss 7 scanvalid 60 protmode CTS lagg: laggdev lagg0 # ifconfig bge0 bge0: flags=8843 metric 0 mtu 1500 options=9b ether 00:19:b9:79:f0:af media: Ethernet autoselect (none) status: no carrier lagg: laggdev lagg0 # ifconfig lagg0 # When I disconnect bge0, wpi0 come to ACTIVE mode. lagg0: flags=8843 metric 0 mtu 1500 ether 00:19:b9:79:f0:af inet 192.168.1.60 netmask 0xffffffc0 broadcast 192.168.1.63 media: Ethernet autoselect status: active laggproto failover laggport: wpi0 flags=4 laggport: bge0 flags=1 # ifconfig lagg0 # When I connect bge0 back, bge0 comes to ACTIVE mode. lagg0: flags=8843 metric 0 mtu 1500 ether 00:19:b9:79:f0:af inet 192.168.1.60 netmask 0xffffffc0 broadcast 192.168.1.63 media: Ethernet autoselect status: active laggproto failover laggport: wpi0 flags=0<> laggport: bge0 flags=5 Could you help me with this issue? Thanks, Vinicius Abrahao From owner-freebsd-net@FreeBSD.ORG Thu Apr 30 07:04:07 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 035481065670 for ; Thu, 30 Apr 2009 07:04:07 +0000 (UTC) (envelope-from miki.bsd@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 613F88FC0C for ; Thu, 30 Apr 2009 07:04:06 +0000 (UTC) (envelope-from miki.bsd@gmail.com) Received: by ewy19 with SMTP id 19so1652065ewy.43 for ; Thu, 30 Apr 2009 00:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=TDuUGbVbePWTbKM1cijmkjQH+dOeFgGvaObaKkONKrM=; b=AJGwLIqgFei9cs51FBtqBXHne7J3///djxvwN+sMnHbsJ1MM33FStQboQ3Eh8dUbLc Su/Y+QfL+rn18ZT4WqhMoYUWR7Q9vgDZJSlji2VHiiP1LufxcCj65QgVY7gHWQY0Knok +WyHOBLssERgalXjV/aiRQlSQWxWojPqTQ1UQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xFhBFpFVclwtokVN5Lz/Dfq1p8ECw4m6rYBOH54YOxckpkvltG1Ly5fJD7jMpbkeHq TZTC1tEWGdtmqCGxV2Zy7g7+IdhfqZnj9vyRli6Y6319rQuGblcvzzEovm17Vc8VFVL6 6RJes3PxwU3EGZe06mSNxidWIaAujCOEqKZ80= MIME-Version: 1.0 Received: by 10.216.3.196 with SMTP id 46mr316460weh.205.1241075045377; Thu, 30 Apr 2009 00:04:05 -0700 (PDT) In-Reply-To: <20090429.141002.-720655694.imp@bsdimp.com> References: <261c29700904282342q62828573hf2631a7f79a10581@mail.gmail.com> <20090429.141002.-720655694.imp@bsdimp.com> Date: Thu, 30 Apr 2009 09:04:05 +0200 Message-ID: <261c29700904300004k4bc02635m2729a0a54c09c135@mail.gmail.com> From: Miki To: "M. Warner Losh" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: [ed] link state constantly going down and up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 07:04:07 -0000 2009/4/29 M. Warner Losh > : I have a problem with a D-Link DFE-670TXD which is handled by if_ed : > : the link state is constantly going down and up : > : Apr 28 14:21:33 iut-mir-o kernel: ed0: link state changed to DOWN > : Apr 28 14:21:35 iut-mir-o kernel: ed0: link state changed to UP > ... > : the problem appear with the following commit : > : SVN rev 190643 on 2009-04-02 16:58:45Z by imp (CVS rev 1.126) > : I do not see any link state change if I revert the commit. > > Doh! > > I needed to force auto negotiation for other cards to work. Let me > see if I can dig up the DFE-670TXD and go from there... Are you also > seeing really horrible network performance as well? Do you see this > only under load, or just at idle? > > Warner > Yes network performance suffers from this. The problem only appears under load but not when idle. Mikael From owner-freebsd-net@FreeBSD.ORG Thu Apr 30 07:22:11 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C053106564A for ; Thu, 30 Apr 2009 07:22:11 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 1C7B38FC13 for ; Thu, 30 Apr 2009 07:22:11 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n3U7HaGY004459; Thu, 30 Apr 2009 01:17:37 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 30 Apr 2009 01:17:38 -0600 (MDT) Message-Id: <20090430.011738.1617886960.imp@bsdimp.com> To: miki.bsd@gmail.com From: "M. Warner Losh" In-Reply-To: <261c29700904300004k4bc02635m2729a0a54c09c135@mail.gmail.com> References: <261c29700904282342q62828573hf2631a7f79a10581@mail.gmail.com> <20090429.141002.-720655694.imp@bsdimp.com> <261c29700904300004k4bc02635m2729a0a54c09c135@mail.gmail.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: [ed] link state constantly going down and up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 07:22:11 -0000 In message: <261c29700904300004k4bc02635m2729a0a54c09c135@mail.gmail.com> Miki writes: : 2009/4/29 M. Warner Losh : : > : I have a problem with a D-Link DFE-670TXD which is handled by if_ed : : > : the link state is constantly going down and up : : > : Apr 28 14:21:33 iut-mir-o kernel: ed0: link state changed to DOWN : > : Apr 28 14:21:35 iut-mir-o kernel: ed0: link state changed to UP : > ... : > : the problem appear with the following commit : : > : SVN rev 190643 on 2009-04-02 16:58:45Z by imp (CVS rev 1.126) : > : I do not see any link state change if I revert the commit. : > : > Doh! : > : > I needed to force auto negotiation for other cards to work. Let me : > see if I can dig up the DFE-670TXD and go from there... Are you also : > seeing really horrible network performance as well? Do you see this : > only under load, or just at idle? : > : > Warner : > : : Yes network performance suffers from this. The problem only appears under : load : but not when idle. Thanks. I'll try to reproduce it here. I noticed this on one of the cards, but had trouble reproducing it, but I'll try harder. Warner From owner-freebsd-net@FreeBSD.ORG Thu Apr 30 07:29:55 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84C5D106566C for ; Thu, 30 Apr 2009 07:29:55 +0000 (UTC) (envelope-from miki.bsd@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id 0E9678FC13 for ; Thu, 30 Apr 2009 07:29:54 +0000 (UTC) (envelope-from miki.bsd@gmail.com) Received: by ey-out-2122.google.com with SMTP id 9so423723eyd.7 for ; Thu, 30 Apr 2009 00:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=tZuDXp1Un6XenNPfJuqC1wVDXg9f1m7CZHHNzxY2QkI=; b=C06o7rINBg5M4hlVdU7R8IORiq/qDdSb9OELOMVEaVGqkG93N4SZj3B0WwiNrz1bML vGfszG0sn0oXigEYn1mAovbBrUFewmM9cnecbax5mz+pdeL2IkhrZMcKBfk/buM3jlrA cV5IjkgAmgJe9ej0Gw2hgcYj2IoBLGf5YEHyM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=g4zrjhNXWSQpsKXVBJoVzHSR7mv2lz0XOSXoKP+3NHYOzkUwfrzQyuePFJ22WO8dO7 i/0pc1jzG64k5eCqt+N2/IOX8eiataHE4IatO16LxKur23jWAwovotVSawK0E6QK2qR5 h0De1cHopoqEPEFokOIjgsuKbOsQZCGC1H268= MIME-Version: 1.0 Received: by 10.216.71.196 with SMTP id r46mr337648wed.54.1241076593892; Thu, 30 Apr 2009 00:29:53 -0700 (PDT) In-Reply-To: <20090430.011738.1617886960.imp@bsdimp.com> References: <261c29700904282342q62828573hf2631a7f79a10581@mail.gmail.com> <20090429.141002.-720655694.imp@bsdimp.com> <261c29700904300004k4bc02635m2729a0a54c09c135@mail.gmail.com> <20090430.011738.1617886960.imp@bsdimp.com> Date: Thu, 30 Apr 2009 09:29:53 +0200 Message-ID: <261c29700904300029s6757d39ei86fbf69ef816fa48@mail.gmail.com> From: Miki To: "M. Warner Losh" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: [ed] link state constantly going down and up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 07:29:55 -0000 2009/4/30 M. Warner Losh > In message: <261c29700904300004k4bc02635m2729a0a54c09c135@mail.gmail.com> > Miki writes: > : 2009/4/29 M. Warner Losh > : > : > : I have a problem with a D-Link DFE-670TXD which is handled by if_ed : > : > : the link state is constantly going down and up : > : > : Apr 28 14:21:33 iut-mir-o kernel: ed0: link state changed to DOWN > : > : Apr 28 14:21:35 iut-mir-o kernel: ed0: link state changed to UP > : > ... > : > : the problem appear with the following commit : > : > : SVN rev 190643 on 2009-04-02 16:58:45Z by imp (CVS rev 1.126) > : > : I do not see any link state change if I revert the commit. > : > > : > Doh! > : > > : > I needed to force auto negotiation for other cards to work. Let me > : > see if I can dig up the DFE-670TXD and go from there... Are you also > : > seeing really horrible network performance as well? Do you see this > : > only under load, or just at idle? > : > > : > Warner > : > > : > : Yes network performance suffers from this. The problem only appears under > : load > : but not when idle. > > Thanks. I'll try to reproduce it here. I noticed this on one of the > cards, but had trouble reproducing it, but I'll try harder. > > Warner > I can easily reproduce this by downloading an ISO image via ftp and doing a checkout of a subversion repository Mikael From owner-freebsd-net@FreeBSD.ORG Thu Apr 30 07:38:35 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88F8110656C0 for ; Thu, 30 Apr 2009 07:38:35 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 47E688FC23 for ; Thu, 30 Apr 2009 07:38:35 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n3U7a8Zn004758; Thu, 30 Apr 2009 01:36:08 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 30 Apr 2009 01:36:10 -0600 (MDT) Message-Id: <20090430.013610.439575052.imp@bsdimp.com> To: miki.bsd@gmail.com From: "M. Warner Losh" In-Reply-To: <261c29700904300029s6757d39ei86fbf69ef816fa48@mail.gmail.com> References: <261c29700904300004k4bc02635m2729a0a54c09c135@mail.gmail.com> <20090430.011738.1617886960.imp@bsdimp.com> <261c29700904300029s6757d39ei86fbf69ef816fa48@mail.gmail.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: [ed] link state constantly going down and up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 07:38:35 -0000 In message: <261c29700904300029s6757d39ei86fbf69ef816fa48@mail.gmail.com> Miki writes: : 2009/4/30 M. Warner Losh : : > In message: <261c29700904300004k4bc02635m2729a0a54c09c135@mail.gmail.com> : > Miki writes: : > : 2009/4/29 M. Warner Losh : > : : > : > : I have a problem with a D-Link DFE-670TXD which is handled by if_ed : : > : > : the link state is constantly going down and up : : > : > : Apr 28 14:21:33 iut-mir-o kernel: ed0: link state changed to DOWN : > : > : Apr 28 14:21:35 iut-mir-o kernel: ed0: link state changed to UP : > : > ... : > : > : the problem appear with the following commit : : > : > : SVN rev 190643 on 2009-04-02 16:58:45Z by imp (CVS rev 1.126) : > : > : I do not see any link state change if I revert the commit. : > : > : > : > Doh! : > : > : > : > I needed to force auto negotiation for other cards to work. Let me : > : > see if I can dig up the DFE-670TXD and go from there... Are you also : > : > seeing really horrible network performance as well? Do you see this : > : > only under load, or just at idle? : > : > : > : > Warner : > : > : > : : > : Yes network performance suffers from this. The problem only appears under : > : load : > : but not when idle. : > : > Thanks. I'll try to reproduce it here. I noticed this on one of the : > cards, but had trouble reproducing it, but I'll try harder. : > : > Warner : > : : I can easily reproduce this by downloading an ISO image via ftp : and doing a checkout of a subversion repository OK. I'll try that. Do you know if you are able to trigger it with ttcp too? That's where I saw the odd symptoms before... Warner From owner-freebsd-net@FreeBSD.ORG Thu Apr 30 11:57:04 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED7E1106566B for ; Thu, 30 Apr 2009 11:57:04 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-qy0-f105.google.com (mail-qy0-f105.google.com [209.85.221.105]) by mx1.freebsd.org (Postfix) with ESMTP id 929D98FC12 for ; Thu, 30 Apr 2009 11:57:04 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by qyk3 with SMTP id 3so3602752qyk.3 for ; Thu, 30 Apr 2009 04:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-pgp-agent:content-transfer-encoding:x-mailer; bh=C4RtAM6CMDMthKheqUzlLXIXFb8LTC0tr3o40lAeu5I=; b=YDvZjxN5ykWI77iRTVC0QZMpvn1LMlDcSmQuCG/1ydY1uJHPdiC0M7kCbZm8YpPent 7jcC1Qu3JAWFVYDWMwtED2HHh7cYcCabqHbw1fjKbLo0Z3lnamlb3pfV48FOyljm+Uzm fy/hkiQT/MioqUsExXwgDQ5ClhC26CbPj4/hI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type:mime-version:subject :date:references:x-pgp-agent:content-transfer-encoding:x-mailer; b=MoQvDYKQFuWYYEKEz9CW/Se7pXn8asbVTgmNVgEkBE+nC89awM80ImI33dF4msvZh1 nDVEEG2dj5nXC+b9Mk4EQoUbFeQkPof8Op5xk+amstMG498fypaWqGU7k2zOOEDiUmjT MqawWHYj+rVrfcKSnE+WUmwQWIzWXpOYhSvNc= Received: by 10.224.67.203 with SMTP id s11mr1657228qai.290.1241092623728; Thu, 30 Apr 2009 04:57:03 -0700 (PDT) Received: from ndenev.cmotd.com (blah.sun-fish.com [217.18.249.150]) by mx.google.com with ESMTPS id 4sm6682569yxd.29.2009.04.30.04.57.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Apr 2009 04:57:02 -0700 (PDT) Message-Id: From: Nikolay Denev To: freebsd-net@freebsd.org In-Reply-To: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-491-792384474" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 30 Apr 2009 14:56:29 +0300 References: <5E915E92-2B82-4331-9493-739568CC6E8C@gmail.com> <2e77fc10904290733m4858172ayd96654f3a9a3a8a@mail.gmail.com> X-Pgp-Agent: GPGMail 1.2.0 (v56) Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.930.3) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: bce(4) sees all incoming frames as 2026 bytes in length X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 11:57:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-491-792384474 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Apr 29, 2009, at 7:04 PM, pluknet wrote: > 2009/4/29 Niki Denev : > >> bce1: mem >> 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci3 >> bce1: Ethernet address: 00:22:19:xx:xx:xx >> bce1: [ITHREAD] >> bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C >> (0x04040105); Flags( MFW MSI ) >> >> bce1: flags=8843 metric 0 >> mtu 1500 >> >> options >> = >> 1bb >> ether 00:22:19:xx:xx:xx >> inet 10.18.2.1 netmask 0xffffff00 broadcast 10.18.2.255 >> media: Ethernet autoselect (1000baseTX ) >> status: active >> >> And here is a tcpdump that shows the problem : >> >> 16:27:32.593808 00:22:19:yy:yy:yy > 00:22:19:xx:xx:xx, ethertype IPv4 >> (0x0800), length 2026: (tos 0x0, ttl 64, id 45347, offset 0, flags >> [none], proto ICMP (1), length 84) 10.18.2.2 > 10.18.2.1: ICMP echo >> request, id 13578, seq 36, length 64 >> 16:27:32.593817 00:22:19:xx:xx:xx > 00:22:19:yy:yy:yy, ethertype IPv4 >> (0x0800), length 98: (tos 0x0, ttl 64, id 18415, offset 0, flags >> [none], proto ICMP (1), length 84) 10.18.2.1 > 10.18.2.2: ICMP echo >> reply, id 13578, seq 36, length 64 > > Ok, now I see. A link level length is 2026 for me too for some sort > of packets > (in opposite to proto's len where all is ok). > > Mine nic is > (same as yours). > > Looks like a regression. > I just also tested 7.1-R and it shows expected LL-length. > > > -- > wbr, > pluknet I think I got it. It seems that the mbuf fields m_pkthdr.len and m_len are not updated to the real packet size pkt_len. Well, actually they are updated, but only if we have ZERO_COPY_SOCKETS defined. After I added this : m0->m_pkthdr.len = m0->m_len = pkt_len; at about line 5930 in if_bce.c, the frame length reported by tcpdump seems correct. P.S.: I guess this could be the cause for the lagg(4) over bce(4) problems too? P.S.2: This fix will probably break the ZERO_COPY_SOCKETS case, but should be fairly easy to make it a "proper" fix. Regards, Niki Denev --Apple-Mail-491-792384474 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (Darwin) iEYEARECAAYFAkn5kfAACgkQHNAJ/fLbfrnF6QCcDXOXdWvfpqBIrCIa1ToQjfQy JeoAn0dtODtxQeKczU7rHoFOiENO7Tfj =kIvo -----END PGP SIGNATURE----- --Apple-Mail-491-792384474-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 30 12:04:25 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C72B410656CE for ; Thu, 30 Apr 2009 12:04:25 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-qy0-f105.google.com (mail-qy0-f105.google.com [209.85.221.105]) by mx1.freebsd.org (Postfix) with ESMTP id 687A58FC13 for ; Thu, 30 Apr 2009 12:04:25 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by qyk3 with SMTP id 3so3609020qyk.3 for ; Thu, 30 Apr 2009 05:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-pgp-agent:content-transfer-encoding:x-mailer; bh=diUw8M4GrFPazPM+ylLNdaFDVpSeZfYQvcE0/TKZKOE=; b=PxzgyGwIhCWTNk0fGQseYswT1F+BIbM3VBd7f5As68QGmeWVUPt7hy70cJIdoKXWQ4 wRbbAWgiqYNFyF/J9jiyWfmL6h17taNd7GApJv/fTV7Cs+Y955oFpzCLC5HydzHR9sOj 1F1kgpnS+UHYs7oLpZzTfqF5ApwLLUmqXO6DQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type:mime-version:subject :date:references:x-pgp-agent:content-transfer-encoding:x-mailer; b=PvXz7pEHPP+wZhcXRvC7ZC9uaM+zsvqywXp2ahBkVxZ/6shZF7ajj+HU7jyslKiirw btL4Ipbk0Zl6AhLygQF1ay4Dq3P26f4gfQSqLwvlp+7Jc7SJbN2cb2osgTcriaGQXPuF RsE9qyOdluaJpD7owxITV3l/UB7whPcJC4Ge4= Received: by 10.224.47.16 with SMTP id l16mr1681475qaf.109.1241093064854; Thu, 30 Apr 2009 05:04:24 -0700 (PDT) Received: from ndenev.cmotd.com (blah.sun-fish.com [217.18.249.150]) by mx.google.com with ESMTPS id 30sm6608450yxk.6.2009.04.30.05.04.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Apr 2009 05:04:24 -0700 (PDT) Message-Id: <5FD800FE-23E5-482E-8491-564FE52D91D5@gmail.com> From: Nikolay Denev To: freebsd-net@freebsd.org In-Reply-To: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-495-792854591" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 30 Apr 2009 15:04:19 +0300 References: <5E915E92-2B82-4331-9493-739568CC6E8C@gmail.com> <2e77fc10904290733m4858172ayd96654f3a9a3a8a@mail.gmail.com> X-Pgp-Agent: GPGMail 1.2.0 (v56) Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.930.3) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: bce(4) and lagg(4) fix [was: bce(4) sees all incoming frames as 2026 bytes in length] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 12:04:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-495-792854591 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Apr 30, 2009, at 2:56 PM, Nikolay Denev wrote: > On Apr 29, 2009, at 7:04 PM, pluknet wrote: > >> 2009/4/29 Niki Denev : >> >>> bce1: mem >>> 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci3 >>> bce1: Ethernet address: 00:22:19:xx:xx:xx >>> bce1: [ITHREAD] >>> bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C >>> (0x04040105); Flags( MFW MSI ) >>> >>> bce1: flags=8843 metric 0 >>> mtu 1500 >>> >>> options >>> = >>> 1bb >>> >>> ether 00:22:19:xx:xx:xx >>> inet 10.18.2.1 netmask 0xffffff00 broadcast 10.18.2.255 >>> media: Ethernet autoselect (1000baseTX ) >>> status: active >>> >>> And here is a tcpdump that shows the problem : >>> >>> 16:27:32.593808 00:22:19:yy:yy:yy > 00:22:19:xx:xx:xx, ethertype >>> IPv4 >>> (0x0800), length 2026: (tos 0x0, ttl 64, id 45347, offset 0, flags >>> [none], proto ICMP (1), length 84) 10.18.2.2 > 10.18.2.1: ICMP echo >>> request, id 13578, seq 36, length 64 >>> 16:27:32.593817 00:22:19:xx:xx:xx > 00:22:19:yy:yy:yy, ethertype >>> IPv4 >>> (0x0800), length 98: (tos 0x0, ttl 64, id 18415, offset 0, flags >>> [none], proto ICMP (1), length 84) 10.18.2.1 > 10.18.2.2: ICMP echo >>> reply, id 13578, seq 36, length 64 >> >> Ok, now I see. A link level length is 2026 for me too for some sort >> of packets >> (in opposite to proto's len where all is ok). >> >> Mine nic is >> (same as yours). >> >> Looks like a regression. >> I just also tested 7.1-R and it shows expected LL-length. >> >> >> -- >> wbr, >> pluknet > > > I think I got it. > > It seems that the mbuf fields m_pkthdr.len and m_len are not updated > to the real packet size pkt_len. > Well, actually they are updated, but only if we have > ZERO_COPY_SOCKETS defined. > > After I added this : > > m0->m_pkthdr.len = m0->m_len = pkt_len; > > at about line 5930 in if_bce.c, the frame length reported by tcpdump > seems correct. > > P.S.: I guess this could be the cause for the lagg(4) over bce(4) > problems too? > > P.S.2: This fix will probably break the ZERO_COPY_SOCKETS case, but > should be fairly easy to make it a "proper" fix. > > Regards, > Niki Denev > I can confirm that with this fix I was able to create lagg(4) interface in "failover" mode with only one member, a bce(4) interface, and it seems to work OK. Regards, Niki Denev --Apple-Mail-495-792854591 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (Darwin) iEYEARECAAYFAkn5k8MACgkQHNAJ/fLbfrkOjgCeJr2oVcHvgZPcyJ+O+M+rlRj1 nEkAnAnZke4evdELE8LNUvnZFN0b2W2G =iMjj -----END PGP SIGNATURE----- --Apple-Mail-495-792854591-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 30 12:38:25 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D1021065670 for ; Thu, 30 Apr 2009 12:38:25 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id 104308FC17 for ; Thu, 30 Apr 2009 12:38:24 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by qw-out-2122.google.com with SMTP id 3so1330595qwe.7 for ; Thu, 30 Apr 2009 05:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-pgp-agent:content-transfer-encoding:x-mailer; bh=27nyhyxZ/H1VWJQvR22JRsws6ivJgbqUIuYJA95tyZg=; b=B7jph9t98xa7H9djyK3cfJT+Zs1ier8m7CwO1loboWGcQ0D1lYK6VxUVisoPF/Fx2S b9JbBg65GedOQSOHSLS9NE/qIyss3SgS12/oYw8QC+MxDfstnXXywwOaDEFCvb+tSMdu OG6oqwxNPWDD6Kd0i3/Ob0YNmKK8/icP7Kv2A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type:mime-version:subject :date:references:x-pgp-agent:content-transfer-encoding:x-mailer; b=hq87q+MUXCxv765HRUg1RgqqmTtDP/pQK41PwvIpFqIKfwzZCI1KjSQUelGdT9knpH vaaLbOFXXP4OU2ZrQp5JktnbO+886BIJzzCIwHKxMfixkEQzWAk2gHmcixAuEIwLYGpT ZNfgz06OurlCawP3nthG+vESgUnd/Jv7eiIJg= Received: by 10.229.84.213 with SMTP id k21mr1132908qcl.19.1241095104396; Thu, 30 Apr 2009 05:38:24 -0700 (PDT) Received: from ndenev.cmotd.com (blah.sun-fish.com [217.18.249.150]) by mx.google.com with ESMTPS id 9sm6776785yxs.3.2009.04.30.05.38.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Apr 2009 05:38:21 -0700 (PDT) Message-Id: From: Nikolay Denev To: freebsd-net@freebsd.org In-Reply-To: <5FD800FE-23E5-482E-8491-564FE52D91D5@gmail.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-499-794893110" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 30 Apr 2009 15:38:17 +0300 References: <5E915E92-2B82-4331-9493-739568CC6E8C@gmail.com> <2e77fc10904290733m4858172ayd96654f3a9a3a8a@mail.gmail.com> <5FD800FE-23E5-482E-8491-564FE52D91D5@gmail.com> X-Pgp-Agent: GPGMail 1.2.0 (v56) Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.930.3) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: bce(4) and lagg(4) fix [was: bce(4) sees all incoming frames as 2026 bytes in length] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 12:38:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-499-794893110 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Apr 30, 2009, at 3:04 PM, Nikolay Denev wrote: [snip] >> >> I think I got it. >> >> It seems that the mbuf fields m_pkthdr.len and m_len are not >> updated to the real packet size pkt_len. >> Well, actually they are updated, but only if we have >> ZERO_COPY_SOCKETS defined. >> >> After I added this : >> >> m0->m_pkthdr.len = m0->m_len = pkt_len; >> >> at about line 5930 in if_bce.c, the frame length reported by >> tcpdump seems correct. >> >> P.S.: I guess this could be the cause for the lagg(4) over bce(4) >> problems too? >> >> P.S.2: This fix will probably break the ZERO_COPY_SOCKETS case, but >> should be fairly easy to make it a "proper" fix. >> >> Regards, >> Niki Denev >> > > I can confirm that with this fix I was able to create lagg(4) > interface in "failover" mode with only one member, a bce(4) > interface, and it seems to work OK. > > Here is the patch : --- sys/dev/bce/if_bce.c.orig 2009-04-30 14:06:54.000000000 +0200 +++ sys/dev/bce/if_bce.c 2009-04-30 14:11:32.000000000 +0200 @@ -5926,6 +5926,11 @@ goto bce_rx_int_next_rx; } +#ifndef ZERO_COPY_SOCKETS + /* Adjust the packet length to match the received data. */ + m0->m_pkthdr.len = m0->m_len = pkt_len; +#endif + /* Send the packet to the appropriate interface. */ m0->m_pkthdr.rcvif = ifp; Regards, Niki Denev --Apple-Mail-499-794893110 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (Darwin) iEYEARECAAYFAkn5m7oACgkQHNAJ/fLbfrn2MgCgokM3YUnI+Bf4p5AUgzppwaP7 nzYAn1sJ6C4PLxNrFvTaM6xcnNZ2/COv =SuNk -----END PGP SIGNATURE----- --Apple-Mail-499-794893110-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 30 13:11:29 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E34D810656B7 for ; Thu, 30 Apr 2009 13:11:28 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 5EC3C8FC08 for ; Thu, 30 Apr 2009 13:11:28 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by bwz9 with SMTP id 9so1776019bwz.43 for ; Thu, 30 Apr 2009 06:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5RdD2I0HEMdJ6OO/PBFjVwGgp4Za1ghbbdsJUDKI/Zg=; b=g5LdFs9NffJwU+WAeoNEroMtmbGczOUdYSLE5foVpzAUrefxj8RgR6V+HgaN99tGcu qAMFWkQ5KEUTaHiPtgBLC+8xblC/mucxdkS6oq/rEvdzuZUkS8qaAO+yjMxoIi78bWyx lALSNHomQQmsgn6dtv6YXTpsjcX7C7EA73Xrk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oXbqBy765jK3i4a+W4QCtO6Ix3RG4fGrikuyRRXZBw0yffdw3ZmvUz1jhdS/6YmuUN 4HG7yiOzHhUw5VaNhxRVQwgF2rVcIHFFuNMAr2RGR1LcR+rFVslZpIGBCq1E8aMc5c0L dZwXqbtM6DoKHzhDaJ0YnO7qFAlMLRCCVu5WE= MIME-Version: 1.0 Received: by 10.204.55.142 with SMTP id u14mr1449966bkg.121.1241097087299; Thu, 30 Apr 2009 06:11:27 -0700 (PDT) In-Reply-To: References: <5E915E92-2B82-4331-9493-739568CC6E8C@gmail.com> <2e77fc10904290733m4858172ayd96654f3a9a3a8a@mail.gmail.com> Date: Thu, 30 Apr 2009 17:11:27 +0400 Message-ID: From: pluknet To: Nikolay Denev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: bce(4) sees all incoming frames as 2026 bytes in length X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 13:11:29 -0000 2009/4/30 Nikolay Denev : > On Apr 29, 2009, at 7:04 PM, pluknet wrote: > >> 2009/4/29 Niki Denev : >> >>> bce1: mem >>> 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci3 >>> bce1: Ethernet address: 00:22:19:xx:xx:xx >>> bce1: [ITHREAD] >>> bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C >>> (0x04040105); Flags( MFW MSI ) >>> >>> bce1: flags=3D8843 metric 0 mtu >>> 1500 >>> >>> =A0options=3D1bb >>> =A0 =A0 =A0ether 00:22:19:xx:xx:xx >>> =A0 =A0 =A0inet 10.18.2.1 netmask 0xffffff00 broadcast 10.18.2.255 >>> =A0 =A0 =A0media: Ethernet autoselect (1000baseTX ) >>> =A0 =A0 =A0status: active >>> >>> And here is a tcpdump that shows the problem : >>> >>> 16:27:32.593808 00:22:19:yy:yy:yy > 00:22:19:xx:xx:xx, ethertype IPv4 >>> (0x0800), length 2026: (tos 0x0, ttl 64, id 45347, offset 0, flags >>> [none], proto ICMP (1), length 84) 10.18.2.2 > 10.18.2.1: ICMP echo >>> request, id 13578, seq 36, length 64 >>> 16:27:32.593817 00:22:19:xx:xx:xx > 00:22:19:yy:yy:yy, ethertype IPv4 >>> (0x0800), length 98: (tos 0x0, ttl 64, id 18415, offset 0, flags >>> [none], proto ICMP (1), length 84) 10.18.2.1 > 10.18.2.2: ICMP echo >>> reply, id 13578, seq 36, length 64 >> >> Ok, now I see. A link level length is 2026 for me too for some sort of >> packets >> (in opposite to proto's len where all is ok). >> >> Mine nic is >> (same as yours). >> >> Looks like a regression. >> I just also tested 7.1-R and it shows expected LL-length. >> >> >> -- >> wbr, >> pluknet > > > I think I got it. > > It seems that the mbuf fields m_pkthdr.len and m_len are not updated to t= he > real packet size pkt_len. > Well, actually they are updated, but only if we have ZERO_COPY_SOCKETS > defined. > > After I added this : > > =A0 m0->m_pkthdr.len =3D m0->m_len =3D pkt_len; > > at about line 5930 in if_bce.c, the frame length reported by tcpdump seem= s > correct. > JFYI In 7.1-R driver version there was length updating and it seems to be lost in 7.2-R. /* Skip over the l2_fhdr when passing the data up t= he s m_adj(m, sizeof(struct l2_fhdr) + ETHER_ALIGN); /* Adjust the packet length to match the received d= ata. m->m_pkthdr.len =3D m->m_len =3D len; /* Send the packet to the appropriate interface. */ m->m_pkthdr.rcvif =3D ifp; > P.S.: I guess this could be the cause for the lagg(4) over bce(4) problem= s > too? > > P.S.2: This fix will probably break the ZERO_COPY_SOCKETS case, but shoul= d > be fairly easy to make it a "proper" fix. At least it can be ifndef'ed out in ZERO_COPY_SOCKETS case. @@ -5926,6 +5926,11 @@ goto bce_rx_int_next_rx; } +#ifndef ZERO_COPY_SOCKETS + /* Set the total packet length. */ + m0->m_pkthdr.len =3D m0->m_len =3D pkt_len; +#endif + /* Send the packet to the appropriate interface. */ m0->m_pkthdr.rcvif =3D ifp; -eop- --=20 wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Thu Apr 30 13:19:34 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 064C11065670 for ; Thu, 30 Apr 2009 13:19:34 +0000 (UTC) (envelope-from miki.bsd@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 618F08FC0C for ; Thu, 30 Apr 2009 13:19:32 +0000 (UTC) (envelope-from miki.bsd@gmail.com) Received: by ewy19 with SMTP id 19so1818073ewy.43 for ; Thu, 30 Apr 2009 06:19:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=qcLPwXrCWMcRgcjYfXIPjmIcG7wySYzP2Urt4nOuptU=; b=u1ze6Fc4R9Dl6pojxYRsFbppzekLAKlW2a4kgqDhTzUd0cGQLIqHsTBFwftV6fa/nM /Cesztt0slTXmyR49ifWy4ToIBnKySl7WNfi5A5DKJZyRHfTMjfovlBo7m4cgaj3+cU/ zfh1HfTi7lzGisGCbcJjOJJMqW8QgQ4k8ZDfQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bNP1p7IC2j/sE5S4bSKgE9L4lKklvTeRpDJiBeL9sboHGGL5CPq4FLWKWqj0eiNuwz rH0/Tnok6Oy7cEPTeZA6K5k/fxmh05xdu3MfocXlnoVdNAtidg891LHNzyIrHgjweflm H3xfVqiaq1prJTj/RmBQs8KBuxu0sM/2fkG50= MIME-Version: 1.0 Received: by 10.216.35.69 with SMTP id t47mr474894wea.221.1241097572198; Thu, 30 Apr 2009 06:19:32 -0700 (PDT) In-Reply-To: <20090430.013610.439575052.imp@bsdimp.com> References: <261c29700904300004k4bc02635m2729a0a54c09c135@mail.gmail.com> <20090430.011738.1617886960.imp@bsdimp.com> <261c29700904300029s6757d39ei86fbf69ef816fa48@mail.gmail.com> <20090430.013610.439575052.imp@bsdimp.com> Date: Thu, 30 Apr 2009 15:19:32 +0200 Message-ID: <261c29700904300619l3f2e2d68s580f95a3c673fddf@mail.gmail.com> From: Miki To: "M. Warner Losh" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: [ed] link state constantly going down and up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 13:19:34 -0000 2009/4/30 M. Warner Losh > In message: <261c29700904300029s6757d39ei86fbf69ef816fa48@mail.gmail.com> > Miki writes: > : 2009/4/30 M. Warner Losh > : > : > In message: < > 261c29700904300004k4bc02635m2729a0a54c09c135@mail.gmail.com> > : > Miki writes: > : > : 2009/4/29 M. Warner Losh > : > : > : > : > : I have a problem with a D-Link DFE-670TXD which is handled by > if_ed : > : > : > : the link state is constantly going down and up : > : > : > : Apr 28 14:21:33 iut-mir-o kernel: ed0: link state changed to DOWN > : > : > : Apr 28 14:21:35 iut-mir-o kernel: ed0: link state changed to UP > : > : > ... > : > : > : the problem appear with the following commit : > : > : > : SVN rev 190643 on 2009-04-02 16:58:45Z by imp (CVS rev 1.126) > : > : > : I do not see any link state change if I revert the commit. > : > : > > : > : > Doh! > : > : > > : > : > I needed to force auto negotiation for other cards to work. Let me > : > : > see if I can dig up the DFE-670TXD and go from there... Are you > also > : > : > seeing really horrible network performance as well? Do you see > this > : > : > only under load, or just at idle? > : > : > > : > : > Warner > : > : > > : > : > : > : Yes network performance suffers from this. The problem only appears > under > : > : load > : > : but not when idle. > : > > : > Thanks. I'll try to reproduce it here. I noticed this on one of the > : > cards, but had trouble reproducing it, but I'll try harder. > : > > : > Warner > : > > : > : I can easily reproduce this by downloading an ISO image via ftp > : and doing a checkout of a subversion repository > > OK. I'll try that. Do you know if you are able to trigger it with > ttcp too? That's where I saw the odd symptoms before... > > Warner > No I'm unable to trigger it with ttcp. From owner-freebsd-net@FreeBSD.ORG Thu Apr 30 13:33:02 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 189A2106566B for ; Thu, 30 Apr 2009 13:33:02 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 9177B8FC08 for ; Thu, 30 Apr 2009 13:33:01 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by bwz9 with SMTP id 9so1788489bwz.43 for ; Thu, 30 Apr 2009 06:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TGH4RcTncfDC5DugFZaEv7uiNUrBXWEyjRS4Rs3fUk0=; b=DSu2Lulwht6y5Fg5ZkW1q12DbB0pijxmaVHAHDFot7e8FG6d88Wa+mlh1ZTFtfMIgm Cmpmm0qR62kLMQALZpAMOvOkjQRdnKgenKnSuNZ0xx6Cjd/dHGB18cvZqWxTxMPU0NIs NtDe+86lznOZZSwazOm1gMjxpVQx4cbyBAFow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=iiwiaXYOXVudNhXR5mV8SOq23edOfOwRLK88QT5nX2aTA5zMgmS0jZU/PYGR0Bgp26 V+g/hh4aY3y4nh6tH5TEjelz8VyobGiVwHsSaEfQJUvzrhEEDv7wzBdHLE6Ls5kZND1j 9A3+8nd7f2wch6c/OUZKkCZwTFERi3PIKxmLU= MIME-Version: 1.0 Received: by 10.103.165.18 with SMTP id s18mr949035muo.124.1241098380259; Thu, 30 Apr 2009 06:33:00 -0700 (PDT) In-Reply-To: References: <5E915E92-2B82-4331-9493-739568CC6E8C@gmail.com> <2e77fc10904290733m4858172ayd96654f3a9a3a8a@mail.gmail.com> <5FD800FE-23E5-482E-8491-564FE52D91D5@gmail.com> Date: Thu, 30 Apr 2009 17:33:00 +0400 Message-ID: From: pluknet To: Nikolay Denev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: bce(4) and lagg(4) fix [was: bce(4) sees all incoming frames as 2026 bytes in length] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 13:33:02 -0000 2009/4/30 Nikolay Denev : > On Apr 30, 2009, at 3:04 PM, Nikolay Denev wrote: > [snip] >>> >>> I think I got it. >>> >>> It seems that the mbuf fields m_pkthdr.len and m_len are not updated to >>> the real packet size pkt_len. >>> Well, actually they are updated, but only if we have ZERO_COPY_SOCKETS >>> defined. >>> >>> After I added this : >>> >>> =A0 m0->m_pkthdr.len =3D m0->m_len =3D pkt_len; >>> >>> at about line 5930 in if_bce.c, the frame length reported by tcpdump >>> seems correct. >>> >>> P.S.: I guess this could be the cause for the lagg(4) over bce(4) >>> problems too? >>> >>> P.S.2: This fix will probably break the ZERO_COPY_SOCKETS case, but >>> should be fairly easy to make it a "proper" fix. >>> >>> Regards, >>> Niki Denev >>> >> >> I can confirm that with this fix I was able to create lagg(4) interface = in >> "failover" mode with only one member, a =A0bce(4) interface, and it seem= s to >> work OK. >> >> > > Here is the patch : > > --- sys/dev/bce/if_bce.c.orig =A0 2009-04-30 14:06:54.000000000 +0200 > +++ sys/dev/bce/if_bce.c =A0 =A0 =A0 =A02009-04-30 14:11:32.000000000 +02= 00 > @@ -5926,6 +5926,11 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto bce_rx_int_next_rx; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > > +#ifndef ZERO_COPY_SOCKETS > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Adjust the packet length to match the re= ceived data. */ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 m0->m_pkthdr.len =3D m0->m_len =3D pkt_len; > +#endif > + > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Send the packet to the appropriate inte= rface. */ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m0->m_pkthdr.rcvif =3D ifp; > Ha-ha, you was fast! The only note: I think the comment part should be consistent with ZERO_COPY_SOCKETS case. Thank you. --=20 wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Thu Apr 30 15:47:43 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7DCF106566C for ; Thu, 30 Apr 2009 15:47:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qy0-f105.google.com (mail-qy0-f105.google.com [209.85.221.105]) by mx1.freebsd.org (Postfix) with ESMTP id 8EAB78FC13 for ; Thu, 30 Apr 2009 15:47:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by qyk3 with SMTP id 3so3842114qyk.3 for ; Thu, 30 Apr 2009 08:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=4eKsRONT4KlXGDwna3CH3+8QguZmJohiXXjunKX4apM=; b=h9CxS9fC1EVQdS0vUQ4vUXsyxZlKx9KbsxcPYRAEXDLdfWQqZEwuIxKqJz9Jz24Tb6 5loCm0q7H00/FRFXp3S6uvXc5a/Zx+XRhbU1wO21Jto55LGfBE2KB6njrZeWPlRKyYx6 a4RMudd2xu5EH7MZZ/m7o3x7LOeOKwVl2TGho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=IVkR+WvBddBbTNcCIpT/D6KYgVbtWKf3KUiWt/1KhNmKuyNCLUIv49USwUNmQcXfHD Vdac3FjlwKo6pSOgewbL07sD5uL4HxFjnrKEYC5Tbf3TLJD15GmnNK7/6iozCdc2oVAJ 12r7nG4FKBiVlvOGktQNGVkr2BHvSqluPBPHU= MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.229.73.134 with SMTP id q6mr1377973qcj.76.1241106462737; Thu, 30 Apr 2009 08:47:42 -0700 (PDT) In-Reply-To: <20090429132156.GA42816@owl.midgard.homeip.net> References: <49F7709F.1020409@modulus.org> <172091.41695.qm@web63907.mail.re1.yahoo.com> <20090429132156.GA42816@owl.midgard.homeip.net> Date: Thu, 30 Apr 2009 23:47:42 +0800 X-Google-Sender-Auth: 234d923930e3f7df Message-ID: From: Adrian Chadd To: Erik Trulsson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Barney Cordoba , Luigi Rizzo , Andrew Snow , FreeBSD Net Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 15:47:44 -0000 2009/4/29 Erik Trulsson : > That appearance is probably due to the fact the the FreeBSD project actually > is a bunch of dudes working on what they feel like doing (or in a few cases > on what they get paid for doing), and that there is very little centralized > planning being done. (And even if there was, there is no way of enforcing > that people work according to such a plan.) There's more centralised planning in the network stack then you seem to think there is. Personally, I'd like to see some of the multi-thread em stuff (iirc for non-multi-threaded cards) that some company has written and kept up to date make it into -current as it obviously works for them and may work well for other people. But "stuff" is happening and along a roughly consensus which will be probably playing out some more during BSDCan in the upcoming week or so. Pay attention to what Robert, Jeff and Kip (may) talk about there. 2c (as an observer of all of this..) Adrian From owner-freebsd-net@FreeBSD.ORG Thu Apr 30 15:51:05 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0C84106566B for ; Thu, 30 Apr 2009 15:51:05 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id 55CAE8FC08 for ; Thu, 30 Apr 2009 15:51:05 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by qw-out-2122.google.com with SMTP id 3so1412779qwe.7 for ; Thu, 30 Apr 2009 08:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=nMQLk67e5DuQdpmSE3gy6XyVARk3pOppUWOQAfVr1LY=; b=syVrkZaFIrnvh6ObrJZcHfWDS6be23Q9AcYUgHvCm2/kPGRFJVMfdcX/k61WbKCtJc ShTecxbMBjNc/FwXEXiFHKWR3crU3AeXlx95z86brZxd9DNNiHB4usztpD7yRLj5Us4t J62JKl3MX2Vfs6sOh5S9A5RrPzr6TOVhRe6as= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=d9IW9fSPPBQC4v0/eppWQOEL2STWt96zBAMEKCr2LAj+T1gtntMdMwqR6ywFtfrzw/ Nn0fvmpLziwY/GNR/D75rC7KLb3FU0wjinR0HFcf9ATfySvanTGFUA5zT4Wr5wQvvYzB wM5ka8153Sf/SXO1w79k5DRDcc2sqdRcI4YPU= MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.229.94.133 with SMTP id z5mr1404576qcm.38.1241106664522; Thu, 30 Apr 2009 08:51:04 -0700 (PDT) In-Reply-To: <628939.54925.qm@web63901.mail.re1.yahoo.com> References: <20090429132156.GA42816@owl.midgard.homeip.net> <628939.54925.qm@web63901.mail.re1.yahoo.com> Date: Thu, 30 Apr 2009 23:51:04 +0800 X-Google-Sender-Auth: d74d0cc9bf75a4ac Message-ID: From: Adrian Chadd To: barney_cordoba@yahoo.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 15:51:05 -0000 2009/4/30 Barney Cordoba : > Its one of the sad truths of FreeBSD. You'd think with such a large number > of commercial users you'd be able to get plenty of funding for the things > that really need to be done, rather then taking whatever bread crumbs > are thrown your way. Perhaps you need fewer bearded academics and a few > more suits to run the project more like a business than an extended > masters thesis? That is happening. Robert/Kris' (and others) working on parallelising the network stack all the way up and down. Kip has been working on dramatically improving TCP connection and packet forward scalability to support 10GE. This is in part commercially funded work. The problem with "commercial funding" is that for the most part, FreeBSD/Linux/etc "mostly work" for most use cases. What you're not seeing is 100% contribution back from commercial organisations who have extended FreeBSD (and linux for that matter) in their environment to fix specific performance constraints. This is finally changing and stuff is being pushed back into the public tree. 2c, Adrian From owner-freebsd-net@FreeBSD.ORG Thu Apr 30 16:11:49 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 541AD106566C for ; Thu, 30 Apr 2009 16:11:49 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by mx1.freebsd.org (Postfix) with ESMTP id A4BFE8FC14 for ; Thu, 30 Apr 2009 16:11:48 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by fk-out-0910.google.com with SMTP id f33so952067fkf.11 for ; Thu, 30 Apr 2009 09:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vXV9PRKtHl6KieChxsGO2arS70dYxB2X7WYVCaId1zs=; b=ip1QU95kWOkUin0+stuKgUe0jIy1yyYg+QHxjer19+5u6JMxfEoNbvB5rqMzgUqLGM 7Eop5UicRJdzwnORv+fCsUlONH9T+GwS2cPoXjsPaQGwIMtQxkNpAZigMaOBpMvrL+iE 4/SS+NIDaFYfkBICc8lydm+tycg5/YjijIvoE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pep/0PlJ8KzUvWUZbuYx6HOZaQCQelBBX+tfcmQA1uNzoQG/QwhcyWYNZ5frIUfQLY dMrq0zKGoD8EIcntEkuzdiddLYbfX3CUkoThh0RMOE4ejXq6UBlspQ9G9eHGT6xNiQmS dcIq5U6ukH6c0nTVmyes3Mq+LbP77Hfdtl3hI= MIME-Version: 1.0 Received: by 10.102.247.4 with SMTP id u4mr1056296muh.128.1241107906327; Thu, 30 Apr 2009 09:11:46 -0700 (PDT) In-Reply-To: References: <49F7709F.1020409@modulus.org> <172091.41695.qm@web63907.mail.re1.yahoo.com> <20090429132156.GA42816@owl.midgard.homeip.net> Date: Thu, 30 Apr 2009 20:11:46 +0400 Message-ID: From: pluknet To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Luigi Rizzo , Andrew Snow , Barney Cordoba Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 16:11:49 -0000 2009/4/30 Adrian Chadd : > 2009/4/29 Erik Trulsson : >> That appearance is probably due to the fact the the FreeBSD project actually >> is a bunch of dudes working on what they feel like doing (or in a few cases >> on what they get paid for doing), and that there is very little centralized >> planning being done. (And even if there was, there is no way of enforcing >> that people work according to such a plan.) > > There's more centralised planning in the network stack then you seem > to think there is. > > Personally, I'd like to see some of the multi-thread em stuff (iirc > for non-multi-threaded cards) that some company has written and kept > up to date make it into -current as it obviously works for them and > may work well for other people. My part of fyi. That company is Yandex - the one of the largest Russian search engines (first of all) :p [1][2]. [1] http://people.yandex-team.ru/~wawa/ [2] http://company.yandex.com/general_info/yandex_today.xml (just my 2 Russian copecks) -- wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Thu Apr 30 17:34:52 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09C48106564A for ; Thu, 30 Apr 2009 17:34:52 +0000 (UTC) (envelope-from vinnix.bsd@gmail.com) Received: from mail-qy0-f105.google.com (mail-qy0-f105.google.com [209.85.221.105]) by mx1.freebsd.org (Postfix) with ESMTP id B70738FC12 for ; Thu, 30 Apr 2009 17:34:51 +0000 (UTC) (envelope-from vinnix.bsd@gmail.com) Received: by qyk3 with SMTP id 3so3959619qyk.3 for ; Thu, 30 Apr 2009 10:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=8pMfE19C7hPWOuRpk55nSh4HolzqqaiXxQIwrRbvBEs=; b=sZfbLvXD/iQH0GYscmS5ukDKb6nBTyDccKsEtU0ZAuMqme7WJv2q71WcQQPVFnkH29 PfTf9JFZ2R/8BudvvLa4xchVikx42y1IYp5Rnjb7N1mczyEHUo0wRW4W/DS3WnXsZMnC Y3TNYDSteFNWkeGYBSjEY8vch0/4NgpAzRETs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=AwC3eYDLYO3rkzdLTkkl0n/HQfjmav0x4Ghxo1qYkqXblgMW4GNyYPYwwvzfI0GaMW bhp0y/x6XL6hNi27eqq+cqHJoIkdI03anBCD4fnfwn7LcVrizR66RGJo1I0N/GRXGtij 3sVYHWwXjN2PYk/DEKubaht6/3uBUhsNpYq0g= MIME-Version: 1.0 Received: by 10.231.35.66 with SMTP id o2mr1733086ibd.30.1241112890800; Thu, 30 Apr 2009 10:34:50 -0700 (PDT) In-Reply-To: <1e31c7980904291605h55244aech10a7725d59fd0cd@mail.gmail.com> References: <1e31c7980904291605h55244aech10a7725d59fd0cd@mail.gmail.com> Date: Thu, 30 Apr 2009 14:34:50 -0300 Message-ID: <1e31c7980904301034y70c678er5728f8ed6b371bf5@mail.gmail.com> From: Vinicius Abrahao To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Problem with lagg failover (using bge0 and wpi0 interfaces) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 17:34:52 -0000 Anyone know if my problem[1] is related by this PR? http://www.freebsd.org/cgi/query-pr.cgi?pr=133178 [1]: http://lists.freebsd.org/pipermail/freebsd-net/2009-April/021873.html Tks, Vinicius From owner-freebsd-net@FreeBSD.ORG Thu Apr 30 19:44:20 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9CBC1065678 for ; Thu, 30 Apr 2009 19:44:20 +0000 (UTC) (envelope-from andrea@brancatelli.it) Received: from mela.raged.it (brancatelli.it [84.233.228.130]) by mx1.freebsd.org (Postfix) with ESMTP id 6FB568FC26 for ; Thu, 30 Apr 2009 19:44:14 +0000 (UTC) (envelope-from andrea@brancatelli.it) Received: from mela.raged.it (localhost [127.0.0.1]) by mela.raged.it (8.14.2/8.14.2) with ESMTP id n3UJE5t2042897 for ; Thu, 30 Apr 2009 21:14:05 +0200 (CEST) (envelope-from andrea@brancatelli.it) Received: (from www@localhost) by mela.raged.it (8.14.2/8.14.2/Submit) id n3UJE4pL042896; Thu, 30 Apr 2009 21:14:04 +0200 (CEST) (envelope-from andrea@brancatelli.it) Date: Thu, 30 Apr 2009 21:14:04 +0200 (CEST) X-Authentication-Warning: mela.raged.it: www set sender to andrea@brancatelli.it using -f To: freebsd-net@freebsd.org X-PHP-Script: webmail.ragedrecords.com/compose2.php for 217.133.85.183 Received: from 217.133.85.183 (auth. user andrea@brancatelli.it@127.0.0.1) by webmail.ragedrecords.com with HTTP; Thu, 30 Apr 2009 20:14:04 +0100 X-IlohaMail-Blah: andrea@brancatelli.it X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.ragedrecords.com) Message-ID: From: Bounce-To: Errors-To: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Virus-Scanned: ClamAV 0.94/9308/Thu Apr 30 19:19:03 2009 on mela.raged.it X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mela.raged.it Subject: lagg LACP between two hosts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 19:44:21 -0000 Hello everybody, I have a strange curiosity maybe you can clarify me :-) Is it possible to do a LACP lagg connection directly between two hosts using two gigalan and two crossed cables? Or maybe three... ;-) Thanks ;-) From owner-freebsd-net@FreeBSD.ORG Thu Apr 30 20:05:59 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED793106566B for ; Thu, 30 Apr 2009 20:05:59 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id ACF2A8FC16 for ; Thu, 30 Apr 2009 20:05:59 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id C4EE4FF32; Fri, 1 May 2009 07:48:30 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0nMD+4RFYUW; Fri, 1 May 2009 07:48:21 +1200 (NZST) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Fri, 1 May 2009 07:48:21 +1200 (NZST) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 0F77F11432; Fri, 1 May 2009 07:48:21 +1200 (NZST) Date: Thu, 30 Apr 2009 12:48:20 -0700 From: Andrew Thompson To: andrea@brancatelli.it Message-ID: <20090430194820.GA67455@citylink.fud.org.nz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-net@freebsd.org Subject: Re: lagg LACP between two hosts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 20:06:00 -0000 On Thu, Apr 30, 2009 at 09:14:04PM +0200, andrea@brancatelli.it wrote: > > Hello everybody, > > I have a strange curiosity maybe you can clarify me :-) > > Is it possible to do a LACP lagg connection directly between two hosts > using two gigalan and two crossed cables? Or maybe three... ;-) Yes, that will work fine. The load balancing across the link uses the mac+ip to hash so you need variation in those to split the traffic. Andrew From owner-freebsd-net@FreeBSD.ORG Thu Apr 30 20:07:37 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D3D810656F5 for ; Thu, 30 Apr 2009 20:07:37 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: from ibctech.ca (unknown [IPv6:2607:f118::b6]) by mx1.freebsd.org (Postfix) with SMTP id E38058FC0A for ; Thu, 30 Apr 2009 20:07:36 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: (qmail 30136 invoked by uid 89); 30 Apr 2009 20:08:24 -0000 Received: from unknown (HELO ?IPv6:2607:f118::5?) (steve@ibctech.ca@2607:f118::5) by 2607:f118::b6 with ESMTPA; 30 Apr 2009 20:08:24 -0000 Message-ID: <49FA0502.4040302@ibctech.ca> Date: Thu, 30 Apr 2009 16:07:30 -0400 From: Steve Bertrand User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: andrea@brancatelli.it References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: lagg LACP between two hosts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 20:07:37 -0000 andrea@brancatelli.it wrote: > Hello everybody, > > I have a strange curiosity maybe you can clarify me :-) > > Is it possible to do a LACP lagg connection directly between two hosts > using two gigalan and two crossed cables? Or maybe three... ;-) I've done it with two GigE nics, and it works perfectly well. Steve From owner-freebsd-net@FreeBSD.ORG Fri May 1 03:44:30 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D98B6106564A for ; Fri, 1 May 2009 03:44:30 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id 645D88FC19 for ; Fri, 1 May 2009 03:44:30 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from hamilton.upcnetadm.upcnet.es (hamilton.upcnetadm.upcnet.es [147.83.2.240]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id n3UN52aK016095 for ; Fri, 1 May 2009 01:05:02 +0200 Received: from [192.168.100.184] ([88.15.98.27]) by hamilton.upcnetadm.upcnet.es (Lotus Domino Release 5.0.12) with ESMTP id 2009050101051069:161553 ; Fri, 1 May 2009 01:05:10 +0200 Message-ID: <49FA2E3F.9050108@entel.upc.edu> Date: Fri, 01 May 2009 01:03:27 +0200 From: =?ISO-8859-1?Q?Gustau_P=E9rez?= User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-MIMETrack: Itemize by SMTP Server on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 01/05/2009 01:05:11, Serialize by Router on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 01/05/2009 01:05:11, Serialize complete at 01/05/2009 01:05:11 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Fri, 01 May 2009 01:05:03 +0200 (CEST) Subject: Signal sensitivity problem with if_rum X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 03:44:31 -0000 Hi, I think this is right place to post, if it is not, please let me know. I'm experiencing problems with two different devices using if_rum. One is a Hercules Guillemot and the other is a Linksys Cisco WUSB54GC The first one is about sensitivity, which is very low: for example, I'm detecting just two or three networks around me (with windows both usb devices detect around 14 or 15 networks) and the reported signal is very low.Placing the sensor very near to my wireless network AP (which is a FreeBSD machine with atheros card placing the txpower to 20) reports a signal quality of 50% or 60%. Linux presents the same problem (my wife's laptop with ubuntu shows the same figures, more or The other one is that having such a low sensitivity makes those dongles unusable when making large transfers, mostly when using scp/sftp or sshfs (samba seems to make it work better for longer transfer, but finally the problem appears). At some given point, the dongles seem to lose contact with the AP (making ifconfig shows that wlan0 is still associated), waiting for a period of time (usually one or two minutes) the transfer continues. Probably both problems are related. In order to debug the problem I tried looking dmesg in both my AP and my laptop (no trace). Tried looking at the ssh logs (when making large transfers, no clue). In the only place I found something was in the samba logs, only saying that there was a problem with the transfer (broken pipe, the socket is closed). So : In the linux world, I found that the register which controls the sensitivity is bbp17 : http://209.85.229.132/search?q=cache:H8W6R5Ds3mYJ:forum.aircrack-ng.org/index.php%3Ftopic%3D2235.0+bbp17+ralink+linux&cd=1&hl=ca&ct=clnk&gl=es&client=firefox-a Tried looking in /usr/src/sys/dev/usb/wlan/if_rum.c, but I got lost. Tried with sysctl -a | grep rum or grep wlan0, but no MiB related to sensitivity appeared. Is there anything I can try ? How can I force bbp 17 to get 0 value ? Tried with rum_def_bbp in if_rum.c, changing 17 to 0. No luck. Regards, Gus From owner-freebsd-net@FreeBSD.ORG Fri May 1 10:27:08 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D74B9106564A for ; Fri, 1 May 2009 10:27:08 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 9F2018FC14 for ; Fri, 1 May 2009 10:27:08 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id B20F178CFD for ; Fri, 1 May 2009 10:11:41 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n41ABftk009640 for ; Fri, 1 May 2009 10:11:41 GMT (envelope-from phk@critter.freebsd.dk) To: net@freebsd.org From: Poul-Henning Kamp Date: Fri, 01 May 2009 10:11:41 +0000 Message-ID: <9639.1241172701@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Subject: SO_LINGER + shutdown(2) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 10:27:09 -0000 I was somewhat surprised to see that calling shutdown(SHUT_WR) on a TCP socket with SO_LINGER set {.l_onoff = 1, .l_linger = 0} does not in fact flush the send queue orderly, but immediately RST's the connection. I realize this is an issue for the Dept. of deep TCP arcanæ and not something to be changed lightly, so consider this more of an observation than bug report. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-net@FreeBSD.ORG Fri May 1 14:20:28 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24F9A1065675 for ; Fri, 1 May 2009 14:20:28 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id AAC788FC21 for ; Fri, 1 May 2009 14:20:27 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so699701fgb.12 for ; Fri, 01 May 2009 07:20:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZWH2hjQr53fDEGgnp+BiER0bSYkoFUCQwS8l/eEWGvA=; b=bXO85pNlTbb0RjZR6+QD+mmL/ZlzU0K0YLDNo8Ptv4/RfefNgj9sod3pLiluUor1W0 o5om+BGZrLl+UmhbzbGY8loUH9+vTmi34u47s0Prf2mHU9iZKKt871aYPn0N/i86J1wC OG+ZYS2XewMTunlB0xguZe19mO4LafaDlNt78= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jv4Fcmqu0XG4qB1tvOJzvZVftNTN8D1B89Awa1yyEOtwuYdmQNkWi/7v86w2dXRAXB ZTTVdDQVPLAdkInqJ8uXb5uqu23FmbpWEMd4DpcDy1rGNtivJxC1pbbqFxcC/eAAT8IF hbe1HPqhit35pFGComJ/yNr/G4bcUjpXQ4egg= MIME-Version: 1.0 Received: by 10.239.163.69 with SMTP id o5mr143520hbd.40.1241186153128; Fri, 01 May 2009 06:55:53 -0700 (PDT) In-Reply-To: <49FA2E3F.9050108@entel.upc.edu> References: <49FA2E3F.9050108@entel.upc.edu> Date: Fri, 1 May 2009 15:55:53 +0200 Message-ID: <3a142e750905010655i5e56282eu240e13f2a03dfb02@mail.gmail.com> From: "Paul B. Mahol" To: Gustau Perez Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Signal sensitivity problem with if_rum X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 14:20:28 -0000 On 5/1/09, Gustau Perez wrote: > > Hi, > > I think this is right place to post, if it is not, please let me know. > > I'm experiencing problems with two different devices using if_rum. > One is a Hercules Guillemot and the other is a Linksys Cisco WUSB54GC > > The first one is about sensitivity, which is very low: for example, > I'm detecting just two or three networks around me (with windows both > usb devices detect around 14 or 15 networks) and the reported signal is > very low.Placing the sensor very near to my wireless network AP (which > is a FreeBSD machine with atheros card placing the txpower to 20) > reports a signal quality of 50% or 60%. > > Linux presents the same problem (my wife's laptop with ubuntu shows > the same figures, more or > > The other one is that having such a low sensitivity makes those > dongles unusable when making large transfers, mostly when using scp/sftp > or sshfs (samba seems to make it work better for longer transfer, but > finally the problem appears). At some given point, the dongles seem to > lose contact with the AP (making ifconfig shows that wlan0 is still > associated), waiting for a period of time (usually one or two minutes) > the transfer continues. Probably both problems are related. > > In order to debug the problem I tried looking dmesg in both my AP and > my laptop (no trace). Tried looking at the ssh logs (when making large > transfers, no clue). In the only place I found something was in the > samba logs, only saying that there was a problem with the transfer > (broken pipe, the socket is closed). > > So : > > In the linux world, I found that the register which controls the > sensitivity is bbp17 : > > http://209.85.229.132/search?q=cache:H8W6R5Ds3mYJ:forum.aircrack-ng.org/index.php%3Ftopic%3D2235.0+bbp17+ralink+linux&cd=1&hl=ca&ct=clnk&gl=es&client=firefox-a > > Tried looking in > /usr/src/sys/dev/usb/wlan/if_rum.c, but I got lost. Tried with sysctl -a > | grep rum or grep wlan0, but no MiB related to sensitivity appeared. > > Is there anything I can try ? How can I force bbp 17 to get 0 value ? > Tried with rum_def_bbp in if_rum.c, changing 17 to 0. No luck. There is several places where bbp17 is changed. Last time I was exploring rum I found that it lacks bbp auto tuning. [Failed to implement it, because in meantime I broke chip :)] -- Paul From owner-freebsd-net@FreeBSD.ORG Fri May 1 15:36:15 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E11A410656F6 for ; Fri, 1 May 2009 15:36:15 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id B84C18FC26 for ; Fri, 1 May 2009 15:36:15 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 0005833845D for ; Fri, 1 May 2009 11:36:14 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 01 May 2009 11:36:14 -0400 X-Sasl-enc: aH7zlgAX4Fp4Mluui+7t/oijs/SEC8xx14Lp2b8QnCAE 1241192174 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 4D2B5D3F8 for ; Fri, 1 May 2009 11:36:14 -0400 (EDT) Message-ID: <49FB16ED.1070909@incunabulum.net> Date: Fri, 01 May 2009 16:36:13 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: freebsd-net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: LOR in ip6_output() and MLDv2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 15:36:16 -0000 Hi all, There is a Lock Order Reversal in ip6_output(), which is triggered by the MLDv2 code. What's the best way to resolve? IF_AFDATA_LOCK could be changed to an rwlock, that might help get rid of it -- ip6_output() will take an exclusive lock by way of in6_setscope(), which is needed as ip6_output() does not accept an ifp. in6_setscope() acquires the IF_AFDATA_LOCK and the SCOPE6_LOCK. It does not write to anything. MLD tries to side-step the use of in6_setscope() with the MLD lock held, but this is not enough because ip6_output() will still need to call in6_setscope() to verify the scope ID which MLD gives to it is not bogus (even though in the KAME stack, this just amounts to an embedded ifindex). The LOR is probably benign, but it exists because the bottom half of IPv6 is taking mutex locks on ifnet's if_afdata field. It is triggered because _domifattach() is always called with the IF_AFDATA lock held, and it takes the MLI_LOCK during initialization. WITNESS sees this lock order and notes it down, it then triggers a LOR on if detach. I'd rather not introduce a netisr for an output queue, as forcing deferred dispatch (to get away from the LOR) is undesirable and could lead to further races on VIMAGE detach, for example. cheers, BMS From owner-freebsd-net@FreeBSD.ORG Fri May 1 16:51:50 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D232E1065680 for ; Fri, 1 May 2009 16:51:50 +0000 (UTC) (envelope-from louie@transsys.com) Received: from ringworld.transsys.com (ringworld.transsys.com [144.202.0.15]) by mx1.freebsd.org (Postfix) with ESMTP id AA8A88FC0C for ; Fri, 1 May 2009 16:51:50 +0000 (UTC) (envelope-from louie@transsys.com) Received: from PM-G5.transsys.com (c-69-141-150-106.hsd1.nj.comcast.net [69.141.150.106]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: louie) by ringworld.transsys.com (Postfix) with ESMTP id 0F00B5C5F; Fri, 1 May 2009 12:25:15 -0400 (EDT) Message-Id: <608FDC77-03A7-47E5-B992-6B0ECC1BFACE@transsys.com> From: Louis Mamakos To: net@freebsd.org In-Reply-To: <9639.1241172701@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 1 May 2009 12:25:14 -0400 References: <9639.1241172701@critter.freebsd.dk> X-Mailer: Apple Mail (2.930.3) Cc: Poul-Henning Kamp Subject: Re: SO_LINGER + shutdown(2) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 16:51:51 -0000 On May 1, 2009, at 6:11 AM, Poul-Henning Kamp wrote: > > I was somewhat surprised to see that calling shutdown(SHUT_WR) on > a TCP socket with SO_LINGER set {.l_onoff =3D 1, .l_linger =3D 0} does > not in fact flush the send queue orderly, but immediately RST's the > connection. > > I realize this is an issue for the Dept. of deep TCP arcan=E6 and not > something to be changed lightly, so consider this more of an > observation than bug report. > Setting aside for the moment what applications might rely on this behavior, this seems unexpected and perhaps wrong to me. The intent of the shutdown() system call in this instance ought to be to indicate that the local end of the connection has no additional data to transmit to the remote TCP peer. But it ought to continue to allow additional data to be read from the connection. Sending a reset segment to the far end will hardly enable that behavior. The remote TCP will abandon the connection and there will be no further data forthcoming from it (aside from what might be in flight.) If the local TCP connection has already received a FIN segment from the far end and is in CLOSEWAIT state, then perhaps that's a bit of a different animal.. louie= From owner-freebsd-net@FreeBSD.ORG Fri May 1 17:33:55 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48E35106564A for ; Fri, 1 May 2009 17:33:55 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 20D018FC0A for ; Fri, 1 May 2009 17:33:54 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 6EF713280AC for ; Fri, 1 May 2009 13:33:54 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 01 May 2009 13:33:54 -0400 X-Sasl-enc: w3casValoHyPETb7nynJuLPcrx2ogBfNY/IuGP+cvAtX 1241199231 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id CEDAC2D5F8 for ; Fri, 1 May 2009 13:33:51 -0400 (EDT) Message-ID: <49FB327E.3010504@incunabulum.net> Date: Fri, 01 May 2009 18:33:50 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: freebsd-net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Request feedback on IPv6 multicast listen on :: X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 17:33:55 -0000 During the MLDv2 refactoring, I removed some old KAME code which supports the ability to listen to *all* multicast groups. It isn't clear to me whether this code was still in use, and I couldn't find information about it in the normative RFCs (2292, 3542) for IPv6 stack implementation. This call needed super-user privileges to use, and I'm not sure if anything is actually using it. Can anyone out there with possible exposure to it clarify? I can find a way to re-introduce it if needed, but I suspect it is very old code which may not have actually been used (it dates back to the initial KAME fork). cheers, BMS From owner-freebsd-net@FreeBSD.ORG Fri May 1 18:06:08 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B4CE106568B for ; Fri, 1 May 2009 18:06:08 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from tokyo01.jp.mail.your.org (tokyo01.jp.mail.your.org [204.9.54.5]) by mx1.freebsd.org (Postfix) with ESMTP id 1A3B78FC0C for ; Fri, 1 May 2009 18:06:07 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from tokyo01.jp.mail.your.org (localhost.your.org [127.0.0.1]) by tokyo01.jp.mail.your.org (Postfix) with ESMTP id 352952AD583B for ; Fri, 1 May 2009 17:46:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=dragondata.com; h= message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date; s=selector1; bh=W5FLG7q3IsAl/IRtWyCq fquc134=; b=JCfUFriRcSahpH3HVg3sdhGwivfHjRLBZtPJ5AbuwGEgG54O+Cxf W6VHjBgi37nnG0HXPhSoWFgX7UW+8ROaWyXamvUiVZWmYDvuzJNMN/pNmrYEMVSI BXev4dDif9N9zi994jnU+Uclra8b4vfgpal66E1qADi9r0q16OAKxjE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=dragondata.com; h=message-id:from :to:content-type:content-transfer-encoding:mime-version:subject: date; q=dns; s=selector1; b=orBk6eyFJquiUaN5xoduGzfCFtnrRAikv4zg BfkyHwV5ED3AGqhHFTSE7hYHfrt5hUiA9mCTewNOD1uqCSLY76PadoFItNWsWclL z51wzI01NSBaqVx3WaO7PCW5Ta92LVx10B+B6qr+TlCKitriWFX6sNGbJ/rfqY6y GlBKmw8= Received: from mail.your.org (server2-a.your.org [216.14.97.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by tokyo01.jp.mail.your.org (Postfix) with ESMTPS id 0AED42AD560D for ; Fri, 1 May 2009 17:46:58 +0000 (UTC) Received: from [216.14.99.244] (unknown [216.14.99.244]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.your.org (Postfix) with ESMTPSA id 86EFB2C9017 for ; Fri, 1 May 2009 17:46:56 +0000 (UTC) Message-Id: <00C19FCC-837A-44B8-A0C9-C56E3D02F8EF@dragondata.com> From: Kevin Day To: freebsd-net@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 1 May 2009 12:46:55 -0500 X-Mailer: Apple Mail (2.930.3) Subject: Slow local TCP transfers on -CURRENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 18:06:08 -0000 I've been seeing this for a few months now on -CURRENT. TCP transfers to local IP addresses (but not 127.0.0.1) are incredibly slow. Transfer from localhost: # scp "root@127.0.0.1:/boot/kernel/kernel" . kernel 100 % 11MB 11.1MB/s 00:00 Appropriately fast. Transfer from an IP on a local interface: # scp "root@216.14.96.4:/boot/kernel/kernel" . kernel 0 % 16KB 13.0KB/s 14:37 ETA The routes seem normal: # route get 127.0.0.1 route to: localhost destination: localhost interface: lo0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 16384 1 0 # route -n get 216.14.96.4 route to: 216.14.96.4 destination: 216.14.96.0 mask: 255.255.255.128 interface: nfe0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0 nfe0: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:c6:dd:9c inet 216.14.96.4 netmask 0xffffff80 broadcast 216.14.96.127 Takes 10-60 minutes to copy, stalling frequently during the transfer. It's not limited to just scp either, all TCP transfers seem to stall this way. I don't believe I'm doing anything unusual, has anyone seen anything like this? -- Kevin From owner-freebsd-net@FreeBSD.ORG Fri May 1 20:05:35 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC2E11065676 for ; Fri, 1 May 2009 20:05:35 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id 39D638FC1C for ; Fri, 1 May 2009 20:05:34 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from hamilton.upcnetadm.upcnet.es (hamilton.upcnetadm.upcnet.es [147.83.2.240]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id n41K5OqP014346; Fri, 1 May 2009 22:05:24 +0200 Received: from [192.168.100.184] ([88.15.98.27]) by hamilton.upcnetadm.upcnet.es (Lotus Domino Release 5.0.12) with ESMTP id 2009050122053298:162925 ; Fri, 1 May 2009 22:05:32 +0200 Message-ID: <49FB55A3.605@entel.upc.edu> Date: Fri, 01 May 2009 22:03:47 +0200 From: =?ISO-8859-1?Q?Gustau_P=E9rez?= User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: "Paul B. Mahol" References: <49FA2E3F.9050108@entel.upc.edu> <3a142e750905010655i5e56282eu240e13f2a03dfb02@mail.gmail.com> In-Reply-To: <3a142e750905010655i5e56282eu240e13f2a03dfb02@mail.gmail.com> X-MIMETrack: Itemize by SMTP Server on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 01/05/2009 22:05:33, Serialize by Router on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 01/05/2009 22:05:33, Serialize complete at 01/05/2009 22:05:33 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Fri, 01 May 2009 22:05:24 +0200 (CEST) Cc: freebsd-net@freebsd.org Subject: Re: Signal sensitivity problem with if_rum X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 20:05:37 -0000 > There is several places where bbp17 is changed. > > Editing the code looking for calls to the function rum_bbp_write, I've been able to find where bbp17 is changed at init. Changing rum_def_bbp[3] (which is reg 17) to values quite 'big' like 0x10 or 0x14 doesn't seem to affect its behaviour. Lowering it even more (0x01for example) sometimes shows more reacheable AP's in range; but signal quality still very bad. Changing RT2573_NOISE_FLOOR doesn't make any change (in terms of signal quality, which remains the same). Any idea if is there anything to change/tune ? Regards, Gus > Last time I was exploring > rum I found that it lacks bbp auto tuning. > [Failed to implement it, because in meantime I broke chip :)] > > From owner-freebsd-net@FreeBSD.ORG Fri May 1 23:20:59 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F3AA106566B for ; Fri, 1 May 2009 23:20:59 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63906.mail.re1.yahoo.com (web63906.mail.re1.yahoo.com [69.147.97.121]) by mx1.freebsd.org (Postfix) with SMTP id 285E58FC18 for ; Fri, 1 May 2009 23:20:59 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 96267 invoked by uid 60001); 1 May 2009 23:20:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1241220058; bh=T+Y83AS4WaWoqO+kSIzvUwWcL2AlLrHLtDZBdUmPVCY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=fmCuaAL5kyQmO+ByUw6v86A0dbpzj95zIkDEBc47A3JyzhDdHAL23zzcLBL4Xb5YFoD/5NfHBeYvq/LWatlt6DPFqBhY6qastxwh0cOL2j1GLHp03wbZn+jn0JGJnosEnt1y01YUkVZO01ovPJ7hR8jvCMIu5TAQ2kBgDPcJ4pI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=R5BP0egv32SeajkMAdjhcIq0Vu4e3JKdbnJxCYB6UZ5Yg50MN4aaIYelpyQvVraSthzOhticQM5N7BF0xdXgix5Ts/GYdQKQp69K1pKPY2KMsn+ZL42W4xIdAzrYdZD9N9a+xDd//d0WoyZcVd/oM2dOY7lM54XPzpKaZBPqw78=; Message-ID: <585693.96129.qm@web63906.mail.re1.yahoo.com> X-YMail-OSG: GdJMw.cVM1nE8tEzf.jiBqjhCOcPYJ66yaV7yY3_pv3C1eTcH8t2cZlJ2k9lSeHqdf6FuPj_4HNXZWhNi8rnQOhieRT4KluSyrSdSlJQNeYvFbuZrg0K.gSzZJKWylFa7O7kFdJeQbEUYlYq83F6djrVSmmTdm7YPzfp1cW6rtpFYmUzreRH2GiMIITpQCCLNEG3YxlCQHaUEnJok7nYOhiKY4lKyapHKVq67QoMktNc8gl7e4TqUkXYe6XF2_tKEWKNPw6AwMLDYHKqgKOqnx841GsOY4mx6QVBadY71ca_3E.fN9wn9wg- Received: from [98.242.223.106] by web63906.mail.re1.yahoo.com via HTTP; Fri, 01 May 2009 16:20:58 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Fri, 1 May 2009 16:20:58 -0700 (PDT) From: Barney Cordoba To: Adrian Chadd In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: FreeBSD Net Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 23:20:59 -0000 --- On Thu, 4/30/09, Adrian Chadd wrote: > From: Adrian Chadd > Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) > To: barney_cordoba@yahoo.com > Cc: "FreeBSD Net" > Date: Thursday, April 30, 2009, 11:51 AM > 2009/4/30 Barney Cordoba : > > Its one of the sad truths of FreeBSD. You'd think > with such a large number > > of commercial users you'd be able to get plenty of > funding for the things > > that really need to be done, rather then taking > whatever bread crumbs > > are thrown your way. Perhaps you need fewer bearded > academics and a few > > more suits to run the project more like a business > than an extended > > masters thesis? > > That is happening. Robert/Kris' (and others) working on > parallelising > the network stack all the way up and down. Kip has been > working on > dramatically improving TCP connection and packet forward > scalability > to support 10GE. This is in part commercially funded work. > > The problem with "commercial funding" is that for > the most part, > FreeBSD/Linux/etc "mostly work" for most use > cases. What you're not > seeing is 100% contribution back from commercial > organisations who > have extended FreeBSD (and linux for that matter) in their > environment > to fix specific performance constraints. This is finally > changing and > stuff is being pushed back into the public tree. I think its unlikely that a commercial implementation is going to be of much use generally, as with a mutex based OS you're going to have to do heavy specialization to get the results you want. For example a web server, transparent firewall and router would required very different implementations to be properly optimised. I'm going to regularly hear the open sorcerers whining about contributing, but the fact is that the work I'm doing has no place in a general purpose OS. Optimizing for a specific commercial product is going to require all kinds of fudging and gimmickry. Barney From owner-freebsd-net@FreeBSD.ORG Fri May 1 23:47:24 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFF251065680 for ; Fri, 1 May 2009 23:47:24 +0000 (UTC) (envelope-from www-data@b08.banan.cz) Received: from b08.banan.cz (b08.banan.cz [77.93.194.181]) by mx1.freebsd.org (Postfix) with ESMTP id 910338FC0A for ; Fri, 1 May 2009 23:47:24 +0000 (UTC) (envelope-from www-data@b08.banan.cz) Received: from b08.banan.cz (localhost [127.0.0.1]) by b08.banan.cz (Postfix) with ESMTP id 86674116C0D for ; Sat, 2 May 2009 00:27:04 +0200 (CEST) Received: by b08.banan.cz (Postfix, from userid 33) id 1AEE51178F2; Fri, 1 May 2009 16:32:38 +0200 (CEST) To: freebsd-net@freebsd.org X-PHP-Script: www.proinex.cz/administrator/components/com_virtuemart/export.php for 196.3.183.72 From: Robert S. Mueller MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: <20090501150357.1AEE51178F2@b08.banan.cz> Date: Fri, 1 May 2009 16:32:38 +0200 (CEST) X-Abuse: abuse@banan.cz Subject: Attn: Beneficiary.... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fbi11@inMail24.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 23:47:25 -0000 Anti-Terrorist and Monitory Crimes Division. Federal Bureau Of Investigation. Attn: Beneficiary, This is to Officially Inform you that it has come to our notice and we have thoroughly investigated by the help of our Intelligence Monitoring Network System that you are having a Legal Transaction with some people, it came to our notice that you are So therefore, we have contacted the Federal Ministry Of Finance on your behalf and they have brought a solution to your problem by arranging your payment in total of (US$20,000,000:00)$20 million in an ATM CARD which you will use to withdraw money in anywhere of the world. You now have the lawful right to claim your fund in the ATM CARD by contacting the ATM CARD CENTER, their email is as follow: {atmpaymentcentre12@inMail24.com}. Also, we have being informed by Mr. Robert Scheels that he gave you instructions on how to proceed and contact the ATM CARD CENTER for their requirements to procure your Approval Slip which contains details of your PERSONAL IDENTIFICATION NUMBER (PIN) which you would use in activating and operating your ATM CARD in any ATM Machine closer to you and note that to procure your Approval Slip it would cost you $550.00. Since the Federal Bureau of Investigation is involved in this transaction, all you did have to do is to be rest assured for this is 100% risk free so do contact the ATM CARD CENTRE so they could let you know on how to make payment for the procurement of your Approval Slip which is the only payment needed before the delivery of your ATM CARD is being effected. Below are the contact details of the ATM CARD CENTRE which you are to proceed and contact them for their requirements to proceed and procure your Approval Slip after making payment of $550.00 CONTACT DETAILS Name: Sandra Larry Email:{atmpaymentcentre12@inMail24.com} We do await your response so we can move on with our Investigation and make sure your ATM SWIFT CARD gets to you. Thanks and hope to read from you soon. FBI Director Robert S. Mueller Note: Do disregard any email you get from any imposter or office claiming to be in possession of your ATM CARD, you are advised only to be in contact with Mrs Sandra Larry of the ATM CARD CENTRE who is the rightful person you are suppose to deal with in regards of your ATM CARD PAYMENT and forward any email you get from imposters to this office so we could act upon and commence investigation. From owner-freebsd-net@FreeBSD.ORG Sat May 2 00:16:14 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BECD11065676 for ; Sat, 2 May 2009 00:16:14 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-fx0-f162.google.com (mail-fx0-f162.google.com [209.85.220.162]) by mx1.freebsd.org (Postfix) with ESMTP id 4C3C98FC0A for ; Sat, 2 May 2009 00:16:14 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by fxm6 with SMTP id 6so2548961fxm.43 for ; Fri, 01 May 2009 17:16:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wQ4gpwXB6gCBbYG7zTPxgFKKWTuidXDQd0KMuf9V7a8=; b=gQlmjXy68m0EeHGpcqQnXRkN6Rt66kDg4/AHWEvqVFx1tQ1v5LoTxgkc3bjwuNTYMf 8Y9H99Tf/gTAslr6p35oSdnpfcjJtpCZtiEpaLB6osx70bTmRhhsCQ/jubynLd9F2FeH 6T00LxkZmcnkqSdXbkTUU5y/IYnFI9IN9hDnw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xtQxyTDwTHd5l9/NZZIMhcokLVlGKVr60BmTIzQO7aPeEGgsOqxfO4EljNW7Hpz0rr 0JoGcwte2dE03FbY39jtPs1JGj0jUMDusTl7UxZTUjvjytWgFLX2uQs55F3qSjZJfAdH NcJYxM1SkbOCHltvTzOOL5a/nnHnbIvL/k27A= MIME-Version: 1.0 Received: by 10.239.163.69 with SMTP id o5mr170076hbd.40.1241223373267; Fri, 01 May 2009 17:16:13 -0700 (PDT) In-Reply-To: <49FB55A3.605@entel.upc.edu> References: <49FA2E3F.9050108@entel.upc.edu> <3a142e750905010655i5e56282eu240e13f2a03dfb02@mail.gmail.com> <49FB55A3.605@entel.upc.edu> Date: Sat, 2 May 2009 02:16:13 +0200 Message-ID: <3a142e750905011716g39ea55f0kd081bfdd55709b37@mail.gmail.com> From: "Paul B. Mahol" To: Gustau Perez Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Signal sensitivity problem with if_rum X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 00:16:15 -0000 On 5/1/09, Gustau Perez wrote: > >> There is several places where bbp17 is changed. >> >> > > Editing the code looking for calls to the function rum_bbp_write, > I've been able to find where bbp17 is changed at init. Changing > rum_def_bbp[3] (which is reg 17) to values quite 'big' like 0x10 or 0x14 > doesn't seem to affect its behaviour. > > Lowering it even more (0x01for example) sometimes shows more > reacheable AP's in range; but signal quality still very bad. > Changing RT2573_NOISE_FLOOR doesn't make any change (in terms of signal > quality, which remains the same). > > Any idea if is there anything to change/tune ? There is not just bbp17 to tune there are probably others much more important registers. But as I already mentioned that code is completly missing. -- Paul From owner-freebsd-net@FreeBSD.ORG Sat May 2 02:00:49 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11A58106564A for ; Sat, 2 May 2009 02:00:49 +0000 (UTC) (envelope-from Jinmei_Tatuya@isc.org) Received: from mon.jinmei.org (mon.jinmei.org [IPv6:2001:4f8:3:36::162]) by mx1.freebsd.org (Postfix) with ESMTP id F3C908FC1E for ; Sat, 2 May 2009 02:00:48 +0000 (UTC) (envelope-from Jinmei_Tatuya@isc.org) Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id A930833C2E; Fri, 1 May 2009 19:00:48 -0700 (PDT) Date: Fri, 01 May 2009 19:00:48 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bruce Simpson In-Reply-To: <49FB327E.3010504@incunabulum.net> References: <49FB327E.3010504@incunabulum.net> 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=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net Subject: Re: Request feedback on IPv6 multicast listen on :: X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 02:00:49 -0000 At Fri, 01 May 2009 18:33:50 +0100, Bruce Simpson wrote: > During the MLDv2 refactoring, I removed some old KAME code which=20 > supports the ability to listen to *all* multicast groups. > It isn't clear to me whether this code was still in use, and I couldn't=20 > find information about it in the normative RFCs (2292, 3542) for IPv6=20 > stack implementation. >=20 > This call needed super-user privileges to use, and I'm not sure if=20 > anything is actually using it. Can anyone out there with possible=20 > exposure to it clarify? I believe you can safely remove it. The KAME repository version of that code was already deprecated long time ago. See the change for rev.1.433 at: http://orange.kame.net/dev/cvsweb2.cgi/kame/kame/sys/netinet6/ip6_output.c I also noted this strange behavior in a book about the KAME implementation: 3684: mreq =3D mtod(m, struct ipv6_mreq *); 3685: if (IN6_IS_ADDR_UNSPECIFIED(&mreq->ipv6mr_multiaddr= )) { 3686: /* 3687: * We use the unspecified address to specif= y to accept 3688: * all multicast addresses. Only super user= is allowed 3689: * to do this. 3690: */ 3692: if (suser(p)) 3696: { 3697: error =3D EACCES; 3698: break; 3699: } 3684=E2=80=933699 ipv6mr_multiaddr =EF=AC=81eld must hold a valid IPv6 multicast address. The KAME implementation allows a privileged application to specify the IPv6 unspeci=EF=AC=81ed address. While the intention may be = to allow the socket to accept packets from any multicast address, the system does not actually behave that way. First, the IN6_LOOKUP_MULTI() macro does not have a special matching rule for the unspeci=EF=AC=81ed address. Secondly, in order to accept any multicast addresses on an interface, it is necessary to specify the promiscuous mode for the interface=E2=80=99s multicast =EF=AC=81lter, which will not = actually be done in this case. Later versions of the KAME implementation removed this code and similar code that exists for IPV6_LEAVE_GROUP. Hope this helps, --- JINMEI, Tatuya Internet Systems Consortium, Inc. From owner-freebsd-net@FreeBSD.ORG Sat May 2 06:32:24 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 760D4106564A for ; Sat, 2 May 2009 06:32:24 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id 2A6BE8FC13 for ; Sat, 2 May 2009 06:32:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by qw-out-2122.google.com with SMTP id 3so2126435qwe.7 for ; Fri, 01 May 2009 23:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=52NjXuUAr/qSPQcnNl+xXs4TRmLpJKzhChcVZJU3oSc=; b=O/yPMI0qZ+xmnAacxkAgqekRzaEarHp9tmjE6nYgXD0TwPdNi9540rBInJ0vXt2UXK qAF8fq0n13+9g76uy9ny0DkRVY+CL77d8XmlcAbfJVHTnU6u8m6DM+8RC89M7pynwqy9 EQB9LcMwUsXmJQ3++XZzqO+DBt38vQPkaIZ4U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=mtkEAPu8Gdm4EUzlCZVqGt9gvtGoZJHXA4IbqEgGdi9pGiMgJK+lECBGUlKfQ9nJ8T HSFkQ9Zh5CQApoZAf1WftATk5zWRVlKTAIlrd09KHhbQLwSJLnAVSnemGvnG63qFvijy 2UFPT3UtxScV0Y7lOBvphyosgpJ2XGgHhA8Q4= MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.229.79.2 with SMTP id n2mr2678661qck.8.1241245943311; Fri, 01 May 2009 23:32:23 -0700 (PDT) In-Reply-To: <585693.96129.qm@web63906.mail.re1.yahoo.com> References: <585693.96129.qm@web63906.mail.re1.yahoo.com> Date: Sat, 2 May 2009 14:32:23 +0800 X-Google-Sender-Auth: c29892363a2664f0 Message-ID: From: Adrian Chadd To: barney_cordoba@yahoo.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 06:32:24 -0000 2009/5/2 Barney Cordoba : > I think its unlikely that a commercial implementation is going to > be of much use generally, as with a mutex based OS you're going to > have to do heavy specialization to get the results =A0you want. For > example a web server, transparent firewall and router would required > very different implementations to be properly optimised. > > I'm going to regularly hear the open sorcerers whining about > contributing, but the fact is that the work I'm doing has no place in > a general purpose OS. Optimizing for a specific commercial product is > going to require all kinds of fudging and gimmickry. Sure, but you may find that your fudging and gimmickry could be useful as a reference platform for more generic improvements. So I do encourage you (and others!) with these sorts of hackery to release your stuff for others to use and abuse. Who knows, they may get improved and included into FreeBSD at a later stage. (FWIW, companies like Ironport do just this. :) Adrian From owner-freebsd-net@FreeBSD.ORG Sat May 2 07:45:35 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF1901065670 for ; Sat, 2 May 2009 07:45:35 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id 555A88FC08 for ; Sat, 2 May 2009 07:45:35 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from hamilton.upcnetadm.upcnet.es (hamilton.upcnetadm.upcnet.es [147.83.2.240]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id n427jOHe012898; Sat, 2 May 2009 09:45:24 +0200 Received: from [192.168.100.184] ([88.15.98.27]) by hamilton.upcnetadm.upcnet.es (Lotus Domino Release 5.0.12) with ESMTP id 2009050209453222:163348 ; Sat, 2 May 2009 09:45:32 +0200 Message-ID: <49FBF9B5.40800@entel.upc.edu> Date: Sat, 02 May 2009 09:43:49 +0200 From: =?ISO-8859-1?Q?Gustau_P=E9rez?= User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: "Paul B. Mahol" References: <49FA2E3F.9050108@entel.upc.edu> <3a142e750905010655i5e56282eu240e13f2a03dfb02@mail.gmail.com> <49FB55A3.605@entel.upc.edu> <3a142e750905011716g39ea55f0kd081bfdd55709b37@mail.gmail.com> In-Reply-To: <3a142e750905011716g39ea55f0kd081bfdd55709b37@mail.gmail.com> X-MIMETrack: Itemize by SMTP Server on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 02/05/2009 09:45:32, Serialize by Router on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 02/05/2009 09:45:33, Serialize complete at 02/05/2009 09:45:33 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Sat, 02 May 2009 09:45:24 +0200 (CEST) Cc: freebsd-net@freebsd.org Subject: Re: Signal sensitivity problem with if_rum X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 07:45:36 -0000 >> Any idea if is there anything to change/tune ? >> > > There is not just bbp17 to tune there are probably others much more important > registers. > > But as I already mentioned that code is completly missing. > > I was not talking about autotuning features, which are missing as you pointed. Was talking just about changing/tuning values of some registers to increase reception sensitivity. The people of linux, seem to have increased the sensitivity by modifing bbp17 and disabling autotuning. I tried with bbp17 and for the autotuning disabled, well, we already have it implemented :) (just joking) Anyway, giving that I didn't get an increase of sensitivity, I think we'll need the help of the developers. Well, this morning will try to increase sensitivity of those usb rum with a linux system, just to check what they say here : http://209.85.229.132/search?q=cache:H8W6R5Ds3mYJ:forum.aircrack-ng.org/index.php%3Ftopic%3D2235.0+bbp17+ralink+linux&cd=1&hl=ca&ct=clnk&gl=es&client=firefox-a Regards, Gus From owner-freebsd-net@FreeBSD.ORG Sat May 2 11:51:21 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7F62106566B for ; Sat, 2 May 2009 11:51:21 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63901.mail.re1.yahoo.com (web63901.mail.re1.yahoo.com [69.147.97.116]) by mx1.freebsd.org (Postfix) with SMTP id 65A8D8FC14 for ; Sat, 2 May 2009 11:51:21 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 72823 invoked by uid 60001); 2 May 2009 11:24:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1241263480; bh=qz9+5KBnTn3R8fsUtxs+85gL42LHkyhMdkbcl+75+bc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5VDjaJSfwziNs0xzpPku9RF6YJVh6slYz18k4fhlAPNOHRpJ/sgkYAygWwpM+oHOkhFTGAt3fuBxtlmrCP0JjdpL6LemS/dXqkI4qWjloUR9geujJAxqDETcRyGpS7R9wlODdujHDYQ8Y4CkkiLoJAiPdOWhEivhFcGFFdPGEic= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=yqsTXKKftmPjqgqbbddmsUdyD5kiHtnK8uwkdr8zkCB1WxucpFJq1WuG6sU+BvCSI6Nyq3/hwUrZDvcH5hMHD7xZTt8pxI3U23pqCnkoCgb/fWjJ853lMfD3ORUXlGjbz/g8YqU2tvFZFaCihM5ZFdOb48NLjjg01u5JHotkoXg=; Message-ID: <666691.64173.qm@web63901.mail.re1.yahoo.com> X-YMail-OSG: rEUwQ24VM1l.nDoiBo4wNOhg9oIn0taQsczRmqsasGzx3Qt5h454AJpQt9ymA8IkAIhopXYJO_K6wTaSz8ehymyKFLSZGEaEGLKAzdOY.FBDqU5lhaXUs1M43LZEsAlYG7s_IjSiOBBKVAgbSHEWb68np14rErccSmsC_YS95f9BNsR6LaqubuQGuioWiVxF.RK76lb_rDLg95qJ5QpBVI3OskcvjP3x2kUuS1mVBwct2pyHUU49HIZf6ZezTWnGjcv.G0UcbkzIstG18HOzfmFiA8FKn4ufYmUdRW5zSCRc5sgDUAgFBhqqhGRcIIgMh50b6X1s5.Cm_bS0ZCU91yXAY3Pq8NgMp2SSww_Qttk- Received: from [98.242.223.106] by web63901.mail.re1.yahoo.com via HTTP; Sat, 02 May 2009 04:24:40 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Sat, 2 May 2009 04:24:40 -0700 (PDT) From: Barney Cordoba To: Adrian Chadd In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: net@freebsd.org Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 11:51:22 -0000 --- On Sat, 5/2/09, Adrian Chadd wrote: > From: Adrian Chadd > Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) > To: barney_cordoba@yahoo.com > Cc: "FreeBSD Net" > Date: Saturday, May 2, 2009, 2:32 AM > 2009/5/2 Barney Cordoba : >=20 > > I think its unlikely that a commercial implementation > is going to > > be of much use generally, as with a mutex based OS > you're going to > > have to do heavy specialization to get the results > =A0you want. For > > example a web server, transparent firewall and router > would required > > very different implementations to be properly > optimised. > > > > I'm going to regularly hear the open sorcerers > whining about > > contributing, but the fact is that the work I'm > doing has no place in > > a general purpose OS. Optimizing for a specific > commercial product is > > going to require all kinds of fudging and gimmickry. >=20 > Sure, but you may find that your fudging and gimmickry > could be useful > as a reference platform for more generic improvements. >=20 > So I do encourage you (and others!) with these sorts of > hackery to > release your stuff for others to use and abuse. Who knows, > they may > get improved and included into FreeBSD at a later stage. >=20 > (FWIW, companies like Ironport do just this. :) >=20 Companies might release bug fixes and such, but nobody is=20 going to spend a lot of money to build a better mousetrap and then effectively give away the work to all of their=20 competitors.=20 BC Barney=0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Sat May 2 12:25:45 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CC0410656F4 for ; Sat, 2 May 2009 12:25:45 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2B10C8FC12 for ; Sat, 2 May 2009 12:25:44 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1M0EHn-0006yK-Sj for freebsd-net@freebsd.org; Sat, 02 May 2009 12:25:44 +0000 Received: from 169-154.dsl.iskon.hr ([89.164.169.154]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 May 2009 12:25:43 +0000 Received: from ivoras by 169-154.dsl.iskon.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 May 2009 12:25:43 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Sat, 02 May 2009 14:25:32 +0200 Lines: 12 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 169-154.dsl.iskon.hr User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) Sender: news Subject: Regression: em driver in -CURRENT, "Invalid MAC address" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 12:25:45 -0000 Hi, When I upgraded my 7-STABLE virtual machine under VirtualBox to 8-CURRENT, the em driver stopped working. VirtualBox supports three different flavours of emulated em devices, all of which result in the "Invalid MAC address" error and cannot be used any more. The error was previously reported for VMWare, but since VirtualBox is as different from VMWare as it can be, the problem is most likely in the driver. I can provide more information if needed, I'll be at DevSummit with the box. From owner-freebsd-net@FreeBSD.ORG Sat May 2 12:50:03 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 876A61065675 for ; Sat, 2 May 2009 12:50:03 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 00F178FC12 for ; Sat, 2 May 2009 12:50:02 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) (authenticated bits=0) by lauren.room52.net (8.14.3/8.14.3) with ESMTP id n42CG9BS043617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 May 2009 22:16:10 +1000 (EST) (envelope-from lstewart@freebsd.org) Message-ID: <49FC3984.8050609@freebsd.org> Date: Sat, 02 May 2009 22:16:04 +1000 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Kevin Day References: <00C19FCC-837A-44B8-A0C9-C56E3D02F8EF@dragondata.com> In-Reply-To: <00C19FCC-837A-44B8-A0C9-C56E3D02F8EF@dragondata.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lauren.room52.net Cc: freebsd-net@freebsd.org Subject: Re: Slow local TCP transfers on -CURRENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 12:50:03 -0000 Kevin Day wrote: > > I've been seeing this for a few months now on -CURRENT. TCP transfers to > local IP addresses (but not 127.0.0.1) are incredibly slow. > > Transfer from localhost: > > # scp "root@127.0.0.1:/boot/kernel/kernel" . > kernel > 100% 11MB 11.1MB/s 00:00 > > Appropriately fast. > > > Transfer from an IP on a local interface: > > # scp "root@216.14.96.4:/boot/kernel/kernel" . > kernel > 0% 16KB 13.0KB/s 14:37 ETA > > > The routes seem normal: > > > # route get 127.0.0.1 > route to: localhost > destination: localhost > interface: lo0 > flags: > recvpipe sendpipe ssthresh rtt,msec mtu weight expire > 0 0 0 0 16384 1 0 > > # route -n get 216.14.96.4 > route to: 216.14.96.4 > destination: 216.14.96.0 > mask: 255.255.255.128 > interface: nfe0 > flags: > recvpipe sendpipe ssthresh rtt,msec mtu weight expire > 0 0 0 0 1500 1 0 > > > nfe0: flags=8843 metric 0 mtu 1500 > options=19b > ether 00:30:48:c6:dd:9c > inet 216.14.96.4 netmask 0xffffff80 broadcast 216.14.96.127 > > Takes 10-60 minutes to copy, stalling frequently during the transfer. > It's not limited to just scp either, all TCP transfers seem to stall > this way. > > > > I don't believe I'm doing anything unusual, has anyone seen anything > like this? Known fallout from the ARPv2 work I believe. As a workaround until it gets fixed: route add -host (if-ip) -iface lo0 (note I haven't tested this myself) (see the Jan 2009 freebsd-net@ thread "Bacula: VERY SLOW on SAME host" for some details). Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Sat May 2 13:17:36 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81219106566B for ; Sat, 2 May 2009 13:17:36 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-fx0-f162.google.com (mail-fx0-f162.google.com [209.85.220.162]) by mx1.freebsd.org (Postfix) with ESMTP id DD0198FC13 for ; Sat, 2 May 2009 13:17:35 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by fxm6 with SMTP id 6so2729007fxm.43 for ; Sat, 02 May 2009 06:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OTTbnEhci8ouNt9Gdja2Te2QXRs/VPA8P3Bi3y/SDRE=; b=fUO39utXQ/h0TT8VOdILes32U4y30tse7LWXCOkEIHGX2zwAXDPK5OgWbJHu4uujDs SBgLfZ0saRj5/OjkXWPDPi+tlUSGqB9ZVGfWS6w7MNS+v6dY+HgKFZVEygRcgRIUbxJW hxtmXL9I/jve8V6ubTYZVLMv+U6KRblUNiZ5Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GdV0VRqnyB5GaqxuG0fmrWn9Xx3CtSNqBu0WsdSD+pDaPQX7wf3W2uQNW3wm00sXvE Z89rgDlMFHDy5zChCoJoAnF1m5jYywIub/6Io9SRwWE+HKOPKd5kS02rcCIGE9LhmD3w jeJXwQxIrcBPr5rU+xiZnMnkxQ5T4e9g99F4I= MIME-Version: 1.0 Received: by 10.239.171.143 with SMTP id w15mr188228hbe.119.1241270254908; Sat, 02 May 2009 06:17:34 -0700 (PDT) In-Reply-To: <49FBF9B5.40800@entel.upc.edu> References: <49FA2E3F.9050108@entel.upc.edu> <3a142e750905010655i5e56282eu240e13f2a03dfb02@mail.gmail.com> <49FB55A3.605@entel.upc.edu> <3a142e750905011716g39ea55f0kd081bfdd55709b37@mail.gmail.com> <49FBF9B5.40800@entel.upc.edu> Date: Sat, 2 May 2009 15:17:34 +0200 Message-ID: <3a142e750905020617y40f62463ma91b46a015b2b2ab@mail.gmail.com> From: "Paul B. Mahol" To: Gustau Perez Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Signal sensitivity problem with if_rum X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 13:17:36 -0000 On 5/2/09, Gustau Perez wrote: > >>> Any idea if is there anything to change/tune ? >>> >> >> There is not just bbp17 to tune there are probably others much more >> important >> registers. >> >> But as I already mentioned that code is completly missing. >> >> > I was not talking about autotuning features, which are missing as you > pointed. Was talking > just about changing/tuning values of some registers to increase > reception sensitivity. > > The people of linux, seem to have increased the sensitivity by > modifing bbp17 and disabling > autotuning. I tried with bbp17 and for the autotuning disabled, well, we > already have it > implemented :) (just joking) Anyway, giving that I didn't get an > increase of sensitivity, I think we'll > need the help of the developers. > > Well, this morning will try to increase sensitivity of those usb rum > with a linux system, just to check > what they say here : That information is misleading, I remmember reading somewhere that linux rt73 had similar problems like rum but it got fixed, and is not present in new kernels. I think that problem originated for linux from now obsolete drivers. On what linux version and what drivers version do you experience similar problems with signal sensitivity like with rum? -- Paul From owner-freebsd-net@FreeBSD.ORG Sat May 2 15:03:52 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E97D11065686 for ; Sat, 2 May 2009 15:03:51 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id 2561A8FC14 for ; Sat, 2 May 2009 15:03:50 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by qw-out-2122.google.com with SMTP id 3so2223106qwe.7 for ; Sat, 02 May 2009 08:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ez0k+HoP4BkmjJ4J8T3MuVq9g660zycSc5jE30Z0mkY=; b=rR+3k4onC+1k/pIUGzjFWyFtj9vsv7rqIeIXMlZnDq4RiXk5yEpnzrxjdoRm+lxXoO bSI4oWiJmsEF+aF+e2xbuFXeqSrCvytS7ZGEPNDHCIprzAEBQSFKQ1JefPcxOiVAB8W9 YfQg6kSMxYtoFpGXVnFB+55mDZ8OtroeC+hXo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xLV0nhzANDSCfSTQDqJvFBnB8AyjIKULzi9BuhLP1Fy2tuYpf7HHaNWiYB8FTw+WlP xeg0agyWnVmHN1pKtveHT9PzEAVPUMA3Q/tpxJZN35maJ/LYsleQjBFRP4Ka8qLNjNsk R47QW30j8QxCtjrvp0Ax5GvldGipOfxj1AdWA= MIME-Version: 1.0 Received: by 10.224.46.16 with SMTP id h16mr4210822qaf.179.1241276630387; Sat, 02 May 2009 08:03:50 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 May 2009 08:03:50 -0700 Message-ID: <2a41acea0905020803s63b69b1awb39538f000f5bd5a@mail.gmail.com> From: Jack Vogel To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Regression: em driver in -CURRENT, "Invalid MAC address" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 15:03:53 -0000 I'm willing to bet that its in fact the same problem that VMWare is having. Our method of getting the mac address changed, and the emulations seem to be unprepared for it. This was done for a real customer requirement to allow support of alternate mac addressing in firmware. What happens now is a warm reset of the hardware is done, followed by reading the RAR[0] register. In a real Intel NIC the mac address will be valid in that register, but in VMWare, and I'm willing to bet in VirtualBox as well, its 0. VMWare also has 3 choices of device (wow, amazing coincidence :), can you tell me when you pick e1000 what real adapter it claims to emulate? I am considering options for this problem. The one I lean toward right now is to make a "legacy" em driver, it will have support for ONLY pre-PCI Express hardware, it will be frozen as it were, the idea is that with no new work on it it will not suffer from any regression type failures. If I do this, there are some strategy issues, and its those I'm thinking about. In any case, I intend to have this problem resolved for 8's release. Stay tuned. Jack On Sat, May 2, 2009 at 5:25 AM, Ivan Voras wrote: > Hi, > > When I upgraded my 7-STABLE virtual machine under VirtualBox to 8-CURRENT, > the em driver stopped working. VirtualBox supports three different flavours > of emulated em devices, all of which result in the "Invalid MAC address" > error and cannot be used any more. > > The error was previously reported for VMWare, but since VirtualBox is as > different from VMWare as it can be, the problem is most likely in the > driver. > > I can provide more information if needed, I'll be at DevSummit with the > box. > > _______________________________________________ > 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 May 2 16:50:03 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12885106566C for ; Sat, 2 May 2009 16:50:03 +0000 (UTC) (envelope-from swun2010@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id C35FB8FC1D for ; Sat, 2 May 2009 16:50:02 +0000 (UTC) (envelope-from swun2010@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so1827753ywe.13 for ; Sat, 02 May 2009 09:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=Kn6GPja/Mueq18MuFjIaqHQZkRlVODXQpRhzm/QAhM8=; b=LD6OaxSWkvcKouxJo5sJnGkl6l8kLWAcutN8nEoYVjC/0fZbwXdfY2+Q3F4drQT077 5jC7SU2KJrpv2yfRQTXKPKO3LanX/ixWyqsFKzjQg4eMadPMS3jpqEZegAVOMwqZo5Cg f2NJzZp87quuJNJHDok22Bt4kboFok2iKCIYc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=i0E5Nx3gvpQqWyJR7YAfpZQqo6WM9ooV1K/EpI8TNm0Uh4Nug3KIjR/BQ57UUuJGdR w8nirmAg9OEeTR2GZhRWTphbnfuribyIUWan5/QvyTnDDSXPcTzMSIIB90fIVhMwGQlI Vs3NOhMG7/5H4zRodSBEklA9uagG0PabB7wzg= MIME-Version: 1.0 Received: by 10.151.132.12 with SMTP id j12mr8098555ybn.42.1241281693338; Sat, 02 May 2009 09:28:13 -0700 (PDT) Date: Sun, 3 May 2009 02:28:13 +1000 Message-ID: <736c47cb0905020928o23062742sced92fc20f351eb3@mail.gmail.com> From: Sam Wun To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: tcp problem with freebsd 7.1? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 16:50:03 -0000 Hi, With regarding to the following statement, is there any serious tcp problem with freebsd 7.1? "We recently found our new FreeBSD server (located in some foreign region) has poor network performance. After doing some tcpdump and iperf testing, we found that out-of-order TCP packets are not inserted into queue. This is an 100Mbps line, and TSO is disabled. " Very appreciate for any suggestion. Thanks From owner-freebsd-net@FreeBSD.ORG Sat May 2 17:00:07 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EB2E106566B for ; Sat, 2 May 2009 17:00:07 +0000 (UTC) (envelope-from swun2010@gmail.com) Received: from mail-qy0-f105.google.com (mail-qy0-f105.google.com [209.85.221.105]) by mx1.freebsd.org (Postfix) with ESMTP id 58B638FC1C for ; Sat, 2 May 2009 17:00:07 +0000 (UTC) (envelope-from swun2010@gmail.com) Received: by qyk3 with SMTP id 3so5884672qyk.3 for ; Sat, 02 May 2009 10:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=Kn6GPja/Mueq18MuFjIaqHQZkRlVODXQpRhzm/QAhM8=; b=DUcfz6m33B+UAaN1XviTuJL0b5Qq/s9qzvrrgJocwpOksoTRYL+Q5gKkv401UVJM/j xBJeAZz/itTZFY2aB3sgWdsn5EyT0MUShudMlALumB4w2gw4GESQTit+NEBsaLpSdAVr HV2OiKCC0RG8EHQ9TBoztoaksspC9ZqIIy3AE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=iu9S8F2JvGoUeasP13Q+XOnKN5SdWskwmpVXQeTHu5lsKPA4RlLxOiHVJTstXZD48c Rta15WQFI2iawoFSA3LH76HVsO1BjtvNeK0PFMPHOwf4iehCycZFZPmHzv+2B7S7gA/f PQ4VfhsCyvMiD+A+f7z+aQXG2/lvDkuRp+Fuo= MIME-Version: 1.0 Received: by 10.220.45.203 with SMTP id g11mr6950374vcf.70.1241281692966; Sat, 02 May 2009 09:28:12 -0700 (PDT) Date: Sun, 3 May 2009 02:28:12 +1000 Message-ID: <736c47cb0905020928h10a956e7r3d9d7fd10bd23a1d@mail.gmail.com> From: Sam Wun To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: tcp problem with freebsd 7.1? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 17:00:07 -0000 Hi, With regarding to the following statement, is there any serious tcp problem with freebsd 7.1? "We recently found our new FreeBSD server (located in some foreign region) has poor network performance. After doing some tcpdump and iperf testing, we found that out-of-order TCP packets are not inserted into queue. This is an 100Mbps line, and TSO is disabled. " Very appreciate for any suggestion. Thanks From owner-freebsd-net@FreeBSD.ORG Sat May 2 18:04:20 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 714DE1065672 for ; Sat, 2 May 2009 18:04:20 +0000 (UTC) (envelope-from wzuber@mac.com) Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by mx1.freebsd.org (Postfix) with ESMTP id 591C78FC14 for ; Sat, 2 May 2009 18:04:19 +0000 (UTC) (envelope-from wzuber@mac.com) MIME-version: 1.0 Received: from [172.16.2.74] ([71.118.144.9]) by asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPA id <0KJ100F4H0R68800@asmtp022.mac.com> for freebsd-net@freebsd.org; Sat, 02 May 2009 10:04:18 -0700 (PDT) Message-id: <7AF3433E-1760-400D-BF04-1C75C838F371@mac.com> From: Wes Zuber To: Sam Wun In-reply-to: <736c47cb0905020928o23062742sced92fc20f351eb3@mail.gmail.com> Content-type: multipart/signed; boundary=Apple-Mail-671-983652833; micalg=sha1; protocol="application/pkcs7-signature" Date: Sat, 02 May 2009 10:04:17 -0700 References: <736c47cb0905020928o23062742sced92fc20f351eb3@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: tcp problem with freebsd 7.1? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 18:04:20 -0000 --Apple-Mail-671-983652833 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit We have had some issues with NIC drivers in the past.. what Nics are you running. Specifically some Nics need to have the CRC checks disabled. This also sounds like state is not being kept on the IP Filter if you are running one. Do you have more details? --Wes On May 2, 2009, at 9:28 AM, Sam Wun wrote: > Hi, > > With regarding to the following statement, is there any serious tcp > problem with freebsd 7.1? > > "We recently found our new FreeBSD server (located in some foreign > region) has poor network performance. After doing some tcpdump and > iperf testing, we found that out-of-order TCP packets are not inserted > into queue. > > This is an 100Mbps line, and TSO is disabled. " > > Very appreciate for any suggestion. > > Thanks > _______________________________________________ > 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" --Apple-Mail-671-983652833-- From owner-freebsd-net@FreeBSD.ORG Sat May 2 20:30:36 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21208106568D for ; Sat, 2 May 2009 20:30:36 +0000 (UTC) (envelope-from rslaranjo@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id D143D8FC15 for ; Sat, 2 May 2009 20:30:35 +0000 (UTC) (envelope-from rslaranjo@gmail.com) Received: by qw-out-2122.google.com with SMTP id 3so2307026qwe.7 for ; Sat, 02 May 2009 13:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=65lVaWqMlbtV8mKkuP5LND8TlnJ9VQtTSiC5Zc+1cM8=; b=eUeLF+0Z8hhk1WQeTE6xL9jC9/nDKGu39+QbP9qOPuEc0iOh1MrsvvH4ibxX8IEd16 8j3u281NaACqaSS0HJWsBM2kWWr+0gmbkhJxL8EgClmtxvmjMbc32EZ9vUFtJEdsudT6 twkvrLhTpU1xvx/QUYay4UhN9on+0paMOcWbg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=Cp+MaZGcbNANgF6ayuvbTCaImaY4AqvKX8whGqKS285y+0riEjwTRXWHy99p/x62oL dP7jueq3GfWCyap503OwwwGlW3K65+D/bSOs0EgIs21hf04BvR0fgjqhLiXtC1mCTxaC wo8zUOY+8xJEa6qA6o6unW5xQRpQH54XRmJo0= MIME-Version: 1.0 Received: by 10.220.93.10 with SMTP id t10mr6921369vcm.107.1241294364692; Sat, 02 May 2009 12:59:24 -0700 (PDT) Date: Sun, 3 May 2009 03:59:24 +0800 Message-ID: From: Rommel Laranjo To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Freebsd failed to create routing prefix X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 20:30:36 -0000 Hello everyone, I need help. My box(Machine1) by default will perform IPv6 stateless autoconfiguration and I need to change this autoconfigured address to static manually without restarting. Here are the steps I follow but I sure I missed something cause I was unsuccessful of doing it. 1. I disabled sysctl knob to stop receiving rtadv # sysctl -w net.inet6.ip6.accept_rtadv=0 2. I then removed the autoconfigured ipv6 address from the interface # ifconfig em0 inet6 2001:db8:1234:abcd:20c:27ff:fe3d:63dd delete 3. I removed the default ipv6 route since I will replace with another route # route delete -inet6 default 4. I then added the autoconfigured ipv6 address back to the interface to make it static # ifconfig em0 inet6 2001:db8:1234:abcd:20c:27ff:fe3d:63dd prefixlen 64 up 5. I added the new default ipv6 route # route add -inet6 default 2001:db8:1234:abcd::1 At this point I pinged 2001:db8:1234:abcd:20c:27ff:fe3d:63dd from another IPv6 box (Machine2) with IPv6 address of the same prefix (2001:db8:1234:abcd:215:d3ff:fe4f:acaf) but with no success. But if I ping6 from Machine2 to my router 2001:db8:1234:abcd::1 I am successfull. I tried to check IPv6 route information from Machine1 thru netstat -rnf inet6 but have not found this entry: 2001:db8:1234:abcd::/64 link#1 UC em0 I hope someone could shed light on how to put this route into my ipv6 routing table. Is this a bug in FreeBSD not to automatically add a routing prefix after changing from IPv6 stateless autoconfiguration to static IPv6 address ? Thanks, Romskie From owner-freebsd-net@FreeBSD.ORG Sat May 2 21:41:53 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5141E1065670; Sat, 2 May 2009 21:41:53 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 266DC8FC14; Sat, 2 May 2009 21:41:53 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n42LfroA035290; Sat, 2 May 2009 21:41:53 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n42Lfr5x035284; Sat, 2 May 2009 21:41:53 GMT (envelope-from linimon) Date: Sat, 2 May 2009 21:41:53 GMT Message-Id: <200905022141.n42Lfr5x035284@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/134168: [ral] ral driver problem on RT2525 2.4GHz transceiver + RT2560 MAC/BBP wireless X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 21:41:53 -0000 Old Synopsis: ral driver problem on RT2525 2.4GHz transceiver + RT2560 MAC/BBP wireless New Synopsis: [ral] ral driver problem on RT2525 2.4GHz transceiver + RT2560 MAC/BBP wireless Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat May 2 21:41:43 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=134168 From owner-freebsd-net@FreeBSD.ORG Sat May 2 21:53:53 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 883A3106564A; Sat, 2 May 2009 21:53:53 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5DA878FC17; Sat, 2 May 2009 21:53:53 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n42Lrr89048496; Sat, 2 May 2009 21:53:53 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n42LrrJf048492; Sat, 2 May 2009 21:53:53 GMT (envelope-from linimon) Date: Sat, 2 May 2009 21:53:53 GMT Message-Id: <200905022153.n42LrrJf048492@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/134157: [dummynet] dummynet loads cpu for 100% and make a system frozen and unstable [regression] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 21:53:54 -0000 Old Synopsis: [dummynet] dummynet loads cpu for 100% and make a system frozen and unstable New Synopsis: [dummynet] dummynet loads cpu for 100% and make a system frozen and unstable [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat May 2 21:53:37 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=134157 From owner-freebsd-net@FreeBSD.ORG Sat May 2 21:56:37 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5E4E106566C; Sat, 2 May 2009 21:56:37 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id ABEFB8FC17; Sat, 2 May 2009 21:56:37 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n42Lub4V048626; Sat, 2 May 2009 21:56:37 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n42Luboo048622; Sat, 2 May 2009 21:56:37 GMT (envelope-from linimon) Date: Sat, 2 May 2009 21:56:37 GMT Message-Id: <200905022156.n42Luboo048622@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/133968: [dummynet] [panic] dummynet kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 21:56:38 -0000 Old Synopsis: Dummynet kernel panic New Synopsis: [dummynet] [panic] dummynet kernel panic Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat May 2 21:56:12 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=133968 From owner-freebsd-net@FreeBSD.ORG Sat May 2 21:57:09 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E67B61065693; Sat, 2 May 2009 21:57:09 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BBCF58FC28; Sat, 2 May 2009 21:57:09 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n42Lv9gN048675; Sat, 2 May 2009 21:57:09 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n42Lv9vd048671; Sat, 2 May 2009 21:57:09 GMT (envelope-from linimon) Date: Sat, 2 May 2009 21:57:09 GMT Message-Id: <200905022157.n42Lv9vd048671@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/133969: [dummynet] [panic] Fatal trap 12: page fault while in kernel mode with dummynet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 21:57:10 -0000 Old Synopsis: Fatal trap 12: page fault while in kernel mode with dummynet New Synopsis: [dummynet] [panic] Fatal trap 12: page fault while in kernel mode with dummynet Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat May 2 21:56:48 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=133969 From owner-freebsd-net@FreeBSD.ORG Sat May 2 23:00:00 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10B8D1065672 for ; Sat, 2 May 2009 23:00:00 +0000 (UTC) (envelope-from aman.jassal@esigetel.fr) Received: from mail.esigetel.fr (venus.esigetel.fr [192.134.106.8]) by mx1.freebsd.org (Postfix) with ESMTP id 935658FC1B for ; Sat, 2 May 2009 22:59:59 +0000 (UTC) (envelope-from aman.jassal@esigetel.fr) Received: by mail.esigetel.fr (Postfix, from userid 65534) id 1B1E5108B8; Sun, 3 May 2009 00:43:10 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on venus.esigetel.avon X-Spam-Level: X-Spam-Status: No, score=-3.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=unavailable version=3.1.8 Received: from localhost (localhost [127.0.0.1]) by mail.esigetel.fr (Postfix) with ESMTP id 8B3B4108B7; Sun, 3 May 2009 00:43:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at esigetel.fr Received: from mail.esigetel.fr ([127.0.0.1]) by localhost (venus.esigetel.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1DSz3oXK7rZ; Sun, 3 May 2009 00:43:04 +0200 (CEST) Received: from webmail.esigetel.fr (neo.ecampus.avon [192.168.106.14]) by mail.esigetel.fr (Postfix) with ESMTP id 4EF1410872; Sun, 3 May 2009 00:43:04 +0200 (CEST) Received: from 86.212.66.201 by webmail.esigetel.fr with HTTP; Sun, 3 May 2009 00:43:04 +0200 (CEST) Message-ID: <52471.86.212.66.201.1241304184.squirrel@webmail.esigetel.fr> In-Reply-To: References: Date: Sun, 3 May 2009 00:43:04 +0200 (CEST) From: "JASSAL Aman" To: "Rommel Laranjo" User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: Freebsd failed to create routing prefix X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 23:00:00 -0000 Hello M.Laranjo The Kame stack for IPv6 should be working fine, whether you use stateless autoconfiguration or static configuration. Since you want to use static configuration, my suggestion would be to modify the /etc/rc.conf file so that your static configuration is loaded everytime at boot. That way, you don't have to suppress the autoconfigured address to reconfigure your static address afterwards. The lines you will need are : ipv6_enable="YES" ipv6_network_interface="em0" ipv6_ifconfig_em0="2001:db8:1234:abcd:20c:27ff:fe3d:63dd prefixlen 64" ipv6_defaultrouter="2001:db8:1234:abcd::1" This should work. Please try to ping6 your router to see if everything is working as it's supposed to. About your last question, I'm not 100% sure, but I don't think FreeBSD will autoconfigure a route if you just add a static ipv6 address on your interface... Unless you use a routing daemon like routed. Kind regards Aman Jassal Le Sam 2 mai 2009 21:59, Rommel Laranjo a écrit : > Hello everyone, > > > I need help. My box(Machine1) by default will perform IPv6 stateless > autoconfiguration and I need to change this autoconfigured address to > static manually without restarting. Here are the steps I follow but I sure > I missed something cause I was > unsuccessful of doing it. > > 1. I disabled sysctl knob to stop receiving rtadv > # sysctl -w net.inet6.ip6.accept_rtadv=0 > > > 2. I then removed the autoconfigured ipv6 address from the interface > # ifconfig em0 inet6 2001:db8:1234:abcd:20c:27ff:fe3d:63dd delete > > > 3. I removed the default ipv6 route since I will replace with another > route # route delete -inet6 default > > > 4. I then added the autoconfigured ipv6 address back to the interface to > make it static # ifconfig em0 inet6 2001:db8:1234:abcd:20c:27ff:fe3d:63dd > prefixlen 64 up > > 5. I added the new default ipv6 route > # route add -inet6 default 2001:db8:1234:abcd::1 > > > At this point I pinged 2001:db8:1234:abcd:20c:27ff:fe3d:63dd from another > IPv6 box (Machine2) with IPv6 address of the same prefix > (2001:db8:1234:abcd:215:d3ff:fe4f:acaf) but with no success. But if I > ping6 from Machine2 to my router 2001:db8:1234:abcd::1 I am successfull. > > I tried to check IPv6 route information from Machine1 thru netstat -rnf > inet6 but have not found this entry: > > 2001:db8:1234:abcd::/64 link#1 UC > em0 > > I hope someone could shed light on how to put this route into my ipv6 > routing table. Is this a bug in FreeBSD not to automatically add a routing > prefix after changing from IPv6 stateless autoconfiguration to static IPv6 > address ? > > Thanks, > > > Romskie > _______________________________________________ > 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 May 2 23:15:32 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1E09106566C for ; Sat, 2 May 2009 23:15:32 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 136D08FC08 for ; Sat, 2 May 2009 23:15:31 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by ewy19 with SMTP id 19so2914253ewy.43 for ; Sat, 02 May 2009 16:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=xv/E9JmKhquvzRxiuZhXGpE6BU65qH9EKM73fKJi88U=; b=ctLzIM0Xme8A6/nOey4gMAFnhJxAmF9rstalW+AnYCr4LtSmuunNFuXOCCrs8BtsB3 E8N05OUj7mXRhjcnI+hOgeDNP1eUWf3AFSO7UxTTqSuAyZftNh0IT8NrCLPoOjRvxYoZ kYluNJ1S2giBqHDV/uPqQKTtZQcdXwnSve0sI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=ilqpobcZ0I1VINzJYVGrUn8hTsAS85IbkiLoMDVAYK/SIP6OX4AIALUzh0EM3gMA3u L27wdiWHRLVYkogp2oMgFeikzL7zGmQRexYSy6tjrS40fcNnzub3xGfGDHCFq8JF0KWM LJGzFw5HszdVLaUvGIOc2bgZKZ5i8b93JdOg0= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.210.57.3 with SMTP id f3mr4456250eba.12.1241306131082; Sat, 02 May 2009 16:15:31 -0700 (PDT) In-Reply-To: <2a41acea0905020803s63b69b1awb39538f000f5bd5a@mail.gmail.com> References: <2a41acea0905020803s63b69b1awb39538f000f5bd5a@mail.gmail.com> From: Ivan Voras Date: Sun, 3 May 2009 01:15:16 +0200 X-Google-Sender-Auth: ca3ab27b44ebad0e Message-ID: <9bbcef730905021615l21ef8a73hf26aca18f3230c3b@mail.gmail.com> To: Jack Vogel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Regression: em driver in -CURRENT, "Invalid MAC address" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 23:15:33 -0000 2009/5/2 Jack Vogel : > I'm willing to bet that its in fact the same problem that VMWare is having. > Our method of getting the mac address changed, and the emulations seem > to be unprepared for it. > > This was done for a real customer requirement to allow support of alternate > mac addressing in firmware. What happens now is a warm reset of the hardware > is done, followed by reading the RAR[0] register. In a real Intel NIC the > mac > address will be valid in that register, but in VMWare, and I'm willing to > bet in > VirtualBox as well, its 0. > > VMWare also has 3 choices of device (wow, amazing coincidence :), can > you tell me when you pick e1000 what real adapter it claims to emulate? Here's the information on all three: em0: port 0xc060-0xc067 mem 0xf0820000-0xf083ffff irq 16 at device 8.0 on pci0 em0: Invalid MAC address device_attach: em0 attach returned 5 em1: port 0xc068-0xc06f mem 0xf0840000-0xf085ffff irq 17 at device 9.0 on pci0 em1: Invalid MAC address device_attach: em1 attach returned 5 em2: port 0xc070-0xc077 mem 0xf0860000-0xf087ffff irq 18 at device 10.0 on pci0 em2: Invalid MAC address device_attach: em2 attach returned 5 em0@pci0:0:8:0: class=0x020000 card=0x001e8086 chip=0x100e8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82540EM Gigabit Ethernet Controller' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction em1@pci0:0:9:0: class=0x020000 card=0x10048086 chip=0x10048086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82543GC Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction em2@pci0:0:10:0: class=0x020000 card=0x075015ad chip=0x100f8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82545EM Gigabit Ethernet Controller (copper)' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction > I am considering options for this problem. The one I lean toward right now > is to make a "legacy" em driver, it will have support for ONLY pre-PCI > Express > hardware, it will be frozen as it were, the idea is that with no new work on > it > it will not suffer from any regression type failures. If I do this, there > are some > strategy issues, and its those I'm thinking about. I think that would be a losing battle wrt future developments of both the driver and the VM environments (too fragile state; anyway, other OSes don't have the issue so why should we?). I don't really know how it works but couldn't you use the information talked about earlier (register is 0 after a warm reset) to detect the general class of the problem and if detected conditionally proceed with the old code / behaviour just for the initialization part? Another possible route is to make use of VM detection present in HEAD and just blindly use the old way if a VM environment is detected. I think this is only slightly less bad than forking the driver since new VM platforms are appearing all the time - is something like the middle option doable? From owner-freebsd-net@FreeBSD.ORG Sat May 2 23:17:01 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA707106564A for ; Sat, 2 May 2009 23:17:01 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (unknown [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 4B1178FC08 for ; Sat, 2 May 2009 23:17:01 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from delta.allbsd.org (p3138-ipbf904funabasi.chiba.ocn.ne.jp [122.26.38.138]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.2) with ESMTP id n42NGnk7002116; Sun, 3 May 2009 08:17:00 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id n42NGbig082397; Sun, 3 May 2009 08:16:39 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sun, 03 May 2009 08:16:17 +0900 (JST) Message-Id: <20090503.081617.15105360.hrs@allbsd.org> To: rslaranjo@gmail.com From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.2 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sun_May__3_08_16_17_2009_806)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mail.allbsd.org [133.31.130.32]); Sun, 03 May 2009 08:17:00 +0900 (JST) Cc: freebsd-net@FreeBSD.org Subject: Re: Freebsd failed to create routing prefix X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 23:17:02 -0000 ----Security_Multipart(Sun_May__3_08_16_17_2009_806)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rommel Laranjo wrote in : rs> I hope someone could shed light on how to put this route into my ipv6 rs> routing table. rs> Is this a bug in FreeBSD not to automatically add a routing prefix rs> after changing from IPv6 stateless autoconfiguration to rs> static IPv6 address ? It looks odd because that link should be added automatically at 4 in your procedure regardless of whether you use the stateless autoconf. BTW, does your system have multiple NICs? -- | Hiroki SATO ----Security_Multipart(Sun_May__3_08_16_17_2009_806)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkn81EEACgkQTyzT2CeTzy2jhgCdGtgC2fUO8n+/MU6o5DI5x695 a8gAnjah6Sl7Al7ZtrCj6EzyWRcAaBqF =d3qW -----END PGP SIGNATURE----- ----Security_Multipart(Sun_May__3_08_16_17_2009_806)----