From owner-freebsd-net@freebsd.org Sun Sep 6 02:13:10 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 559D59CB798 for ; Sun, 6 Sep 2015 02:13:10 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A462302 for ; Sun, 6 Sep 2015 02:13:10 +0000 (UTC) (envelope-from artemb@gmail.com) Received: by obqa2 with SMTP id a2so41730590obq.3 for ; Sat, 05 Sep 2015 19:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m2SmvIlj51RsSGFqmBfprkxxLYccDcVkLbkII2+hUsE=; b=Jd/HiVL82N3qDuMhTFmeKZ8KevLiWZu8gUpWD5R2M6+PhkDdkSnOZjMwr2grF4PF6P DJiWdunFgkEC4ly66vYp9Ni0nQ2wmFtrbulfqVkR7bRWPsJchP2FGK6zky/o5vq2cu38 Ewv7Sto5mZ8jS7WxU9jVXTyYkS+GWxN4TyoStWOD8mG7lW/ATTJurcOKvtKKw6NT/bqq 2atBTmF3GVeCiz8lxySqH5V6pScrgEf97i15SVugWKnRk11Dt2wLQPyM5PkfusOnYSGy ttDkdW6rHPzn1Pa1rM7xccNwErt3FLdEvjjl2UmzZgsTUBkOCTe1Gn5722LrwWMMhvF0 LYqw== MIME-Version: 1.0 X-Received: by 10.60.131.74 with SMTP id ok10mr9376253oeb.83.1441505589293; Sat, 05 Sep 2015 19:13:09 -0700 (PDT) Received: by 10.202.83.74 with HTTP; Sat, 5 Sep 2015 19:13:09 -0700 (PDT) In-Reply-To: References: <1441485132.75285.YahooMailBasic@web165005.mail.bf1.yahoo.com> Date: Sat, 5 Sep 2015 19:13:09 -0700 Message-ID: Subject: Re: Problem with receiving packets right after remote-interface is up From: Artem Belevich To: "M. V." Cc: "freebsd-net@freebsd.org" , Luigi Rizzo Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2015 02:13:10 -0000 On Sat, Sep 5, 2015 at 2:44 PM, Luigi Rizzo wrote: > You may be able to avoid the issue if you avoid autonegotiation and > manually set the media type, speed and duplex. > Technically, 1G ethernet *requires* autonegotiation. http://standards.ieee.org/findstds/interps/IEEE802.3af-2003interp-6.pdf While you can indeed set speed/duplex manually, you will also need to make sure both have have proper clock master/slave selection which is normally done via autonegotiation. On Freebsd some interfaces support "mediaopt master" option -- check if that's the case for your interface with ifconfig -m. You will also need to make sure that the other end of the link is also configured to set matching link parameters manually. Even with all of that, copper PHYs take a while to bring link up as PHYs need to tune their parameters. Ethernet MAC will not be able to send or receive any packets *on the wire* until PHYs are done which may take relatively long time (~hundreds of milliseconds). > > On Saturday, September 5, 2015, M. V. via freebsd-net < > freebsd-net@freebsd.org> wrote: > > > Hi, > > > > Our product is being tested with Spirent TestCenter, and we're facing an > > unusual problem with the tests. > > We use NICs with intel 82574 and 82576 on FreeBSD 9.2 with latest em and > > igb drivers (we also tested this on FreeBSD-10.1) It seems what Spirent > > TestCenter does to start any individual test is, it disables its own > > interface, and at the beginning of the new test, it suddenly "up"s its > > interface and sends test packet right after that without any delay. > You may want to go over spirent box settings and look for something along the lines of "wait for the link to come up". It may be somewhere in per-interface settings. > This is > > where we have problem, and we don't receive this first packets most of the > > time (result is vary, in 100 tests, we lose about 60~70% of this "first" > > packets on each test, so we FAIL most of tests because apparently we need > > about 0.5~1 seconds after setup and renegotiation before we can receive > > packets) > That's in the ballpark of time it takes for a copper link to come up. > > we checked both em and igb drivers and both have this problem. > > this is how we reproduce the problem: > > - connect sender-system's first port to receiver-system's first port. > > - In sender-system: > > -- ifconfig em0 down > > -- sleep 5 > > -- ifconfig em0 up && tcpreplay -l 1 -i em0 one_packet.pcap > > > > We checked, and even though sender sends packet successfully (tx led > > blinks), > It's not a conclusive proof that the packet made it to the wire. Depending on where the LED is connected, it may mean different things -- if it's set up to indicate that MAC is sending a packet to PHY, for instance, it would happily blink if the link is down. > in receiver even driver doesn't receive it (rx led doesn't blink, > > and "rxeof" function in "if_em" tells us no new packet is received) > > we removed optional interface options like msix, tso, rxcsum, ... but no > > luck. > Which is another point that the link is not up and the packet did not get received by the PHY. > > > > So, does anyone know any solution for this problem? or any suggestions on > > where we should look or what we should do that might solve it and prevent > > our tests from being failed? > It sounds to me like the problem is with your test setup. If your test requires no packet drops, then it implicitly assumes having established link and sending the packets right after the interface (and not necessarily the physical link) is up is really pushing it. You will either need to configure your test gear to wait some time after the interface is up, or redesign your test so it can tolerate some packet loss while the physical link is being established. To make things more interesting, consider that ethernet does not guarantee packet delivery at all. --Artem From owner-freebsd-net@freebsd.org Sun Sep 6 15:07:51 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B32DB9CBBF8 for ; Sun, 6 Sep 2015 15:07:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9FFB6EC3 for ; Sun, 6 Sep 2015 15:07:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t86F7pAW000547 for ; Sun, 6 Sep 2015 15:07:51 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202875] ixv driver in 11.0-CURRENT doesn't pass traffic using KVM hypervisor Date: Sun, 06 Sep 2015 15:07:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: jeffrey.e.pieper@intel.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2015 15:07:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202875 --- Comment #4 from Jeff Pieper --- (In reply to Patrick Kelsey from comment #2) Exactly the same. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Sun Sep 6 17:47:10 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E28E39CB9D4 for ; Sun, 6 Sep 2015 17:47:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C47531D6A for ; Sun, 6 Sep 2015 17:47:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t86HlAoY085584 for ; Sun, 6 Sep 2015 17:47:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202875] ixv driver in 11.0-CURRENT doesn't pass traffic using KVM hypervisor Date: Sun, 06 Sep 2015 17:47:10 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: jeffrey.e.pieper@intel.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2015 17:47:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202875 --- Comment #5 from Jeff Pieper --- (In reply to Patrick Kelsey from comment #3) Our internal out-of-tree driver has all commits included in HEAD with the exceptions being r285590 and r285592, and It works as expected. During discussion with Eric Joyner, r285590 was determined to be the most likely cause. This appears to be an rx issue, as tcpdump on SUT shows only ARP requests being sent, but on a link partner tcpdump shows ARP requests being received and replies being sent. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Sun Sep 6 19:22:18 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4132E9CC7CA for ; Sun, 6 Sep 2015 19:22:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 141631334 for ; Sun, 6 Sep 2015 19:22:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t86JMHpD014894 for ; Sun, 6 Sep 2015 19:22:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202875] ixv driver in 11.0-CURRENT doesn't pass traffic using KVM hypervisor Date: Sun, 06 Sep 2015 19:22:18 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: pkelsey@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2015 19:22:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202875 --- Comment #6 from Patrick Kelsey --- (In reply to Jeff Pieper from comment #5) > (In reply to Patrick Kelsey from comment #3) > > Our internal out-of-tree driver has all commits included in HEAD with the > exceptions being r285590 and r285592, and It works as expected. During > discussion with Eric Joyner, r285590 was determined to be the most likely > cause. If you are down to two revisions in question, that's only one patch-and-test step away from knowing with certainty which is the culprit... If r285590 is indeed the culprit, then the change I made to the receive tail pointer initialization needs to be looked at. On the hardware I was using at least, initializing the tail pointer before enabling the queue was not sufficient because enabling the queue would clear the tail pointer (the driver was working only by coincidence as it would wind up falling into the rx ring refresh logic and wind up rewriting the tail pointer). Moving the initialization to after the queue was enabled resolved this issue. Perhaps there are other constraints/requirements on tail pointer initialization - for example, maybe on some hardware, enabling the queue with both the head and tail pointers set to zero wedges the queue, or maybe another wmb() is required between the tail pointer initialization where it is now and the register writes that follow. The hardware I'm using: ix0@pci0:6:0:0: class=0x020000 card=0x000c8086 chip=0x10fb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82599EB 10-Gigabit SFI/SFP+ Network Connection' On the hardware you are seeing this issue on, are you able to test ixv under a FreeBSD 11.0-CURRENT host? By that, I mean run FreeBSD as the host on the system and create and test VFs within the host by using iovctl. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Sun Sep 6 19:54:01 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D6E29CB57C for ; Sun, 6 Sep 2015 19:54:01 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2CD60358 for ; Sun, 6 Sep 2015 19:54:01 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id t86JrsrP077893 for ; Sun, 6 Sep 2015 12:53:58 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201509061953.t86JrsrP077893@gw.catspoiler.org> Date: Sun, 6 Sep 2015 12:53:53 -0700 (PDT) From: Don Lewis Subject: Re: CoDel and ECN questions To: freebsd-net@FreeBSD.org In-Reply-To: <201509020450.t824oTKP057556@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2015 19:54:01 -0000 On 1 Sep, Don Lewis wrote: > Bufferbloat on my DSL link to the outside world has been bugging me > lately. I was considering adding an OpenWrt box between my DSL modem > and my FreeBSD firewall in order to get CoDel, when I discovered that > CoDel had been quietly added to FreeBSD 11. Unfortunately the > documentation is severely lacking. The ALTQ(4) man page mentions CoDel > and points to pfctl(8) and pf.conf(5) for details, but pf.conf(5) > discusses cbq, priq, hfsc, and red, but not codel. > > I'm currently using ipfw and not pf, but it looks like ipfw can connect > to altq, so I'm good there. ... in the outbound direction only. > I need to limit bandwidth in both directions, but altq only controls > outbound traffic on an interface, which makes sense. If this box was > just forwarding packets between two interfaces, I could also use altq on > the inward-facing interface to limit download bandwidth to control the > queue depth on the ISP side of my DSL link. The problem is that some > of the inbound traffic terminates on the firewall box itself, and in the > future I may have more than one inside interface. Dummynet is able to > control bandwidth in both directions, but it only implements RED and > gRED but not CoDel (or at least it's not documented). In the simple case of a single host downloading via a slow connection, altq doesn't help at all since it only deals with outgoing packets and there isn't an outbound interface where it is helpful to limit the bandwidth. Looking at the source, it seems that there isn't a CoDel implementation for dummynet. It might be interesting to allow dummynet to use altq queues. That would avoid having to reimplement CoDel for dummynet. I do want to limit incoming bandwidth. By setting the inbound bandwidth limit slightly below my DSL download rate, and by using ECN and/or dropping packets locally, I can get the remote TCP senders to slow down and not bloat the buffers at the ISP end of my DSL pipe. Ideally, my ISP would fix he bufferbloat problem on their end, but I'm not holding my breath ... > The OpenWrt implementation can account for extra per-packet overhead in > its bandwidth calculations. That could be significant for me because of > the additional PPPoE and ATM overhead, which is pretty large for small > packets. Do we have anything similar? Doesn't look like we have that. > Can we combine ECN with CoDel? Pf.conf(5) says that ECN implies RED. Looks like the documentation is lagging. Grepping the source turns up ECN references in the CoDel source. > I'm using 6rd and gif(4) for IPv6 connectivity. Does gif copy the ECN > bits when encapsulating and decapsulating packets? The gif and stf man pages say this is an option. BTW, it would be really nice if net/stf-6rd-kmod was imported. The port hasn't been updated to support FreeBSD 10.2, and there is no support at all for 11.0-CURRENT. Locally applying the patch to src means losing freebsd-update support. Importing this was discussed way back in 2010 and concerns were expressed about this being a waste of time since the code would be obsolete before the useful end of life of FreeBSD 9. Five years later, at the rate that my ISP does technology upgrades, it looks like I'll be needing 6rd through FreeBSD 10 EOL ... From owner-freebsd-net@freebsd.org Sun Sep 6 21:00:25 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9202B9CB684 for ; Sun, 6 Sep 2015 21:00:25 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6CBA2E91 for ; Sun, 6 Sep 2015 21:00:25 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t86L0Pbr096988 for ; Sun, 6 Sep 2015 21:00:25 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201509062100.t86L0Pbr096988@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-net@FreeBSD.org Subject: Problem reports for freebsd-net@FreeBSD.org that need special attention X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Sun, 06 Sep 2015 21:00:25 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2015 21:00:25 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 194515 | Fatal Trap 12 Kernel with vimage Open | 199136 | [if_tap] Added down_on_close sysctl variable to t 2 problems total for which you should take action. From owner-freebsd-net@freebsd.org Sun Sep 6 21:37:47 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02C269C5B9C for ; Sun, 6 Sep 2015 21:37:47 +0000 (UTC) (envelope-from bored_to_death85@yahoo.com) Received: from nm43-vm3.bullet.mail.gq1.yahoo.com (nm43-vm3.bullet.mail.gq1.yahoo.com [67.195.87.218]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C14B9CA for ; Sun, 6 Sep 2015 21:37:45 +0000 (UTC) (envelope-from bored_to_death85@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1441575278; bh=kcnFSOsY9+FRyENm27yMMNa1pgD3yX5+8/HbPSNBcKE=; h=Date:From:Subject:To:Cc:In-Reply-To:From:Subject; b=YAIuqTuQY85JIkSzkEelLKudDBxysjZFGwoMR4zR87lL/HPWTFS7EUAV8lL90xu6G9z1GBGQ6Mnu9WbVKyUKHdNrLsotv5+7GcxEdTJOU7pNMjScNmfN3MFLCPtg6esU+gtmkhyANTgCLRhdq1kXeVrYYyHF6X9eVLUW4tSuFmlhJ9kZ5FgQJtDj5aODXAcPIhXRh7bAxrT7IMPw83ylpY2JP1LL0IeofZizLHJMrgsSOjxZTRyeYAT+nFyg/yV8SebhwgSP8NWbl8FbBntW2EtUC/wUCt9UodvgBeNUiK5v8wb7dvxOBi9IyAnWECVw2DjuL1CdVN2eaBp67mRDrQ== Received: from [127.0.0.1] by nm43.bullet.mail.gq1.yahoo.com with NNFMP; 06 Sep 2015 21:34:38 -0000 Received: from [216.39.60.184] by nm43.bullet.mail.gq1.yahoo.com with NNFMP; 06 Sep 2015 21:31:51 -0000 Received: from [98.139.170.181] by tm20.bullet.mail.gq1.yahoo.com with NNFMP; 06 Sep 2015 21:31:51 -0000 Received: from [98.139.212.194] by tm24.bullet.mail.bf1.yahoo.com with NNFMP; 06 Sep 2015 21:31:51 -0000 Received: from [127.0.0.1] by omp1003.mail.bf1.yahoo.com with NNFMP; 06 Sep 2015 21:31:51 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 151310.20910.bm@omp1003.mail.bf1.yahoo.com Received: (qmail 66931 invoked by uid 60001); 6 Sep 2015 21:31:51 -0000 X-YMail-OSG: Kl6J9WkVM1lN9VwLqb0FxMVD3hCKIRdTXYe4gkG0FYsJw5S hpMJvXpoZxkPegdcFclZCif_aaRT8jkPlScm8cVJ.lblaTP1delg8XBkXlld 2GOilxUXZTAB.RMKYthluvkenEJ3EFbdxHLNIBxlPePiXnUZTTiGJRZEQiRm 6WLrQ0IeGCyie6b0mVUQ8Kfn6Bg_h6vdgOYBFeLOsBNujL76l_tyu7k5XdYW UJKZJ6uZwKQQcAcC1XhVQV8_QvWykX6bwgcmPCXNxqyFcNIXPQB6LDCQqlDS bPwCMz1onat_ZLyAhj.G5V35_CVNbwftih0FBWPOS8H7sLFB87S9hP_erapQ Q0f0ol53H18LkkkBY9A1fRhTy.EVtDAIxbBYmKey8w4boax6LTY0NphCKA3w SPJPRKpAHNRoxSOUANCp8GbdmdUIFInyeL6KKUiEe0hPuVqJTQ.C4RURXCb0 UtcL0B5O7dpzFtDVTm6Jlgt73jPJQusZ0n5ue9yIQmDEc6BU_049qMfU1ciL _1CidzrqvBjijnEDTkqFQq7_Egok81KsjVrOvJN7L_waKvE5YIPckFS7ls0. NRbWpAoqXJKxuv9ze6sh7NimhtyXRxRuD Received: from [151.238.53.33] by web165005.mail.bf1.yahoo.com via HTTP; Sun, 06 Sep 2015 14:31:51 PDT X-Rocket-MIMEInfo: 002.001, DQpUaGFuayB5b3UgZ3V5cyBmb3IgeW91ciBhbnN3ZXJzLg0KDQpPbiBTYXQsIFNlcCA1LCAyMDE1IGF0IDI6NDQgUE0sIEx1aWdpIFJpenpvIDxyaXp6b0BpZXQudW5pcGkuaXQ.IHdyb3RlOg0KPiBZb3UgbWF5IGJlIGFibGUgdG8gYXZvaWQgdGhlIGlzc3VlIGlmIHlvdSBhdm9pZCBhdXRvbmVnb3RpYXRpb24NCj4gYW5kIG1hbnVhbGx5IHNldCB0aGUgbWVkaWEgdHlwZSwgc3BlZWQgYW5kIGR1cGxleC4NCg0KT24gU3VuLCA5LzYvMTUsIEFydGVtIEJlbGV2aWNoIDxhcnRlbWJAZ21haWwuY29tPiB3cm90ZToBMAEBAQE- X-Mailer: YahooMailBasic/651 YahooMailWebService/0.8.203.813 Message-ID: <1441575111.13185.YahooMailBasic@web165005.mail.bf1.yahoo.com> Date: Sun, 6 Sep 2015 14:31:51 -0700 From: "M. V." Subject: Re: Problem with receiving packets right after remote-interface is up To: Artem Belevich Cc: "freebsd-net@freebsd.org" , Luigi Rizzo In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2015 21:37:47 -0000 Thank you guys for your answers. On Sat, Sep 5, 2015 at 2:44 PM, Luigi Rizzo wrote: > You may be able to avoid the issue if you avoid autonegotiation > and manually set the media type, speed and duplex. On Sun, 9/6/15, Artem Belevich wrote: > While you can indeed set speed/duplex manually, you will > also need to make sure both have have proper clock > master/slave selection which is normally done via autonegotiation. > ... I continued tests today based on what you said about auto-negotiation might cause the problem. A thing I found out today was that, even if I put about 3 seconds (or less) delay between "up"ing interface of sender, and sending packets, packet-drop would occur. but if I put 4 seconds delay or more between bringing link up and sending, no drop will occur. About disabling auto-negotiation and media options: My interfaces didn't support master/slave option. I changed interface media to both "1000BASET" and "100BASETX" instead of auto, but problem was still there. but interestingly, when I changed receiver's media to "10BASET" (other side was still auto) no packet-drop occurred (even when I removed the delay between bringing up interface and sending packets). I checked e1000 and em driver codes to find out what is driver doing differently when we set media to 10BASET that makes my tests succeed, but found nothing. Any ideas? On Sun, 9/6/15, Artem Belevich wrote: > It sounds to me like the problem is with your test setup. If > your test requires no packet drops, then it implicitly > assumes having established link and sending the packets > right after the interface Unfortunately we can't change test setup. Spirent Test-Center device runs the tests and gives up the detailed result about what happened, and these drops cause most tests to FAIL at the beginning and doesn't continue. Thank you. From owner-freebsd-net@freebsd.org Mon Sep 7 01:24:01 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3C749CB241 for ; Mon, 7 Sep 2015 01:24:01 +0000 (UTC) (envelope-from gondim@bsdinfo.com.br) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [191.243.120.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 88DA6BBB for ; Mon, 7 Sep 2015 01:24:01 +0000 (UTC) (envelope-from gondim@bsdinfo.com.br) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id A40EC30FCCB for ; Sun, 6 Sep 2015 22:16:06 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-transfer-encoding:content-type:content-type:subject :subject:to:mime-version:user-agent:from:from:date:date :message-id; s=dkim; t=1441588562; x=1442452563; bh=PtY3pOpPMjtR qpDBID7APu4PabJeEATNwxw0nhPwyF4=; b=KS1veElqpY9EVBmO3ru7f4KxYO/C uENpbJryBU59+9L8E0w2oUrBmCBavx8PIgYeeiZdFoWMzb1lY/SzDOylYp156Mnm yJr5Whc8dOwn/TApb4eqAx0q+NPWa6OCp70xz3x/KIHDaPqVfGAz3xLMZOi56wUP tLoKyhkIjnlkp8I= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YygxAKNOA-Ci for ; Sun, 6 Sep 2015 22:16:02 -0300 (BRT) Received: from [192.168.10.208] (unknown [186.193.54.69]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id DAA1730FCBD for ; Sun, 6 Sep 2015 22:16:02 -0300 (BRT) Message-ID: <55ECE515.3080104@bsdinfo.com.br> Date: Sun, 06 Sep 2015 22:15:01 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: FreeBSD Net Subject: Tuning for Intel X520-SR2 and Intel i350-T2 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 01:24:02 -0000 Hi all, I have a router FreeBSD 10.2-RELEASE-p2 with one network card Intel X520-SR2 and two cards Intel i350-T2. My hardware: - Motherboard Intel S2600COE [1] - Dual Hexa Xeon: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz - 18Gb ram - Downstream traffic 4Gbps Is there any tuning to reduce the use of network outages? My top below: last pid: 8196; load averages: 17.98, 17.52, 17.21 up 1+23:05:25 21:45:05 32 processes: 1 running, 31 sleeping CPU 0: 0.4% user, 0.0% nice, 0.4% system, 37.0% interrupt, 62.2% idle CPU 1: 0.0% user, 0.0% nice, 0.0% system, 50.4% interrupt, 49.6% idle CPU 2: 0.8% user, 0.0% nice, 0.0% system, 46.9% interrupt, 52.4% idle CPU 3: 0.0% user, 0.0% nice, 0.0% system, 65.7% interrupt, 34.3% idle CPU 4: 0.0% user, 0.0% nice, 0.0% system, 62.6% interrupt, 37.4% idle CPU 5: 0.0% user, 0.0% nice, 0.4% system, 63.0% interrupt, 36.6% idle CPU 6: 0.0% user, 0.0% nice, 0.0% system, 63.8% interrupt, 36.2% idle CPU 7: 0.4% user, 0.0% nice, 0.0% system, 33.1% interrupt, 66.5% idle CPU 8: 0.0% user, 0.0% nice, 0.0% system, 64.6% interrupt, 35.4% idle CPU 9: 0.4% user, 0.0% nice, 0.0% system, 33.5% interrupt, 66.1% idle CPU 10: 0.4% user, 0.0% nice, 0.8% system, 36.6% interrupt, 62.2% idle CPU 11: 0.8% user, 0.0% nice, 0.4% system, 31.9% interrupt, 66.9% idle My sysctl.conf: net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 net.inet6.ip6.forwarding=1 kern.ipc.somaxconn=4096 net.inet.tcp.syncookies=1 net.inet.ip.redirect=1 net.inet.ip.accept_sourceroute=0 net.inet.ip.sourceroute=0 net.inet.tcp.drop_synfin=1 net.inet.udp.blackhole=1 net.inet.tcp.blackhole=2 security.bsd.see_other_uids=0 net.inet.ip.fw.dyn_buckets=65536 net.inet.ip.fw.dyn_max=65536 hw.intr_storm_threshold=9000 net.inet.ip.dummynet.pipe_slot_limit=800 net.inet.icmp.icmplim=2000 My loader.conf: loader_logo="beastie" if_lagg_load="YES" speaker_load="YES" aio_load="YES" autoboot_delay="5" net.fibs=1 kern.hz=2000 My firewall rules: (root@rt01)[~]# ipfw show 00100 400 134880 allow ip from any to any via lo0 00200 0 0 deny ip from 127.0.0.0/8 to any 00300 0 0 deny ip from ::1 to any 00400 0 0 deny ip from any to 127.0.0.0/8 00500 0 0 deny ip from any to ::1 00600 7381651 499415987 deny ip from not table(3) to any in recv vlan0 00700 4011900 222326864 deny ip from not table(3) to any in recv vlan1 00800 1287607 84935306 deny ip from not table(3) to any in recv vlan2 00900 2152212 128056358 deny ip from not table(3) to any in recv vlan3 01000 0 0 deny ip from not table(3) to any in recv vlan7 01100 0 0 deny ip from not table(3) to any in recv vlan5 01200 0 0 deny ip from not table(3) to any in recv vlan6 01300 0 0 deny ip from not table(3) to any in recv vlan8 01400 0 0 check-state 01500 1543 96723 deny tcp from any to any in tcpflags fin,psh,urg 01600 785 265717 deny tcp from any to any in tcpflags !syn,!fin,!ack,!psh,!rst,!urg 01700 633 49047 deny tcp from any to any in tcpflags syn,fin 01800 20620 828603 deny tcp from any to any in tcpflags fin,rst 01900 0 0 deny ip from any to any in ipoptions ssrr,lsrr,rr,ts 02000 0 0 deny ip from table(99) to any in via igb4 02100 0 0 deny ip from table(99) to any in via igb5 02200 75031 11544750 deny ip from table(99) to any in via igb1 02300 340077 17057941 deny ip from table(1) to any 02400 0 0 deny log logamount 100 ip from any to table(2) 02500 21858 1661959 allow udp from 186.xxx.xxx.3 to me dst-port 161 in via vlan0 keep-state 02600 0 0 allow tcp from 186.xxx.xxx.3 to me dst-port 199 in via vlan0 setup keep-state 02700 100 8128 deny udp from any to me dst-port 161 02800 0 0 deny tcp from any to me dst-port 199 65535 158071018941 121039458717515 allow ip from any to any My /etc/rc.local (cpu affinity): #!/bin/sh echo "SO4L16G>L8C." > /dev/speaker /usr/bin/cpuset -l 0 /usr/local/sbin/bgpd /usr/bin/cpuset -l 5 -x 300 /usr/bin/cpuset -l 4 -x 301 /usr/bin/cpuset -l 3 -x 302 /usr/bin/cpuset -l 2 -x 303 /usr/bin/cpuset -l 1 -x 304 /usr/bin/cpuset -l 0 -x 305 /usr/bin/cpuset -l 0 -x 306 /usr/bin/cpuset -l 1 -x 307 /usr/bin/cpuset -l 2 -x 308 /usr/bin/cpuset -l 3 -x 309 /usr/bin/cpuset -l 4 -x 310 /usr/bin/cpuset -l 5 -x 311 /usr/bin/cpuset -l 5 -x 312 /usr/bin/cpuset -l 4 -x 313 /usr/bin/cpuset -l 3 -x 314 /usr/bin/cpuset -l 2 -x 315 /usr/bin/cpuset -l 1 -x 316 /usr/bin/cpuset -l 0 -x 317 /usr/bin/cpuset -l 0 -x 318 /usr/bin/cpuset -l 1 -x 319 /usr/bin/cpuset -l 2 -x 320 /usr/bin/cpuset -l 3 -x 321 /usr/bin/cpuset -l 4 -x 322 /usr/bin/cpuset -l 5 -x 323 /usr/bin/cpuset -l 5 -x 324 /usr/bin/cpuset -l 4 -x 325 /usr/bin/cpuset -l 3 -x 326 /usr/bin/cpuset -l 2 -x 327 /usr/bin/cpuset -l 1 -x 328 /usr/bin/cpuset -l 0 -x 329 /usr/bin/cpuset -l 0 -x 330 /usr/bin/cpuset -l 1 -x 331 /usr/bin/cpuset -l 2 -x 332 /usr/bin/cpuset -l 3 -x 333 /usr/bin/cpuset -l 4 -x 334 /usr/bin/cpuset -l 5 -x 335 /usr/bin/cpuset -l 5 -x 264 /usr/bin/cpuset -l 4 -x 265 /usr/bin/cpuset -l 3 -x 266 /usr/bin/cpuset -l 2 -x 267 /usr/bin/cpuset -l 1 -x 268 /usr/bin/cpuset -l 0 -x 269 /usr/bin/cpuset -l 0 -x 270 /usr/bin/cpuset -l 1 -x 271 /usr/bin/cpuset -l 2 -x 272 /usr/bin/cpuset -l 3 -x 273 /usr/bin/cpuset -l 4 -x 274 /usr/bin/cpuset -l 5 -x 275 /usr/bin/cpuset -l 5 -x 276 /usr/bin/cpuset -l 4 -x 277 /usr/bin/cpuset -l 3 -x 278 /usr/bin/cpuset -l 2 -x 279 /usr/bin/cpuset -l 1 -x 280 /usr/bin/cpuset -l 0 -x 281 /usr/bin/cpuset -l 0 -x 282 /usr/bin/cpuset -l 1 -x 283 /usr/bin/cpuset -l 2 -x 284 /usr/bin/cpuset -l 3 -x 285 /usr/bin/cpuset -l 4 -x 286 /usr/bin/cpuset -l 5 -x 287 /usr/bin/cpuset -l 5 -x 288 /usr/bin/cpuset -l 4 -x 289 /usr/bin/cpuset -l 3 -x 290 /usr/bin/cpuset -l 2 -x 291 /usr/bin/cpuset -l 1 -x 292 /usr/bin/cpuset -l 0 -x 293 /usr/bin/cpuset -l 0 -x 294 /usr/bin/cpuset -l 1 -x 295 /usr/bin/cpuset -l 2 -x 296 /usr/bin/cpuset -l 3 -x 297 /usr/bin/cpuset -l 4 -x 298 /usr/bin/cpuset -l 5 -x 299 /usr/bin/cpuset -l 11 -x 337 /usr/bin/cpuset -l 10 -x 338 /usr/bin/cpuset -l 9 -x 339 /usr/bin/cpuset -l 8 -x 340 /usr/bin/cpuset -l 7 -x 341 /usr/bin/cpuset -l 6 -x 342 /usr/bin/cpuset -l 6 -x 343 /usr/bin/cpuset -l 8 -x 344 /usr/bin/cpuset -l 8 -x 345 /usr/bin/cpuset -l 9 -x 346 /usr/bin/cpuset -l 10 -x 347 /usr/bin/cpuset -l 11 -x 348 /usr/bin/cpuset -l 11 -x 349 /usr/bin/cpuset -l 10 -x 350 /usr/bin/cpuset -l 9 -x 351 /usr/bin/cpuset -l 8 -x 352 /usr/bin/cpuset -l 7 -x 353 /usr/bin/cpuset -l 6 -x 354 ix0: flags=8843 metric 0 mtu 1500 options=8407bb ether a0:36:9f:2a:6d:ac inet6 fe80::a236:9fff:fe2a:6dac%ix0 prefixlen 64 scopeid 0x9 nd6 options=21 media: Ethernet autoselect (10Gbase-LR ) status: active ix1: flags=8843 metric 0 mtu 1500 options=8407bb ether a0:36:9f:2a:6d:ae inet6 fe80::a236:9fff:fe2a:6dae%ix1 prefixlen 64 scopeid 0xa nd6 options=21 media: Ethernet autoselect (10Gbase-SR ) status: active igb4: flags=8843 metric 0 mtu 1500 options=403bb ether 00:1b:21:7b:ee:6c inet6 fe80::21e:67ff:fe9b:3e1%igb4 prefixlen 64 scopeid 0x5 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active igb5: flags=8843 metric 0 mtu 1500 options=403bb ether 00:1b:21:7b:ee:6c inet6 fe80::21e:67ff:fe9b:3e1%igb5 prefixlen 64 scopeid 0x6 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active igb6: flags=8843 metric 0 mtu 1500 options=403bb ether 00:1b:21:7b:ee:98 inet6 fe80::21e:67ff:fe9b:3e1%igb6 prefixlen 64 scopeid 0x7 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active igb7: flags=8843 metric 0 mtu 1500 options=403bb ether 00:1b:21:7b:ee:98 inet6 fe80::21e:67ff:fe9b:3e1%igb7 prefixlen 64 scopeid 0x8 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active [1] http://download.intel.com/support/motherboards/server/s2600co/sb/g42278004_s2600co_tps_rev171.pdf Thanks and best regards, From owner-freebsd-net@freebsd.org Mon Sep 7 01:41:18 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A0019CBDDB for ; Mon, 7 Sep 2015 01:41:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 36A35619 for ; Mon, 7 Sep 2015 01:41:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t871fI4B002168 for ; Mon, 7 Sep 2015 01:41:18 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202907] 10.2 on SolarFlare SFN5162F 10Gb/s NIC missing out traffic Date: Mon, 07 Sep 2015 01:41:16 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: component assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 01:41:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202907 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Component|tests |kern Assignee|freebsd-testing@freebsd.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Mon Sep 7 03:04:02 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23DB69CC973 for ; Mon, 7 Sep 2015 03:04:02 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DDD80C09 for ; Mon, 7 Sep 2015 03:04:01 +0000 (UTC) (envelope-from artemb@gmail.com) Received: by oiev17 with SMTP id v17so37741571oie.1 for ; Sun, 06 Sep 2015 20:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iMenBMpKIG2PG6vb4HbXjXwUpkDsMydpQH97m45i8Ws=; b=P7Ebj0ms1IGlkY8TWai5S5EgIXFowI20CI/zTMG/uk4GrMPyus4hqKRffdvCSyfiw+ zu5EUpDmR3wZb7VxYya7Lnawkxng5tbEAzRVPQXJqHClCjxIR5Bq86AbN5o63vh9kod0 CgkojN7ndW30HaNKbKeRUGmHcq6MgH89mq00suFv56wc2QBJndRU3qxW8NdV0NZZWVz2 Yy93nGZieADZF7QKowb8mQQ+tbY5BFaGtSkIt2Rsym8t3OgcAnM/LSn5YNdfiJ73mCLL Rlpie/dPhHgjEQCE8NdOeTn2ejj8cRhpmkIiT7LtpF6UNyxmWIMGx2tPK3KVox+JZGo8 td2Q== MIME-Version: 1.0 X-Received: by 10.202.93.7 with SMTP id r7mr12605288oib.124.1441595041103; Sun, 06 Sep 2015 20:04:01 -0700 (PDT) Received: by 10.202.83.74 with HTTP; Sun, 6 Sep 2015 20:04:01 -0700 (PDT) In-Reply-To: <1441575111.13185.YahooMailBasic@web165005.mail.bf1.yahoo.com> References: <1441575111.13185.YahooMailBasic@web165005.mail.bf1.yahoo.com> Date: Sun, 6 Sep 2015 20:04:01 -0700 Message-ID: Subject: Re: Problem with receiving packets right after remote-interface is up From: Artem Belevich To: "M. V." Cc: "freebsd-net@freebsd.org" , Luigi Rizzo Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 03:04:02 -0000 On Sun, Sep 6, 2015 at 2:31 PM, M. V. wrote: > > About disabling auto-negotiation and media options: > My interfaces didn't support master/slave option. I changed interface > media to both "1000BASET" and "100BASETX" instead of auto, but problem was > still there. but interestingly, when I changed receiver's media to > "10BASET" (other side was still auto) no packet-drop occurred (even when I > removed the delay between bringing up interface and sending packets). > > Even though 10/100/1000 Ethernet uses more or less same wires, the ways they transmit signals over the wire are *very* different. 10BaseT is very forgiving signal-integrity-wise, so bringing up the link is almost instantaneous if there's no autonegotiation. 1000Base-T, on the other hand, requires fair amount of time to measure electrical properties of the cable and adjust PHY parameters to compensate for them. That takes fair amount of time even if you have disabled autonegotiation. > I checked e1000 and em driver codes to find out what is driver doing > differently when we set media to 10BASET that makes my tests succeed, but > found nothing. Any ideas? > > It all happens on physical level. Driver usually has little control over that other than telling PHY to establish the link and controlling autonegotiation parameters, so 10BaseT and 1000Base-T will look roughly the same. > On Sun, 9/6/15, Artem Belevich wrote: > > It sounds to me like the problem is with your test setup. If > > your test requires no packet drops, then it implicitly > > assumes having established link and sending the packets > > right after the interface > > Unfortunately we can't change test setup. Spirent Test-Center device runs > the tests and gives up the detailed result about what happened, and these > drops cause most tests to FAIL at the beginning and doesn't continue. > >From what you've described, FreeBSD box's behavior appears to be normal. Did you talk to Spirent support? I would expect them to have a way to either avoid bringing physical link down, or delaying RX/TX until link is up. SmartBits and Ixia boxes I dealt with before used to have plenty of controls over their interfaces. I suspect Spirent does, too. --Artem From owner-freebsd-net@freebsd.org Mon Sep 7 05:15:57 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0584E9CCB59 for ; Mon, 7 Sep 2015 05:15:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C6F87B04 for ; Mon, 7 Sep 2015 05:15:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by ioii196 with SMTP id i196so77656335ioi.3 for ; Sun, 06 Sep 2015 22:15:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xBEjizrjuugQFw1c2fqJLUlmlq1HtYkwcb9gtE7YeMQ=; b=R3SokpTSQKMOk6MyWf4Www5DKqRe4bgskJYdADfTqrZ+22jkAa7Zioyh3X6IeRdlAf S53pjqUtPy4PUUQd1LPNzp9t9yHAkcdFxWbNPyrGeahB6U2RI8qeBfLfzmh96T9UxhnY 94l5VA74VekuMTBWI0A7mMKLAOsNTWelEMipYCU4Ts7ieGv6YuQWhG5HifqauQjIqfWG us0WjwK3Gmo4hQ2xxKRc6DvgRDgjU8NuKh5CDSLLKvWeAbidb6xcquBGHyzEje8SONo3 0It0gSJNuSQJk2n3gEJGlT4xBJSlkG/j6IJ0gaoKcU8kCKv9hJxSr9aSoWcvOZPMWrl5 w54Q== MIME-Version: 1.0 X-Received: by 10.107.154.212 with SMTP id c203mr24360319ioe.123.1441602956098; Sun, 06 Sep 2015 22:15:56 -0700 (PDT) Received: by 10.36.28.208 with HTTP; Sun, 6 Sep 2015 22:15:56 -0700 (PDT) In-Reply-To: <55ECE515.3080104@bsdinfo.com.br> References: <55ECE515.3080104@bsdinfo.com.br> Date: Sun, 6 Sep 2015 22:15:56 -0700 Message-ID: Subject: Re: Tuning for Intel X520-SR2 and Intel i350-T2 From: Adrian Chadd To: Marcelo Gondim Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 05:15:57 -0000 What's the actual problem? What are you seeing? (For 10.2, please read the errata notice on ixgbe and disabling the flowdirector code.) -adrian On 6 September 2015 at 18:15, Marcelo Gondim wrote: > Hi all, > > I have a router FreeBSD 10.2-RELEASE-p2 with one network card Intel X520-SR2 > and two cards Intel i350-T2. > > My hardware: > > - Motherboard Intel S2600COE [1] > - Dual Hexa Xeon: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz > - 18Gb ram > - Downstream traffic 4Gbps > > Is there any tuning to reduce the use of network outages? > > My top below: > > last pid: 8196; load averages: 17.98, 17.52, 17.21 up 1+23:05:25 21:45:05 > 32 processes: 1 running, 31 sleeping > CPU 0: 0.4% user, 0.0% nice, 0.4% system, 37.0% interrupt, 62.2% idle > CPU 1: 0.0% user, 0.0% nice, 0.0% system, 50.4% interrupt, 49.6% idle > CPU 2: 0.8% user, 0.0% nice, 0.0% system, 46.9% interrupt, 52.4% idle > CPU 3: 0.0% user, 0.0% nice, 0.0% system, 65.7% interrupt, 34.3% idle > CPU 4: 0.0% user, 0.0% nice, 0.0% system, 62.6% interrupt, 37.4% idle > CPU 5: 0.0% user, 0.0% nice, 0.4% system, 63.0% interrupt, 36.6% idle > CPU 6: 0.0% user, 0.0% nice, 0.0% system, 63.8% interrupt, 36.2% idle > CPU 7: 0.4% user, 0.0% nice, 0.0% system, 33.1% interrupt, 66.5% idle > CPU 8: 0.0% user, 0.0% nice, 0.0% system, 64.6% interrupt, 35.4% idle > CPU 9: 0.4% user, 0.0% nice, 0.0% system, 33.5% interrupt, 66.1% idle > CPU 10: 0.4% user, 0.0% nice, 0.8% system, 36.6% interrupt, 62.2% idle > CPU 11: 0.8% user, 0.0% nice, 0.4% system, 31.9% interrupt, 66.9% idle > > My sysctl.conf: > > net.inet.ip.forwarding=1 > net.inet.ip.fastforwarding=1 > net.inet6.ip6.forwarding=1 > kern.ipc.somaxconn=4096 > net.inet.tcp.syncookies=1 > net.inet.ip.redirect=1 > net.inet.ip.accept_sourceroute=0 > net.inet.ip.sourceroute=0 > net.inet.tcp.drop_synfin=1 > net.inet.udp.blackhole=1 > net.inet.tcp.blackhole=2 > security.bsd.see_other_uids=0 > net.inet.ip.fw.dyn_buckets=65536 > net.inet.ip.fw.dyn_max=65536 > hw.intr_storm_threshold=9000 > net.inet.ip.dummynet.pipe_slot_limit=800 > net.inet.icmp.icmplim=2000 > > My loader.conf: > > loader_logo="beastie" > if_lagg_load="YES" > speaker_load="YES" > aio_load="YES" > autoboot_delay="5" > net.fibs=1 > kern.hz=2000 > > My firewall rules: > > (root@rt01)[~]# ipfw show > 00100 400 134880 allow ip from any to any via lo0 > 00200 0 0 deny ip from 127.0.0.0/8 to any > 00300 0 0 deny ip from ::1 to any > 00400 0 0 deny ip from any to 127.0.0.0/8 > 00500 0 0 deny ip from any to ::1 > 00600 7381651 499415987 deny ip from not table(3) to any in recv > vlan0 > 00700 4011900 222326864 deny ip from not table(3) to any in recv > vlan1 > 00800 1287607 84935306 deny ip from not table(3) to any in recv > vlan2 > 00900 2152212 128056358 deny ip from not table(3) to any in recv > vlan3 > 01000 0 0 deny ip from not table(3) to any in recv > vlan7 > 01100 0 0 deny ip from not table(3) to any in recv > vlan5 > 01200 0 0 deny ip from not table(3) to any in recv > vlan6 > 01300 0 0 deny ip from not table(3) to any in recv > vlan8 > 01400 0 0 check-state > 01500 1543 96723 deny tcp from any to any in tcpflags > fin,psh,urg > 01600 785 265717 deny tcp from any to any in tcpflags > !syn,!fin,!ack,!psh,!rst,!urg > 01700 633 49047 deny tcp from any to any in tcpflags > syn,fin > 01800 20620 828603 deny tcp from any to any in tcpflags > fin,rst > 01900 0 0 deny ip from any to any in ipoptions > ssrr,lsrr,rr,ts > 02000 0 0 deny ip from table(99) to any in via igb4 > 02100 0 0 deny ip from table(99) to any in via igb5 > 02200 75031 11544750 deny ip from table(99) to any in via igb1 > 02300 340077 17057941 deny ip from table(1) to any > 02400 0 0 deny log logamount 100 ip from any to > table(2) > 02500 21858 1661959 allow udp from 186.xxx.xxx.3 to me > dst-port 161 in via vlan0 keep-state > 02600 0 0 allow tcp from 186.xxx.xxx.3 to me > dst-port 199 in via vlan0 setup keep-state > 02700 100 8128 deny udp from any to me dst-port 161 > 02800 0 0 deny tcp from any to me dst-port 199 > 65535 158071018941 121039458717515 allow ip from any to any > > > My /etc/rc.local (cpu affinity): > > #!/bin/sh > echo "SO4L16G>L8C." > /dev/speaker > /usr/bin/cpuset -l 0 /usr/local/sbin/bgpd > /usr/bin/cpuset -l 5 -x 300 > /usr/bin/cpuset -l 4 -x 301 > /usr/bin/cpuset -l 3 -x 302 > /usr/bin/cpuset -l 2 -x 303 > /usr/bin/cpuset -l 1 -x 304 > /usr/bin/cpuset -l 0 -x 305 > /usr/bin/cpuset -l 0 -x 306 > /usr/bin/cpuset -l 1 -x 307 > /usr/bin/cpuset -l 2 -x 308 > /usr/bin/cpuset -l 3 -x 309 > /usr/bin/cpuset -l 4 -x 310 > /usr/bin/cpuset -l 5 -x 311 > /usr/bin/cpuset -l 5 -x 312 > /usr/bin/cpuset -l 4 -x 313 > /usr/bin/cpuset -l 3 -x 314 > /usr/bin/cpuset -l 2 -x 315 > /usr/bin/cpuset -l 1 -x 316 > /usr/bin/cpuset -l 0 -x 317 > /usr/bin/cpuset -l 0 -x 318 > /usr/bin/cpuset -l 1 -x 319 > /usr/bin/cpuset -l 2 -x 320 > /usr/bin/cpuset -l 3 -x 321 > /usr/bin/cpuset -l 4 -x 322 > /usr/bin/cpuset -l 5 -x 323 > /usr/bin/cpuset -l 5 -x 324 > /usr/bin/cpuset -l 4 -x 325 > /usr/bin/cpuset -l 3 -x 326 > /usr/bin/cpuset -l 2 -x 327 > /usr/bin/cpuset -l 1 -x 328 > /usr/bin/cpuset -l 0 -x 329 > /usr/bin/cpuset -l 0 -x 330 > /usr/bin/cpuset -l 1 -x 331 > /usr/bin/cpuset -l 2 -x 332 > /usr/bin/cpuset -l 3 -x 333 > /usr/bin/cpuset -l 4 -x 334 > /usr/bin/cpuset -l 5 -x 335 > /usr/bin/cpuset -l 5 -x 264 > /usr/bin/cpuset -l 4 -x 265 > /usr/bin/cpuset -l 3 -x 266 > /usr/bin/cpuset -l 2 -x 267 > /usr/bin/cpuset -l 1 -x 268 > /usr/bin/cpuset -l 0 -x 269 > /usr/bin/cpuset -l 0 -x 270 > /usr/bin/cpuset -l 1 -x 271 > /usr/bin/cpuset -l 2 -x 272 > /usr/bin/cpuset -l 3 -x 273 > /usr/bin/cpuset -l 4 -x 274 > /usr/bin/cpuset -l 5 -x 275 > /usr/bin/cpuset -l 5 -x 276 > /usr/bin/cpuset -l 4 -x 277 > /usr/bin/cpuset -l 3 -x 278 > /usr/bin/cpuset -l 2 -x 279 > /usr/bin/cpuset -l 1 -x 280 > /usr/bin/cpuset -l 0 -x 281 > /usr/bin/cpuset -l 0 -x 282 > /usr/bin/cpuset -l 1 -x 283 > /usr/bin/cpuset -l 2 -x 284 > /usr/bin/cpuset -l 3 -x 285 > /usr/bin/cpuset -l 4 -x 286 > /usr/bin/cpuset -l 5 -x 287 > /usr/bin/cpuset -l 5 -x 288 > /usr/bin/cpuset -l 4 -x 289 > /usr/bin/cpuset -l 3 -x 290 > /usr/bin/cpuset -l 2 -x 291 > /usr/bin/cpuset -l 1 -x 292 > /usr/bin/cpuset -l 0 -x 293 > /usr/bin/cpuset -l 0 -x 294 > /usr/bin/cpuset -l 1 -x 295 > /usr/bin/cpuset -l 2 -x 296 > /usr/bin/cpuset -l 3 -x 297 > /usr/bin/cpuset -l 4 -x 298 > /usr/bin/cpuset -l 5 -x 299 > /usr/bin/cpuset -l 11 -x 337 > /usr/bin/cpuset -l 10 -x 338 > /usr/bin/cpuset -l 9 -x 339 > /usr/bin/cpuset -l 8 -x 340 > /usr/bin/cpuset -l 7 -x 341 > /usr/bin/cpuset -l 6 -x 342 > /usr/bin/cpuset -l 6 -x 343 > /usr/bin/cpuset -l 8 -x 344 > /usr/bin/cpuset -l 8 -x 345 > /usr/bin/cpuset -l 9 -x 346 > /usr/bin/cpuset -l 10 -x 347 > /usr/bin/cpuset -l 11 -x 348 > /usr/bin/cpuset -l 11 -x 349 > /usr/bin/cpuset -l 10 -x 350 > /usr/bin/cpuset -l 9 -x 351 > /usr/bin/cpuset -l 8 -x 352 > /usr/bin/cpuset -l 7 -x 353 > /usr/bin/cpuset -l 6 -x 354 > > ix0: flags=8843 metric 0 mtu 1500 > options=8407bb > ether a0:36:9f:2a:6d:ac > inet6 fe80::a236:9fff:fe2a:6dac%ix0 prefixlen 64 scopeid 0x9 > nd6 options=21 > media: Ethernet autoselect (10Gbase-LR > ) > status: active > > ix1: flags=8843 metric 0 mtu 1500 > options=8407bb > ether a0:36:9f:2a:6d:ae > inet6 fe80::a236:9fff:fe2a:6dae%ix1 prefixlen 64 scopeid 0xa > nd6 options=21 > media: Ethernet autoselect (10Gbase-SR > ) > status: active > > igb4: flags=8843 metric 0 mtu 1500 > options=403bb > ether 00:1b:21:7b:ee:6c > inet6 fe80::21e:67ff:fe9b:3e1%igb4 prefixlen 64 scopeid 0x5 > nd6 options=21 > media: Ethernet autoselect (1000baseT ) > status: active > > igb5: flags=8843 metric 0 mtu 1500 > options=403bb > ether 00:1b:21:7b:ee:6c > inet6 fe80::21e:67ff:fe9b:3e1%igb5 prefixlen 64 scopeid 0x6 > nd6 options=21 > media: Ethernet autoselect (1000baseT ) > status: active > > igb6: flags=8843 metric 0 mtu 1500 > options=403bb > ether 00:1b:21:7b:ee:98 > inet6 fe80::21e:67ff:fe9b:3e1%igb6 prefixlen 64 scopeid 0x7 > nd6 options=21 > media: Ethernet autoselect (1000baseT ) > status: active > > igb7: flags=8843 metric 0 mtu 1500 > options=403bb > ether 00:1b:21:7b:ee:98 > inet6 fe80::21e:67ff:fe9b:3e1%igb7 prefixlen 64 scopeid 0x8 > nd6 options=21 > media: Ethernet autoselect (1000baseT ) > status: active > > > [1] > http://download.intel.com/support/motherboards/server/s2600co/sb/g42278004_s2600co_tps_rev171.pdf > > Thanks and best regards, > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://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 Sep 7 06:23:20 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF0A29CCF6E for ; Mon, 7 Sep 2015 06:23:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BBA83B1F for ; Mon, 7 Sep 2015 06:23:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t876NKBE064030 for ; Mon, 7 Sep 2015 06:23:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202907] 10.2 on SolarFlare SFN5162F 10Gb/s NIC missing out traffic Date: Mon, 07 Sep 2015 06:23:21 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ngie@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 06:23:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202907 --- Comment #1 from Garrett Cooper,425-314-3911 --- Not on net, but I figured this bug needs more information before it can be appropriately triaged. Please provide... - ... the ifconfig output for em0/sfxge1. - ... the output of `sysctl hw.sfxge`. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Mon Sep 7 06:27:19 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0AC529CB1B0 for ; Mon, 7 Sep 2015 06:27:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E9B12CF2 for ; Mon, 7 Sep 2015 06:27:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t876RIMU067785 for ; Mon, 7 Sep 2015 06:27:18 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202907] 10.2 on SolarFlare SFN5162F 10Gb/s NIC missing out traffic Date: Mon, 07 Sep 2015 06:27:19 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ngie@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 06:27:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202907 Garrett Cooper,425-314-3911 changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ngie@FreeBSD.org --- Comment #2 from Garrett Cooper,425-314-3911 --- Sidenote: based on code inspection, specifying -i when specifying -I is redundant. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Mon Sep 7 10:28:55 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 504369C847A for ; Mon, 7 Sep 2015 10:28:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 22FE31343 for ; Mon, 7 Sep 2015 10:28:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t87ASt5D089308 for ; Mon, 7 Sep 2015 10:28:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202907] 10.2 on SolarFlare SFN5162F 10Gb/s NIC missing out traffic Date: Mon, 07 Sep 2015 10:28:55 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: presess@spi.net.pl X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 10:28:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202907 --- Comment #3 from presess@spi.net.pl --- Hi, sfxge1: flags=8843 metric 0 mtu 1500 options=6c07ab ether 00:0f:53:08:48:89 inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255 nd6 options=29 media: Ethernet 10Gbase-SR status: active em0: flags=8c02 metric 0 mtu 1500 options=4019b ether 74:d4:35:e7:40:af inet 10.10.2.1 netmask 0xffffff00 broadcast 10.10.2.255 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active root@rtr:/# sysctl -a | grep hw.sfxge hw.sfxge.tso_fw_assisted: 1 hw.sfxge.tx_dpl_put_max: 1024 hw.sfxge.tx_dpl_get_non_tcp_max: 1024 hw.sfxge.tx_dpl_get_max: 65536 hw.sfxge.lro.loss_packets: 20 hw.sfxge.lro.slow_start_packets: 2000 hw.sfxge.lro.idle_ticks: 0 hw.sfxge.lro.chain_max: 20 hw.sfxge.lro.table_size: 128 hw.sfxge.tx_ring: 1024 hw.sfxge.rx_ring: 1024 root@rtr:/# sysctl -a | grep hw.em hw.em.eee_setting: 1 hw.em.rx_process_limit: 100 hw.em.enable_msix: 1 hw.em.sbp: 0 hw.em.smart_pwr_down: 0 hw.em.txd: 1024 hw.em.rxd: 1024 hw.em.rx_abs_int_delay: 66 hw.em.tx_abs_int_delay: 66 hw.em.rx_int_delay: 0 hw.em.tx_int_delay: 66 root@rtr:/# sysctl -a | grep octets dev.em.2.mac_stats.good_octets_txd: 0 dev.em.2.mac_stats.good_octets_recvd: 0 dev.em.1.mac_stats.good_octets_txd: 0 dev.em.1.mac_stats.good_octets_recvd: 0 dev.em.0.mac_stats.good_octets_txd: 456051 dev.em.0.mac_stats.good_octets_recvd: 1531824 dev.sfxge.1.stats.tx_octets: 1087206 dev.sfxge.1.stats.rx_octets: 23345200 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Mon Sep 7 16:28:35 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D41C9CC843 for ; Mon, 7 Sep 2015 16:28:35 +0000 (UTC) (envelope-from gondim@bsdinfo.com.br) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [191.243.120.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 709B01A5B for ; Mon, 7 Sep 2015 16:28:33 +0000 (UTC) (envelope-from gondim@bsdinfo.com.br) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id C761630FCCE for ; Mon, 7 Sep 2015 13:27:38 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-transfer-encoding:content-type:content-type :in-reply-to:references:subject:subject:to:mime-version :user-agent:from:from:date:date:message-id; s=dkim; t= 1441643254; x=1442507255; bh=cyaj9RV2cuSGgkbTruZvfpR4Qavd6ZqL9xn 2hAFOvyY=; b=G8i0Lbt1pBYFvaAdD7pD3Bd6eg3/WI6WbEE82NSYtcag9L4RwLQ oHJbTvEFghcWSHcRBquNlQbd2cdoQ38Q2wvVQ4uDY9TxirU781ExbViAQaefrL3v ykUE2Ga5Ci8D++++b9hHwVo2tfg0K227G15N1VicPjeMoymXWd3Tc/14= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTLeoCq9_SUf for ; Mon, 7 Sep 2015 13:27:34 -0300 (BRT) Received: from [192.168.10.208] (unknown [186.193.54.69]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id 0BF0C30FCC3; Mon, 7 Sep 2015 13:27:34 -0300 (BRT) Message-ID: <55EDBAB8.4050400@bsdinfo.com.br> Date: Mon, 07 Sep 2015 13:26:32 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Adrian Chadd CC: FreeBSD Net Subject: Re: Tuning for Intel X520-SR2 and Intel i350-T2 References: <55ECE515.3080104@bsdinfo.com.br> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 16:28:35 -0000 On 07-09-2015 02:15, Adrian Chadd wrote: > What's the actual problem? What are you seeing? > > (For 10.2, please read the errata notice on ixgbe and disabling the > flowdirector code.) > > > > -adrian Hi Adrian, This problem would be not only in 10.1? Below is saying that only affected 10.1. Topic: Disable ixgbe(4) flow-director support Category: core Module: ixgbe Announced: 2015-08-25 Credits: Marc De La Gueronniere (Verisign, Inc.) Affects: FreeBSD 10.1 Corrected: 2014-10-11 22:10:39 UTC (stable/10, 10.1-STABLE) 2015-08-25 20:48:58 UTC (releng/10.1, 10.1-RELEASE-p19) I'm just looking for some tuning that reduces the use of interruptions of the network interfaces. > > > On 6 September 2015 at 18:15, Marcelo Gondim wrote: >> Hi all, >> >> I have a router FreeBSD 10.2-RELEASE-p2 with one network card Intel X520-SR2 >> and two cards Intel i350-T2. >> >> My hardware: >> >> - Motherboard Intel S2600COE [1] >> - Dual Hexa Xeon: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz >> - 18Gb ram >> - Downstream traffic 4Gbps >> >> Is there any tuning to reduce the use of network outages? >> >> My top below: >> >> last pid: 8196; load averages: 17.98, 17.52, 17.21 up 1+23:05:25 21:45:05 >> 32 processes: 1 running, 31 sleeping >> CPU 0: 0.4% user, 0.0% nice, 0.4% system, 37.0% interrupt, 62.2% idle >> CPU 1: 0.0% user, 0.0% nice, 0.0% system, 50.4% interrupt, 49.6% idle >> CPU 2: 0.8% user, 0.0% nice, 0.0% system, 46.9% interrupt, 52.4% idle >> CPU 3: 0.0% user, 0.0% nice, 0.0% system, 65.7% interrupt, 34.3% idle >> CPU 4: 0.0% user, 0.0% nice, 0.0% system, 62.6% interrupt, 37.4% idle >> CPU 5: 0.0% user, 0.0% nice, 0.4% system, 63.0% interrupt, 36.6% idle >> CPU 6: 0.0% user, 0.0% nice, 0.0% system, 63.8% interrupt, 36.2% idle >> CPU 7: 0.4% user, 0.0% nice, 0.0% system, 33.1% interrupt, 66.5% idle >> CPU 8: 0.0% user, 0.0% nice, 0.0% system, 64.6% interrupt, 35.4% idle >> CPU 9: 0.4% user, 0.0% nice, 0.0% system, 33.5% interrupt, 66.1% idle >> CPU 10: 0.4% user, 0.0% nice, 0.8% system, 36.6% interrupt, 62.2% idle >> CPU 11: 0.8% user, 0.0% nice, 0.4% system, 31.9% interrupt, 66.9% idle >> >> My sysctl.conf: >> >> net.inet.ip.forwarding=1 >> net.inet.ip.fastforwarding=1 >> net.inet6.ip6.forwarding=1 >> kern.ipc.somaxconn=4096 >> net.inet.tcp.syncookies=1 >> net.inet.ip.redirect=1 >> net.inet.ip.accept_sourceroute=0 >> net.inet.ip.sourceroute=0 >> net.inet.tcp.drop_synfin=1 >> net.inet.udp.blackhole=1 >> net.inet.tcp.blackhole=2 >> security.bsd.see_other_uids=0 >> net.inet.ip.fw.dyn_buckets=65536 >> net.inet.ip.fw.dyn_max=65536 >> hw.intr_storm_threshold=9000 >> net.inet.ip.dummynet.pipe_slot_limit=800 >> net.inet.icmp.icmplim=2000 >> >> My loader.conf: >> >> loader_logo="beastie" >> if_lagg_load="YES" >> speaker_load="YES" >> aio_load="YES" >> autoboot_delay="5" >> net.fibs=1 >> kern.hz=2000 >> >> My firewall rules: >> >> (root@rt01)[~]# ipfw show >> 00100 400 134880 allow ip from any to any via lo0 >> 00200 0 0 deny ip from 127.0.0.0/8 to any >> 00300 0 0 deny ip from ::1 to any >> 00400 0 0 deny ip from any to 127.0.0.0/8 >> 00500 0 0 deny ip from any to ::1 >> 00600 7381651 499415987 deny ip from not table(3) to any in recv >> vlan0 >> 00700 4011900 222326864 deny ip from not table(3) to any in recv >> vlan1 >> 00800 1287607 84935306 deny ip from not table(3) to any in recv >> vlan2 >> 00900 2152212 128056358 deny ip from not table(3) to any in recv >> vlan3 >> 01000 0 0 deny ip from not table(3) to any in recv >> vlan7 >> 01100 0 0 deny ip from not table(3) to any in recv >> vlan5 >> 01200 0 0 deny ip from not table(3) to any in recv >> vlan6 >> 01300 0 0 deny ip from not table(3) to any in recv >> vlan8 >> 01400 0 0 check-state >> 01500 1543 96723 deny tcp from any to any in tcpflags >> fin,psh,urg >> 01600 785 265717 deny tcp from any to any in tcpflags >> !syn,!fin,!ack,!psh,!rst,!urg >> 01700 633 49047 deny tcp from any to any in tcpflags >> syn,fin >> 01800 20620 828603 deny tcp from any to any in tcpflags >> fin,rst >> 01900 0 0 deny ip from any to any in ipoptions >> ssrr,lsrr,rr,ts >> 02000 0 0 deny ip from table(99) to any in via igb4 >> 02100 0 0 deny ip from table(99) to any in via igb5 >> 02200 75031 11544750 deny ip from table(99) to any in via igb1 >> 02300 340077 17057941 deny ip from table(1) to any >> 02400 0 0 deny log logamount 100 ip from any to >> table(2) >> 02500 21858 1661959 allow udp from 186.xxx.xxx.3 to me >> dst-port 161 in via vlan0 keep-state >> 02600 0 0 allow tcp from 186.xxx.xxx.3 to me >> dst-port 199 in via vlan0 setup keep-state >> 02700 100 8128 deny udp from any to me dst-port 161 >> 02800 0 0 deny tcp from any to me dst-port 199 >> 65535 158071018941 121039458717515 allow ip from any to any >> >> >> My /etc/rc.local (cpu affinity): >> >> #!/bin/sh >> echo "SO4L16G>L8C." > /dev/speaker >> /usr/bin/cpuset -l 0 /usr/local/sbin/bgpd >> /usr/bin/cpuset -l 5 -x 300 >> /usr/bin/cpuset -l 4 -x 301 >> /usr/bin/cpuset -l 3 -x 302 >> /usr/bin/cpuset -l 2 -x 303 >> /usr/bin/cpuset -l 1 -x 304 >> /usr/bin/cpuset -l 0 -x 305 >> /usr/bin/cpuset -l 0 -x 306 >> /usr/bin/cpuset -l 1 -x 307 >> /usr/bin/cpuset -l 2 -x 308 >> /usr/bin/cpuset -l 3 -x 309 >> /usr/bin/cpuset -l 4 -x 310 >> /usr/bin/cpuset -l 5 -x 311 >> /usr/bin/cpuset -l 5 -x 312 >> /usr/bin/cpuset -l 4 -x 313 >> /usr/bin/cpuset -l 3 -x 314 >> /usr/bin/cpuset -l 2 -x 315 >> /usr/bin/cpuset -l 1 -x 316 >> /usr/bin/cpuset -l 0 -x 317 >> /usr/bin/cpuset -l 0 -x 318 >> /usr/bin/cpuset -l 1 -x 319 >> /usr/bin/cpuset -l 2 -x 320 >> /usr/bin/cpuset -l 3 -x 321 >> /usr/bin/cpuset -l 4 -x 322 >> /usr/bin/cpuset -l 5 -x 323 >> /usr/bin/cpuset -l 5 -x 324 >> /usr/bin/cpuset -l 4 -x 325 >> /usr/bin/cpuset -l 3 -x 326 >> /usr/bin/cpuset -l 2 -x 327 >> /usr/bin/cpuset -l 1 -x 328 >> /usr/bin/cpuset -l 0 -x 329 >> /usr/bin/cpuset -l 0 -x 330 >> /usr/bin/cpuset -l 1 -x 331 >> /usr/bin/cpuset -l 2 -x 332 >> /usr/bin/cpuset -l 3 -x 333 >> /usr/bin/cpuset -l 4 -x 334 >> /usr/bin/cpuset -l 5 -x 335 >> /usr/bin/cpuset -l 5 -x 264 >> /usr/bin/cpuset -l 4 -x 265 >> /usr/bin/cpuset -l 3 -x 266 >> /usr/bin/cpuset -l 2 -x 267 >> /usr/bin/cpuset -l 1 -x 268 >> /usr/bin/cpuset -l 0 -x 269 >> /usr/bin/cpuset -l 0 -x 270 >> /usr/bin/cpuset -l 1 -x 271 >> /usr/bin/cpuset -l 2 -x 272 >> /usr/bin/cpuset -l 3 -x 273 >> /usr/bin/cpuset -l 4 -x 274 >> /usr/bin/cpuset -l 5 -x 275 >> /usr/bin/cpuset -l 5 -x 276 >> /usr/bin/cpuset -l 4 -x 277 >> /usr/bin/cpuset -l 3 -x 278 >> /usr/bin/cpuset -l 2 -x 279 >> /usr/bin/cpuset -l 1 -x 280 >> /usr/bin/cpuset -l 0 -x 281 >> /usr/bin/cpuset -l 0 -x 282 >> /usr/bin/cpuset -l 1 -x 283 >> /usr/bin/cpuset -l 2 -x 284 >> /usr/bin/cpuset -l 3 -x 285 >> /usr/bin/cpuset -l 4 -x 286 >> /usr/bin/cpuset -l 5 -x 287 >> /usr/bin/cpuset -l 5 -x 288 >> /usr/bin/cpuset -l 4 -x 289 >> /usr/bin/cpuset -l 3 -x 290 >> /usr/bin/cpuset -l 2 -x 291 >> /usr/bin/cpuset -l 1 -x 292 >> /usr/bin/cpuset -l 0 -x 293 >> /usr/bin/cpuset -l 0 -x 294 >> /usr/bin/cpuset -l 1 -x 295 >> /usr/bin/cpuset -l 2 -x 296 >> /usr/bin/cpuset -l 3 -x 297 >> /usr/bin/cpuset -l 4 -x 298 >> /usr/bin/cpuset -l 5 -x 299 >> /usr/bin/cpuset -l 11 -x 337 >> /usr/bin/cpuset -l 10 -x 338 >> /usr/bin/cpuset -l 9 -x 339 >> /usr/bin/cpuset -l 8 -x 340 >> /usr/bin/cpuset -l 7 -x 341 >> /usr/bin/cpuset -l 6 -x 342 >> /usr/bin/cpuset -l 6 -x 343 >> /usr/bin/cpuset -l 8 -x 344 >> /usr/bin/cpuset -l 8 -x 345 >> /usr/bin/cpuset -l 9 -x 346 >> /usr/bin/cpuset -l 10 -x 347 >> /usr/bin/cpuset -l 11 -x 348 >> /usr/bin/cpuset -l 11 -x 349 >> /usr/bin/cpuset -l 10 -x 350 >> /usr/bin/cpuset -l 9 -x 351 >> /usr/bin/cpuset -l 8 -x 352 >> /usr/bin/cpuset -l 7 -x 353 >> /usr/bin/cpuset -l 6 -x 354 >> >> ix0: flags=8843 metric 0 mtu 1500 >> options=8407bb >> ether a0:36:9f:2a:6d:ac >> inet6 fe80::a236:9fff:fe2a:6dac%ix0 prefixlen 64 scopeid 0x9 >> nd6 options=21 >> media: Ethernet autoselect (10Gbase-LR >> ) >> status: active >> >> ix1: flags=8843 metric 0 mtu 1500 >> options=8407bb >> ether a0:36:9f:2a:6d:ae >> inet6 fe80::a236:9fff:fe2a:6dae%ix1 prefixlen 64 scopeid 0xa >> nd6 options=21 >> media: Ethernet autoselect (10Gbase-SR >> ) >> status: active >> >> igb4: flags=8843 metric 0 mtu 1500 >> options=403bb >> ether 00:1b:21:7b:ee:6c >> inet6 fe80::21e:67ff:fe9b:3e1%igb4 prefixlen 64 scopeid 0x5 >> nd6 options=21 >> media: Ethernet autoselect (1000baseT ) >> status: active >> >> igb5: flags=8843 metric 0 mtu 1500 >> options=403bb >> ether 00:1b:21:7b:ee:6c >> inet6 fe80::21e:67ff:fe9b:3e1%igb5 prefixlen 64 scopeid 0x6 >> nd6 options=21 >> media: Ethernet autoselect (1000baseT ) >> status: active >> >> igb6: flags=8843 metric 0 mtu 1500 >> options=403bb >> ether 00:1b:21:7b:ee:98 >> inet6 fe80::21e:67ff:fe9b:3e1%igb6 prefixlen 64 scopeid 0x7 >> nd6 options=21 >> media: Ethernet autoselect (1000baseT ) >> status: active >> >> igb7: flags=8843 metric 0 mtu 1500 >> options=403bb >> ether 00:1b:21:7b:ee:98 >> inet6 fe80::21e:67ff:fe9b:3e1%igb7 prefixlen 64 scopeid 0x8 >> nd6 options=21 >> media: Ethernet autoselect (1000baseT ) >> status: active >> >> >> [1] >> http://download.intel.com/support/motherboards/server/s2600co/sb/g42278004_s2600co_tps_rev171.pdf >> >> Thanks and best regards, >> From owner-freebsd-net@freebsd.org Mon Sep 7 20:16:45 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 93B1A9CC5CB for ; Mon, 7 Sep 2015 20:16:45 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 608F71F90 for ; Mon, 7 Sep 2015 20:16:45 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igcrk20 with SMTP id rk20so59628123igc.1 for ; Mon, 07 Sep 2015 13:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BjSUQ/ao52xhEDV+xQ6l9ih1axpH+eiTUuQPdJ+GR70=; b=yNpZ9L02M5aUCPlEOSvoYaaPC7efDp2D9Sqg0tmrGVWTSw4JCh3kCAbTKPv7Vs5zj+ CO99HbD191d4K9odxPOXYsvMPFPCJVXaJsxtM7xaHSVBJzx0z1fuUhlSYNifpPN0pwJa 8BjqRQ6hu3GLlNQu1wFZfuKcffAjZL54FL+ORsA1V5E/nD4HOEE3BezImOQ3nQVYmshG idDmWOSWf5CFF587ItOKe9tfjNEVKfORoo563iibLtg5upo12IcBnKACx+GbncpCOr+D BHK+8CYyqt7tEm1zr2Ge1Z2Y7k9b1ARNApy4w1GKEr466k6owsif5xyEbRXEazUwDsNt 4B0A== MIME-Version: 1.0 X-Received: by 10.50.61.243 with SMTP id t19mr30992911igr.22.1441657004645; Mon, 07 Sep 2015 13:16:44 -0700 (PDT) Received: by 10.36.28.208 with HTTP; Mon, 7 Sep 2015 13:16:44 -0700 (PDT) In-Reply-To: <55EDBAB8.4050400@bsdinfo.com.br> References: <55ECE515.3080104@bsdinfo.com.br> <55EDBAB8.4050400@bsdinfo.com.br> Date: Mon, 7 Sep 2015 13:16:44 -0700 Message-ID: Subject: Re: Tuning for Intel X520-SR2 and Intel i350-T2 From: Adrian Chadd To: Marcelo Gondim Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 20:16:45 -0000 ah, sorry. I thought it didn't make it into 10.2. Oops! You can disable AIM (adaptive interrupt moderation) and set the interrupt rate: hw.ix.enable_aim=0 hw.ix.max_interrupt_rate= -adrian On 7 September 2015 at 09:26, Marcelo Gondim wrote: > On 07-09-2015 02:15, Adrian Chadd wrote: >> >> What's the actual problem? What are you seeing? >> >> (For 10.2, please read the errata notice on ixgbe and disabling the >> flowdirector code.) >> >> >> >> -adrian > > Hi Adrian, > > This problem would be not only in 10.1? Below is saying that only affected > 10.1. > > Topic: Disable ixgbe(4) flow-director support > > Category: core > Module: ixgbe > Announced: 2015-08-25 > Credits: Marc De La Gueronniere (Verisign, Inc.) > Affects: FreeBSD 10.1 > Corrected: 2014-10-11 22:10:39 UTC (stable/10, 10.1-STABLE) > 2015-08-25 20:48:58 UTC (releng/10.1, 10.1-RELEASE-p19) > > I'm just looking for some tuning that reduces the use of interruptions of > the network interfaces. > > >> >> >> On 6 September 2015 at 18:15, Marcelo Gondim >> wrote: >>> >>> Hi all, >>> >>> I have a router FreeBSD 10.2-RELEASE-p2 with one network card Intel >>> X520-SR2 >>> and two cards Intel i350-T2. >>> >>> My hardware: >>> >>> - Motherboard Intel S2600COE [1] >>> - Dual Hexa Xeon: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz >>> - 18Gb ram >>> - Downstream traffic 4Gbps >>> >>> Is there any tuning to reduce the use of network outages? >>> >>> My top below: >>> >>> last pid: 8196; load averages: 17.98, 17.52, 17.21 up 1+23:05:25 >>> 21:45:05 >>> 32 processes: 1 running, 31 sleeping >>> CPU 0: 0.4% user, 0.0% nice, 0.4% system, 37.0% interrupt, 62.2% idle >>> CPU 1: 0.0% user, 0.0% nice, 0.0% system, 50.4% interrupt, 49.6% idle >>> CPU 2: 0.8% user, 0.0% nice, 0.0% system, 46.9% interrupt, 52.4% idle >>> CPU 3: 0.0% user, 0.0% nice, 0.0% system, 65.7% interrupt, 34.3% idle >>> CPU 4: 0.0% user, 0.0% nice, 0.0% system, 62.6% interrupt, 37.4% idle >>> CPU 5: 0.0% user, 0.0% nice, 0.4% system, 63.0% interrupt, 36.6% idle >>> CPU 6: 0.0% user, 0.0% nice, 0.0% system, 63.8% interrupt, 36.2% idle >>> CPU 7: 0.4% user, 0.0% nice, 0.0% system, 33.1% interrupt, 66.5% idle >>> CPU 8: 0.0% user, 0.0% nice, 0.0% system, 64.6% interrupt, 35.4% idle >>> CPU 9: 0.4% user, 0.0% nice, 0.0% system, 33.5% interrupt, 66.1% idle >>> CPU 10: 0.4% user, 0.0% nice, 0.8% system, 36.6% interrupt, 62.2% idle >>> CPU 11: 0.8% user, 0.0% nice, 0.4% system, 31.9% interrupt, 66.9% idle >>> >>> My sysctl.conf: >>> >>> net.inet.ip.forwarding=1 >>> net.inet.ip.fastforwarding=1 >>> net.inet6.ip6.forwarding=1 >>> kern.ipc.somaxconn=4096 >>> net.inet.tcp.syncookies=1 >>> net.inet.ip.redirect=1 >>> net.inet.ip.accept_sourceroute=0 >>> net.inet.ip.sourceroute=0 >>> net.inet.tcp.drop_synfin=1 >>> net.inet.udp.blackhole=1 >>> net.inet.tcp.blackhole=2 >>> security.bsd.see_other_uids=0 >>> net.inet.ip.fw.dyn_buckets=65536 >>> net.inet.ip.fw.dyn_max=65536 >>> hw.intr_storm_threshold=9000 >>> net.inet.ip.dummynet.pipe_slot_limit=800 >>> net.inet.icmp.icmplim=2000 >>> >>> My loader.conf: >>> >>> loader_logo="beastie" >>> if_lagg_load="YES" >>> speaker_load="YES" >>> aio_load="YES" >>> autoboot_delay="5" >>> net.fibs=1 >>> kern.hz=2000 >>> >>> My firewall rules: >>> >>> (root@rt01)[~]# ipfw show >>> 00100 400 134880 allow ip from any to any via lo0 >>> 00200 0 0 deny ip from 127.0.0.0/8 to any >>> 00300 0 0 deny ip from ::1 to any >>> 00400 0 0 deny ip from any to 127.0.0.0/8 >>> 00500 0 0 deny ip from any to ::1 >>> 00600 7381651 499415987 deny ip from not table(3) to any in >>> recv >>> vlan0 >>> 00700 4011900 222326864 deny ip from not table(3) to any in >>> recv >>> vlan1 >>> 00800 1287607 84935306 deny ip from not table(3) to any in >>> recv >>> vlan2 >>> 00900 2152212 128056358 deny ip from not table(3) to any in >>> recv >>> vlan3 >>> 01000 0 0 deny ip from not table(3) to any in >>> recv >>> vlan7 >>> 01100 0 0 deny ip from not table(3) to any in >>> recv >>> vlan5 >>> 01200 0 0 deny ip from not table(3) to any in >>> recv >>> vlan6 >>> 01300 0 0 deny ip from not table(3) to any in >>> recv >>> vlan8 >>> 01400 0 0 check-state >>> 01500 1543 96723 deny tcp from any to any in tcpflags >>> fin,psh,urg >>> 01600 785 265717 deny tcp from any to any in tcpflags >>> !syn,!fin,!ack,!psh,!rst,!urg >>> 01700 633 49047 deny tcp from any to any in tcpflags >>> syn,fin >>> 01800 20620 828603 deny tcp from any to any in tcpflags >>> fin,rst >>> 01900 0 0 deny ip from any to any in ipoptions >>> ssrr,lsrr,rr,ts >>> 02000 0 0 deny ip from table(99) to any in via >>> igb4 >>> 02100 0 0 deny ip from table(99) to any in via >>> igb5 >>> 02200 75031 11544750 deny ip from table(99) to any in via >>> igb1 >>> 02300 340077 17057941 deny ip from table(1) to any >>> 02400 0 0 deny log logamount 100 ip from any to >>> table(2) >>> 02500 21858 1661959 allow udp from 186.xxx.xxx.3 to me >>> dst-port 161 in via vlan0 keep-state >>> 02600 0 0 allow tcp from 186.xxx.xxx.3 to me >>> dst-port 199 in via vlan0 setup keep-state >>> 02700 100 8128 deny udp from any to me dst-port 161 >>> 02800 0 0 deny tcp from any to me dst-port 199 >>> 65535 158071018941 121039458717515 allow ip from any to any >>> >>> >>> My /etc/rc.local (cpu affinity): >>> >>> #!/bin/sh >>> echo "SO4L16G>L8C." > /dev/speaker >>> /usr/bin/cpuset -l 0 /usr/local/sbin/bgpd >>> /usr/bin/cpuset -l 5 -x 300 >>> /usr/bin/cpuset -l 4 -x 301 >>> /usr/bin/cpuset -l 3 -x 302 >>> /usr/bin/cpuset -l 2 -x 303 >>> /usr/bin/cpuset -l 1 -x 304 >>> /usr/bin/cpuset -l 0 -x 305 >>> /usr/bin/cpuset -l 0 -x 306 >>> /usr/bin/cpuset -l 1 -x 307 >>> /usr/bin/cpuset -l 2 -x 308 >>> /usr/bin/cpuset -l 3 -x 309 >>> /usr/bin/cpuset -l 4 -x 310 >>> /usr/bin/cpuset -l 5 -x 311 >>> /usr/bin/cpuset -l 5 -x 312 >>> /usr/bin/cpuset -l 4 -x 313 >>> /usr/bin/cpuset -l 3 -x 314 >>> /usr/bin/cpuset -l 2 -x 315 >>> /usr/bin/cpuset -l 1 -x 316 >>> /usr/bin/cpuset -l 0 -x 317 >>> /usr/bin/cpuset -l 0 -x 318 >>> /usr/bin/cpuset -l 1 -x 319 >>> /usr/bin/cpuset -l 2 -x 320 >>> /usr/bin/cpuset -l 3 -x 321 >>> /usr/bin/cpuset -l 4 -x 322 >>> /usr/bin/cpuset -l 5 -x 323 >>> /usr/bin/cpuset -l 5 -x 324 >>> /usr/bin/cpuset -l 4 -x 325 >>> /usr/bin/cpuset -l 3 -x 326 >>> /usr/bin/cpuset -l 2 -x 327 >>> /usr/bin/cpuset -l 1 -x 328 >>> /usr/bin/cpuset -l 0 -x 329 >>> /usr/bin/cpuset -l 0 -x 330 >>> /usr/bin/cpuset -l 1 -x 331 >>> /usr/bin/cpuset -l 2 -x 332 >>> /usr/bin/cpuset -l 3 -x 333 >>> /usr/bin/cpuset -l 4 -x 334 >>> /usr/bin/cpuset -l 5 -x 335 >>> /usr/bin/cpuset -l 5 -x 264 >>> /usr/bin/cpuset -l 4 -x 265 >>> /usr/bin/cpuset -l 3 -x 266 >>> /usr/bin/cpuset -l 2 -x 267 >>> /usr/bin/cpuset -l 1 -x 268 >>> /usr/bin/cpuset -l 0 -x 269 >>> /usr/bin/cpuset -l 0 -x 270 >>> /usr/bin/cpuset -l 1 -x 271 >>> /usr/bin/cpuset -l 2 -x 272 >>> /usr/bin/cpuset -l 3 -x 273 >>> /usr/bin/cpuset -l 4 -x 274 >>> /usr/bin/cpuset -l 5 -x 275 >>> /usr/bin/cpuset -l 5 -x 276 >>> /usr/bin/cpuset -l 4 -x 277 >>> /usr/bin/cpuset -l 3 -x 278 >>> /usr/bin/cpuset -l 2 -x 279 >>> /usr/bin/cpuset -l 1 -x 280 >>> /usr/bin/cpuset -l 0 -x 281 >>> /usr/bin/cpuset -l 0 -x 282 >>> /usr/bin/cpuset -l 1 -x 283 >>> /usr/bin/cpuset -l 2 -x 284 >>> /usr/bin/cpuset -l 3 -x 285 >>> /usr/bin/cpuset -l 4 -x 286 >>> /usr/bin/cpuset -l 5 -x 287 >>> /usr/bin/cpuset -l 5 -x 288 >>> /usr/bin/cpuset -l 4 -x 289 >>> /usr/bin/cpuset -l 3 -x 290 >>> /usr/bin/cpuset -l 2 -x 291 >>> /usr/bin/cpuset -l 1 -x 292 >>> /usr/bin/cpuset -l 0 -x 293 >>> /usr/bin/cpuset -l 0 -x 294 >>> /usr/bin/cpuset -l 1 -x 295 >>> /usr/bin/cpuset -l 2 -x 296 >>> /usr/bin/cpuset -l 3 -x 297 >>> /usr/bin/cpuset -l 4 -x 298 >>> /usr/bin/cpuset -l 5 -x 299 >>> /usr/bin/cpuset -l 11 -x 337 >>> /usr/bin/cpuset -l 10 -x 338 >>> /usr/bin/cpuset -l 9 -x 339 >>> /usr/bin/cpuset -l 8 -x 340 >>> /usr/bin/cpuset -l 7 -x 341 >>> /usr/bin/cpuset -l 6 -x 342 >>> /usr/bin/cpuset -l 6 -x 343 >>> /usr/bin/cpuset -l 8 -x 344 >>> /usr/bin/cpuset -l 8 -x 345 >>> /usr/bin/cpuset -l 9 -x 346 >>> /usr/bin/cpuset -l 10 -x 347 >>> /usr/bin/cpuset -l 11 -x 348 >>> /usr/bin/cpuset -l 11 -x 349 >>> /usr/bin/cpuset -l 10 -x 350 >>> /usr/bin/cpuset -l 9 -x 351 >>> /usr/bin/cpuset -l 8 -x 352 >>> /usr/bin/cpuset -l 7 -x 353 >>> /usr/bin/cpuset -l 6 -x 354 >>> >>> ix0: flags=8843 metric 0 mtu 1500 >>> >>> options=8407bb >>> ether a0:36:9f:2a:6d:ac >>> inet6 fe80::a236:9fff:fe2a:6dac%ix0 prefixlen 64 scopeid 0x9 >>> nd6 options=21 >>> media: Ethernet autoselect (10Gbase-LR >>> ) >>> status: active >>> >>> ix1: flags=8843 metric 0 mtu 1500 >>> >>> options=8407bb >>> ether a0:36:9f:2a:6d:ae >>> inet6 fe80::a236:9fff:fe2a:6dae%ix1 prefixlen 64 scopeid 0xa >>> nd6 options=21 >>> media: Ethernet autoselect (10Gbase-SR >>> ) >>> status: active >>> >>> igb4: flags=8843 metric 0 mtu >>> 1500 >>> >>> options=403bb >>> ether 00:1b:21:7b:ee:6c >>> inet6 fe80::21e:67ff:fe9b:3e1%igb4 prefixlen 64 scopeid 0x5 >>> nd6 options=21 >>> media: Ethernet autoselect (1000baseT ) >>> status: active >>> >>> igb5: flags=8843 metric 0 mtu >>> 1500 >>> >>> options=403bb >>> ether 00:1b:21:7b:ee:6c >>> inet6 fe80::21e:67ff:fe9b:3e1%igb5 prefixlen 64 scopeid 0x6 >>> nd6 options=21 >>> media: Ethernet autoselect (1000baseT ) >>> status: active >>> >>> igb6: flags=8843 metric 0 mtu >>> 1500 >>> >>> options=403bb >>> ether 00:1b:21:7b:ee:98 >>> inet6 fe80::21e:67ff:fe9b:3e1%igb6 prefixlen 64 scopeid 0x7 >>> nd6 options=21 >>> media: Ethernet autoselect (1000baseT ) >>> status: active >>> >>> igb7: flags=8843 metric 0 mtu >>> 1500 >>> >>> options=403bb >>> ether 00:1b:21:7b:ee:98 >>> inet6 fe80::21e:67ff:fe9b:3e1%igb7 prefixlen 64 scopeid 0x8 >>> nd6 options=21 >>> media: Ethernet autoselect (1000baseT ) >>> status: active >>> >>> >>> [1] >>> >>> http://download.intel.com/support/motherboards/server/s2600co/sb/g42278004_s2600co_tps_rev171.pdf >>> >>> Thanks and best regards, >>> > From owner-freebsd-net@freebsd.org Mon Sep 7 23:57:22 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BAF239CD5DE for ; Mon, 7 Sep 2015 23:57:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A77B5146B for ; Mon, 7 Sep 2015 23:57:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t87NvMfM020897 for ; Mon, 7 Sep 2015 23:57:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202885] IPsec performance problems with fragmented ESP and packet loss Date: Mon, 07 Sep 2015 23:57:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: gnn@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gnn@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 23:57:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202885 George V. Neville-Neil changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gnn@FreeBSD.org Assignee|freebsd-net@FreeBSD.org |gnn@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Tue Sep 8 10:20:55 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 257D0A0028C for ; Tue, 8 Sep 2015 10:20:55 +0000 (UTC) (envelope-from prvs=686a0e2e0=roger.pau@citrix.com) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Verizon Public SureServer CA G14-SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D3EC41CC2 for ; Tue, 8 Sep 2015 10:20:54 +0000 (UTC) (envelope-from prvs=686a0e2e0=roger.pau@citrix.com) X-IronPort-AV: E=Sophos;i="5.17,489,1437436800"; d="scan'208";a="301910260" To: FreeBSD Net From: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Subject: Questions about the FreeBSD network subsystem X-Enigmail-Draft-Status: N1110 CC: xen-devel Message-ID: <55EEB681.5070108@citrix.com> Date: Tue, 8 Sep 2015 12:20:49 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-DLP: MIA1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 10:20:55 -0000 Hello, I'm not very familiar with FreeBSD network subsystem and I'm trying to import a new version of xen-netfront from Linux to FreeBSD. So far so good, most stuff is pretty similar and I think I've _mostly_ figured it out by myself. I have however a couple of questions regarding the network subsystem. I'm planning to use if_transmit/if_qflush instead of if_start. AFAICT I have to create my own queue inside of the driver in order to queue packets if the shared ring is full. What's the prefer way to do this? I see there are functions to create a mbuf queue (mbufq) or a ifnet based queue (drbr_* family of functions). I expect using drbr is TRTTD, but I would like to get some confirmation before proceeding. Also, the Xen PV network protocol allows signalling packets that contain valid data or blank checksums. It allows specifying the following flags: - NET{RX/TR}F_data_validated: packet data has been validated against protocol checksum. - NET{RX/TX}F_csum_blank: protocol checksum field is blank in the packet (hardware offload)?. - No flag: checksum present and valid. How do this options translate to the csum_flags present in mbufs on FreeBSD? Thanks, Roger. From owner-freebsd-net@freebsd.org Tue Sep 8 11:26:35 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A686A9CD5F3 for ; Tue, 8 Sep 2015 11:26:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 92DEE185E for ; Tue, 8 Sep 2015 11:26:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t88BQZ8R003868 for ; Tue, 8 Sep 2015 11:26:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202907] 10.2 on SolarFlare SFN5162F 10Gb/s NIC missing out traffic Date: Tue, 08 Sep 2015 11:26:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: arybchik@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 11:26:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202907 --- Comment #4 from Andrew Rybchenko --- That's my fault. Since statistics support differs in HEAD (if_get_counter) and earlier stable branches (periodic update of counters in ifnet). I've forgotten to merge stable/10-specific patch. I'll care about it. (If it helps you, there is no the issue in driver available on Solarflare support site) -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Tue Sep 8 15:22:44 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23E8D9CC3E3 for ; Tue, 8 Sep 2015 15:22:44 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 093C01873 for ; Tue, 8 Sep 2015 15:22:44 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 082649CC3E2; Tue, 8 Sep 2015 15:22:44 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0791D9CC3E1 for ; Tue, 8 Sep 2015 15:22:44 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 508F91872; Tue, 8 Sep 2015 15:22:42 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.15.2/8.15.2) with ESMTPS id t88FMXIs051335 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 8 Sep 2015 18:22:33 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.15.2/8.15.2/Submit) id t88FMXV3051334; Tue, 8 Sep 2015 18:22:33 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 8 Sep 2015 18:22:33 +0300 From: Gleb Smirnoff To: Adrian Chadd , Andriy Voskoboinyk Cc: "net@freebsd.org" Subject: more net80211 changes :/ Message-ID: <20150908152233.GV1023@glebius.int.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="mxv5cy4qt+RJ9ypb" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 15:22:44 -0000 --mxv5cy4qt+RJ9ypb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi! It looks like another sweep over net80211 drivers is required. It isn't going to be as huge as previous one. The problem is that in the "new world order", there will be only if_attach(), instead of if_alloc() / fill & hack / ether_ifattach. What right now happens with net80211 is that all drivers have the same copy & paste in their ic_vap_create, which yields in a sequence of: - if_alloc - driver specific code - ether_ifattach Which isn't possible to collapse into if_attach(), since driver code is in the middle. Another problem is embedding if ieee80211_vap into driver's softc. This is a bad habit, which was proved by ifnet experience (fixed decade ago). What patch does: - Inline ieee80211_vap_setup() and ieee80211_vap_attach() into wlan_clone_create(). Note, that this moves code from ieee80211.c to into ieee80211_freebsd.c, which is good, since this code about interaction with ifnet layer, which is FreeBSD specific and will be more FreeBSD specific. As dependency ifmedia support code and ieee80211_get_counter() also naturally move to the same file. - In the new long wlan_clone_create(), after initial error checking call ic_vap_preattach() to allow driver do its own error checking. I predict that for now ath(4) will be the only driver to use ic_vap_preattach(). - If no errors, go with allocating and attaching the interface, and then call ic_vap_postattach. - The ic_vap_postattach() for all drivers (save ath) would be remnants of ic_vap_create(), where all copy and paste is removed and only driver specific bits remain. - ic_vap_postattach() may allocate driver specific softc for vap, which now longer has ieee80211_vap embedded. This also removes all ambiguities with mac address handling, which was juggled between three functions before. The current patch covers iwn(4) only. Now sending this mail with patched driver. Changing MAC aldo tested - works. I'm starting to convert rest of drivers and meanwhile, waiting for your input. May be you have ideas what else can be improved here. -- Totus tuus, Glebius. --mxv5cy4qt+RJ9ypb Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="new_vap_attach.diff" Index: sys/dev/iwn/if_iwn.c =================================================================== --- sys/dev/iwn/if_iwn.c (revision 287554) +++ sys/dev/iwn/if_iwn.c (working copy) @@ -136,10 +136,7 @@ static int iwn5000_attach(struct iwn_softc *, uint static int iwn_config_specific(struct iwn_softc *, uint16_t); static void iwn_radiotap_attach(struct iwn_softc *); static void iwn_sysctlattach(struct iwn_softc *); -static struct ieee80211vap *iwn_vap_create(struct ieee80211com *, - const char [IFNAMSIZ], int, enum ieee80211_opmode, int, - const uint8_t [IEEE80211_ADDR_LEN], - const uint8_t [IEEE80211_ADDR_LEN]); +static void iwn_vap_postattach(struct ieee80211com *, struct ieee80211vap *); static void iwn_vap_delete(struct ieee80211vap *); static int iwn_detach(device_t); static int iwn_shutdown(device_t); @@ -640,7 +637,7 @@ iwn_attach(device_t dev) } ieee80211_ifattach(ic); - ic->ic_vap_create = iwn_vap_create; + ic->ic_vap_postattach = iwn_vap_postattach; ic->ic_ioctl = iwn_ioctl; ic->ic_parent = iwn_parent; ic->ic_vap_delete = iwn_vap_delete; @@ -666,6 +663,7 @@ iwn_attach(device_t dev) ic->ic_scan_curchan = iwn_scan_curchan; ic->ic_scan_mindwell = iwn_scan_mindwell; ic->ic_setregdomain = iwn_setregdomain; + ic->ic_media_change = iwn_media_change; iwn_radiotap_attach(sc); @@ -1317,22 +1315,13 @@ iwn_sysctlattach(struct iwn_softc *sc) #endif } -static struct ieee80211vap * -iwn_vap_create(struct ieee80211com *ic, const char name[IFNAMSIZ], int unit, - enum ieee80211_opmode opmode, int flags, - const uint8_t bssid[IEEE80211_ADDR_LEN], - const uint8_t mac[IEEE80211_ADDR_LEN]) +static void +iwn_vap_postattach(struct ieee80211com *ic, struct ieee80211vap *vap) { struct iwn_softc *sc = ic->ic_softc; struct iwn_vap *ivp; - struct ieee80211vap *vap; - if (!TAILQ_EMPTY(&ic->ic_vaps)) /* only one at a time */ - return NULL; - - ivp = malloc(sizeof(struct iwn_vap), M_80211_VAP, M_WAITOK | M_ZERO); - vap = &ivp->iv_vap; - ieee80211_vap_setup(ic, vap, name, unit, opmode, flags, bssid); + ivp = malloc(sizeof(struct iwn_vap), M_80211_VAP, M_WAITOK); ivp->ctx = IWN_RXON_BSS_CTX; vap->iv_bmissthreshold = 10; /* override default */ /* Override with driver methods. */ @@ -1339,19 +1328,14 @@ iwn_sysctlattach(struct iwn_softc *sc) ivp->iv_newstate = vap->iv_newstate; vap->iv_newstate = iwn_newstate; sc->ivap[IWN_RXON_BSS_CTX] = vap; - + vap->iv_softc = ivp; ieee80211_ratectl_init(vap); - /* Complete setup. */ - ieee80211_vap_attach(vap, iwn_media_change, ieee80211_media_status, - mac); - ic->ic_opmode = opmode; - return vap; } static void iwn_vap_delete(struct ieee80211vap *vap) { - struct iwn_vap *ivp = IWN_VAP(vap); + struct iwn_vap *ivp = vap->iv_softc; ieee80211_ratectl_deinit(vap); ieee80211_vap_detach(vap); @@ -2814,7 +2798,7 @@ iwn_media_change(struct ifnet *ifp) static int iwn_newstate(struct ieee80211vap *vap, enum ieee80211_state nstate, int arg) { - struct iwn_vap *ivp = IWN_VAP(vap); + struct iwn_vap *ivp = vap->iv_softc; struct ieee80211com *ic = vap->iv_ic; struct iwn_softc *sc = ic->ic_softc; int error = 0; Index: sys/dev/iwn/if_iwnvar.h =================================================================== --- sys/dev/iwn/if_iwnvar.h (revision 287554) +++ sys/dev/iwn/if_iwnvar.h (working copy) @@ -221,16 +221,11 @@ struct iwn_ops { }; struct iwn_vap { - struct ieee80211vap iv_vap; - uint8_t iv_ridx; - int (*iv_newstate)(struct ieee80211vap *, enum ieee80211_state, int); int ctx; - int beacon_int; }; -#define IWN_VAP(_vap) ((struct iwn_vap *)(_vap)) struct iwn_softc { device_t sc_dev; Index: sys/net80211/ieee80211.c =================================================================== --- sys/net80211/ieee80211.c (revision 287554) +++ sys/net80211/ieee80211.c (working copy) @@ -86,15 +86,8 @@ const int ieee80211_opcap[IEEE80211_OPMODE_MAX] = const uint8_t ieee80211broadcastaddr[IEEE80211_ADDR_LEN] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; -static void ieee80211_syncflag_locked(struct ieee80211com *ic, int flag); -static void ieee80211_syncflag_ht_locked(struct ieee80211com *ic, int flag); -static void ieee80211_syncflag_ext_locked(struct ieee80211com *ic, int flag); -static int ieee80211_media_setup(struct ieee80211com *ic, - struct ifmedia *media, int caps, int addsta, - ifm_change_cb_t media_change, ifm_stat_cb_t media_stat); static int media_status(enum ieee80211_opmode, const struct ieee80211_channel *); -static uint64_t ieee80211_get_counter(struct ifnet *, ift_counter); MALLOC_DEFINE(M_80211_VAP, "80211vap", "802.11 vap state"); @@ -400,224 +393,6 @@ ieee80211_find_com(const char *name) return (ic); } -/* - * Default reset method for use with the ioctl support. This - * method is invoked after any state change in the 802.11 - * layer that should be propagated to the hardware but not - * require re-initialization of the 802.11 state machine (e.g - * rescanning for an ap). We always return ENETRESET which - * should cause the driver to re-initialize the device. Drivers - * can override this method to implement more optimized support. - */ -static int -default_reset(struct ieee80211vap *vap, u_long cmd) -{ - return ENETRESET; -} - -/* - * Add underlying device errors to vap errors. - */ -static uint64_t -ieee80211_get_counter(struct ifnet *ifp, ift_counter cnt) -{ - struct ieee80211vap *vap = ifp->if_softc; - struct ieee80211com *ic = vap->iv_ic; - uint64_t rv; - - rv = if_get_counter_default(ifp, cnt); - switch (cnt) { - case IFCOUNTER_OERRORS: - rv += counter_u64_fetch(ic->ic_oerrors); - break; - case IFCOUNTER_IERRORS: - rv += counter_u64_fetch(ic->ic_ierrors); - break; - default: - break; - } - - return (rv); -} - -/* - * Prepare a vap for use. Drivers use this call to - * setup net80211 state in new vap's prior attaching - * them with ieee80211_vap_attach (below). - */ -int -ieee80211_vap_setup(struct ieee80211com *ic, struct ieee80211vap *vap, - const char name[IFNAMSIZ], int unit, enum ieee80211_opmode opmode, - int flags, const uint8_t bssid[IEEE80211_ADDR_LEN]) -{ - struct ifnet *ifp; - - ifp = if_alloc(IFT_ETHER); - if (ifp == NULL) { - ic_printf(ic, "%s: unable to allocate ifnet\n", - __func__); - return ENOMEM; - } - if_initname(ifp, name, unit); - ifp->if_softc = vap; /* back pointer */ - ifp->if_flags = IFF_SIMPLEX | IFF_BROADCAST | IFF_MULTICAST; - ifp->if_transmit = ieee80211_vap_transmit; - ifp->if_qflush = ieee80211_vap_qflush; - ifp->if_ioctl = ieee80211_ioctl; - ifp->if_init = ieee80211_init; - ifp->if_get_counter = ieee80211_get_counter; - - vap->iv_ifp = ifp; - vap->iv_ic = ic; - vap->iv_flags = ic->ic_flags; /* propagate common flags */ - vap->iv_flags_ext = ic->ic_flags_ext; - vap->iv_flags_ven = ic->ic_flags_ven; - vap->iv_caps = ic->ic_caps &~ IEEE80211_C_OPMODE; - vap->iv_htcaps = ic->ic_htcaps; - vap->iv_htextcaps = ic->ic_htextcaps; - vap->iv_opmode = opmode; - vap->iv_caps |= ieee80211_opcap[opmode]; - vap->iv_myaddr = ic->ic_macaddr; - switch (opmode) { - case IEEE80211_M_WDS: - /* - * WDS links must specify the bssid of the far end. - * For legacy operation this is a static relationship. - * For non-legacy operation the station must associate - * and be authorized to pass traffic. Plumbing the - * vap to the proper node happens when the vap - * transitions to RUN state. - */ - IEEE80211_ADDR_COPY(vap->iv_des_bssid, bssid); - vap->iv_flags |= IEEE80211_F_DESBSSID; - if (flags & IEEE80211_CLONE_WDSLEGACY) - vap->iv_flags_ext |= IEEE80211_FEXT_WDSLEGACY; - break; -#ifdef IEEE80211_SUPPORT_TDMA - case IEEE80211_M_AHDEMO: - if (flags & IEEE80211_CLONE_TDMA) { - /* NB: checked before clone operation allowed */ - KASSERT(ic->ic_caps & IEEE80211_C_TDMA, - ("not TDMA capable, ic_caps 0x%x", ic->ic_caps)); - /* - * Propagate TDMA capability to mark vap; this - * cannot be removed and is used to distinguish - * regular ahdemo operation from ahdemo+tdma. - */ - vap->iv_caps |= IEEE80211_C_TDMA; - } - break; -#endif - default: - break; - } - /* auto-enable s/w beacon miss support */ - if (flags & IEEE80211_CLONE_NOBEACONS) - vap->iv_flags_ext |= IEEE80211_FEXT_SWBMISS; - /* auto-generated or user supplied MAC address */ - if (flags & (IEEE80211_CLONE_BSSID|IEEE80211_CLONE_MACADDR)) - vap->iv_flags_ext |= IEEE80211_FEXT_UNIQMAC; - /* - * Enable various functionality by default if we're - * capable; the driver can override us if it knows better. - */ - if (vap->iv_caps & IEEE80211_C_WME) - vap->iv_flags |= IEEE80211_F_WME; - if (vap->iv_caps & IEEE80211_C_BURST) - vap->iv_flags |= IEEE80211_F_BURST; - /* NB: bg scanning only makes sense for station mode right now */ - if (vap->iv_opmode == IEEE80211_M_STA && - (vap->iv_caps & IEEE80211_C_BGSCAN)) - vap->iv_flags |= IEEE80211_F_BGSCAN; - vap->iv_flags |= IEEE80211_F_DOTH; /* XXX no cap, just ena */ - /* NB: DFS support only makes sense for ap mode right now */ - if (vap->iv_opmode == IEEE80211_M_HOSTAP && - (vap->iv_caps & IEEE80211_C_DFS)) - vap->iv_flags_ext |= IEEE80211_FEXT_DFS; - - vap->iv_des_chan = IEEE80211_CHAN_ANYC; /* any channel is ok */ - vap->iv_bmissthreshold = IEEE80211_HWBMISS_DEFAULT; - vap->iv_dtim_period = IEEE80211_DTIM_DEFAULT; - /* - * Install a default reset method for the ioctl support; - * the driver can override this. - */ - vap->iv_reset = default_reset; - - ieee80211_sysctl_vattach(vap); - ieee80211_crypto_vattach(vap); - ieee80211_node_vattach(vap); - ieee80211_power_vattach(vap); - ieee80211_proto_vattach(vap); -#ifdef IEEE80211_SUPPORT_SUPERG - ieee80211_superg_vattach(vap); -#endif - ieee80211_ht_vattach(vap); - ieee80211_scan_vattach(vap); - ieee80211_regdomain_vattach(vap); - ieee80211_radiotap_vattach(vap); - ieee80211_ratectl_set(vap, IEEE80211_RATECTL_NONE); - - return 0; -} - -/* - * Activate a vap. State should have been prepared with a - * call to ieee80211_vap_setup and by the driver. On return - * from this call the vap is ready for use. - */ -int -ieee80211_vap_attach(struct ieee80211vap *vap, ifm_change_cb_t media_change, - ifm_stat_cb_t media_stat, const uint8_t macaddr[IEEE80211_ADDR_LEN]) -{ - struct ifnet *ifp = vap->iv_ifp; - struct ieee80211com *ic = vap->iv_ic; - struct ifmediareq imr; - int maxrate; - - IEEE80211_DPRINTF(vap, IEEE80211_MSG_STATE, - "%s: %s parent %s flags 0x%x flags_ext 0x%x\n", - __func__, ieee80211_opmode_name[vap->iv_opmode], - ic->ic_name, vap->iv_flags, vap->iv_flags_ext); - - /* - * Do late attach work that cannot happen until after - * the driver has had a chance to override defaults. - */ - ieee80211_node_latevattach(vap); - ieee80211_power_latevattach(vap); - - maxrate = ieee80211_media_setup(ic, &vap->iv_media, vap->iv_caps, - vap->iv_opmode == IEEE80211_M_STA, media_change, media_stat); - ieee80211_media_status(ifp, &imr); - /* NB: strip explicit mode; we're actually in autoselect */ - ifmedia_set(&vap->iv_media, - imr.ifm_active &~ (IFM_MMASK | IFM_IEEE80211_TURBO)); - if (maxrate) - ifp->if_baudrate = IF_Mbps(maxrate); - - ether_ifattach(ifp, macaddr); - vap->iv_myaddr = IF_LLADDR(ifp); - /* hook output method setup by ether_ifattach */ - vap->iv_output = ifp->if_output; - ifp->if_output = ieee80211_output; - /* NB: if_mtu set by ether_ifattach to ETHERMTU */ - - IEEE80211_LOCK(ic); - TAILQ_INSERT_TAIL(&ic->ic_vaps, vap, iv_next); - ieee80211_syncflag_locked(ic, IEEE80211_F_WME); -#ifdef IEEE80211_SUPPORT_SUPERG - ieee80211_syncflag_locked(ic, IEEE80211_F_TURBOP); -#endif - ieee80211_syncflag_locked(ic, IEEE80211_F_PCF); - ieee80211_syncflag_locked(ic, IEEE80211_F_BURST); - ieee80211_syncflag_ht_locked(ic, IEEE80211_FHT_HT); - ieee80211_syncflag_ht_locked(ic, IEEE80211_FHT_USEHT40); - IEEE80211_UNLOCK(ic); - - return 1; -} - /* * Tear down vap state and reclaim the ifnet. * The driver is assumed to have prepared for @@ -748,7 +523,7 @@ ieee80211_allmulti(struct ieee80211vap *vap, bool * according to the state of all vap's. This is used, * for example, to handle state changes via ioctls. */ -static void +void ieee80211_syncflag_locked(struct ieee80211com *ic, int flag) { struct ieee80211vap *vap; @@ -788,7 +563,7 @@ ieee80211_syncflag(struct ieee80211vap *vap, int f * according to the state of all vap's. This is used, * for example, to handle state changes via ioctls. */ -static void +void ieee80211_syncflag_ht_locked(struct ieee80211com *ic, int flag) { struct ieee80211vap *vap; @@ -828,7 +603,7 @@ ieee80211_syncflag_ht(struct ieee80211vap *vap, in * according to the state of all vap's. This is used, * for example, to handle state changes via ioctls. */ -static void +void ieee80211_syncflag_ext_locked(struct ieee80211com *ic, int flag) { struct ieee80211vap *vap; @@ -1095,140 +870,6 @@ ieee80211_lookup_channel_rxstatus(struct ieee80211 return (c); } -static void -addmedia(struct ifmedia *media, int caps, int addsta, int mode, int mword) -{ -#define ADD(_ic, _s, _o) \ - ifmedia_add(media, \ - IFM_MAKEWORD(IFM_IEEE80211, (_s), (_o), 0), 0, NULL) - static const u_int mopts[IEEE80211_MODE_MAX] = { - [IEEE80211_MODE_AUTO] = IFM_AUTO, - [IEEE80211_MODE_11A] = IFM_IEEE80211_11A, - [IEEE80211_MODE_11B] = IFM_IEEE80211_11B, - [IEEE80211_MODE_11G] = IFM_IEEE80211_11G, - [IEEE80211_MODE_FH] = IFM_IEEE80211_FH, - [IEEE80211_MODE_TURBO_A] = IFM_IEEE80211_11A|IFM_IEEE80211_TURBO, - [IEEE80211_MODE_TURBO_G] = IFM_IEEE80211_11G|IFM_IEEE80211_TURBO, - [IEEE80211_MODE_STURBO_A] = IFM_IEEE80211_11A|IFM_IEEE80211_TURBO, - [IEEE80211_MODE_HALF] = IFM_IEEE80211_11A, /* XXX */ - [IEEE80211_MODE_QUARTER] = IFM_IEEE80211_11A, /* XXX */ - [IEEE80211_MODE_11NA] = IFM_IEEE80211_11NA, - [IEEE80211_MODE_11NG] = IFM_IEEE80211_11NG, - }; - u_int mopt; - - mopt = mopts[mode]; - if (addsta) - ADD(ic, mword, mopt); /* STA mode has no cap */ - if (caps & IEEE80211_C_IBSS) - ADD(media, mword, mopt | IFM_IEEE80211_ADHOC); - if (caps & IEEE80211_C_HOSTAP) - ADD(media, mword, mopt | IFM_IEEE80211_HOSTAP); - if (caps & IEEE80211_C_AHDEMO) - ADD(media, mword, mopt | IFM_IEEE80211_ADHOC | IFM_FLAG0); - if (caps & IEEE80211_C_MONITOR) - ADD(media, mword, mopt | IFM_IEEE80211_MONITOR); - if (caps & IEEE80211_C_WDS) - ADD(media, mword, mopt | IFM_IEEE80211_WDS); - if (caps & IEEE80211_C_MBSS) - ADD(media, mword, mopt | IFM_IEEE80211_MBSS); -#undef ADD -} - -/* - * Setup the media data structures according to the channel and - * rate tables. - */ -static int -ieee80211_media_setup(struct ieee80211com *ic, - struct ifmedia *media, int caps, int addsta, - ifm_change_cb_t media_change, ifm_stat_cb_t media_stat) -{ - int i, j, rate, maxrate, mword, r; - enum ieee80211_phymode mode; - const struct ieee80211_rateset *rs; - struct ieee80211_rateset allrates; - - /* - * Fill in media characteristics. - */ - ifmedia_init(media, 0, media_change, media_stat); - maxrate = 0; - /* - * Add media for legacy operating modes. - */ - memset(&allrates, 0, sizeof(allrates)); - for (mode = IEEE80211_MODE_AUTO; mode < IEEE80211_MODE_11NA; mode++) { - if (isclr(ic->ic_modecaps, mode)) - continue; - addmedia(media, caps, addsta, mode, IFM_AUTO); - if (mode == IEEE80211_MODE_AUTO) - continue; - rs = &ic->ic_sup_rates[mode]; - for (i = 0; i < rs->rs_nrates; i++) { - rate = rs->rs_rates[i]; - mword = ieee80211_rate2media(ic, rate, mode); - if (mword == 0) - continue; - addmedia(media, caps, addsta, mode, mword); - /* - * Add legacy rate to the collection of all rates. - */ - r = rate & IEEE80211_RATE_VAL; - for (j = 0; j < allrates.rs_nrates; j++) - if (allrates.rs_rates[j] == r) - break; - if (j == allrates.rs_nrates) { - /* unique, add to the set */ - allrates.rs_rates[j] = r; - allrates.rs_nrates++; - } - rate = (rate & IEEE80211_RATE_VAL) / 2; - if (rate > maxrate) - maxrate = rate; - } - } - for (i = 0; i < allrates.rs_nrates; i++) { - mword = ieee80211_rate2media(ic, allrates.rs_rates[i], - IEEE80211_MODE_AUTO); - if (mword == 0) - continue; - /* NB: remove media options from mword */ - addmedia(media, caps, addsta, - IEEE80211_MODE_AUTO, IFM_SUBTYPE(mword)); - } - /* - * Add HT/11n media. Note that we do not have enough - * bits in the media subtype to express the MCS so we - * use a "placeholder" media subtype and any fixed MCS - * must be specified with a different mechanism. - */ - for (; mode <= IEEE80211_MODE_11NG; mode++) { - if (isclr(ic->ic_modecaps, mode)) - continue; - addmedia(media, caps, addsta, mode, IFM_AUTO); - addmedia(media, caps, addsta, mode, IFM_IEEE80211_MCS); - } - if (isset(ic->ic_modecaps, IEEE80211_MODE_11NA) || - isset(ic->ic_modecaps, IEEE80211_MODE_11NG)) { - addmedia(media, caps, addsta, - IEEE80211_MODE_AUTO, IFM_IEEE80211_MCS); - i = ic->ic_txstream * 8 - 1; - if ((ic->ic_htcaps & IEEE80211_HTCAP_CHWIDTH40) && - (ic->ic_htcaps & IEEE80211_HTCAP_SHORTGI40)) - rate = ieee80211_htrates[i].ht40_rate_400ns; - else if ((ic->ic_htcaps & IEEE80211_HTCAP_CHWIDTH40)) - rate = ieee80211_htrates[i].ht40_rate_800ns; - else if ((ic->ic_htcaps & IEEE80211_HTCAP_SHORTGI20)) - rate = ieee80211_htrates[i].ht20_rate_400ns; - else - rate = ieee80211_htrates[i].ht20_rate_800ns; - if (rate > maxrate) - maxrate = rate; - } - return maxrate; -} - /* XXX inline or eliminate? */ const struct ieee80211_rateset * ieee80211_get_suprates(struct ieee80211com *ic, const struct ieee80211_channel *c) Index: sys/net80211/ieee80211_ddb.c =================================================================== --- sys/net80211/ieee80211_ddb.c (revision 287554) +++ sys/net80211/ieee80211_ddb.c (working copy) @@ -634,7 +634,8 @@ _db_show_com(const struct ieee80211com *ic, int sh ic->ic_montaps, ic->ic_th, ic->ic_txchan, ic->ic_rh, ic->ic_rxchan); if (showprocs) { - DB_PRINTSYM("\t", "ic_vap_create", ic->ic_vap_create); + DB_PRINTSYM("\t", "ic_vap_preattach", ic->ic_vap_preattach); + DB_PRINTSYM("\t", "ic_vap_postattach", ic->ic_vap_postattach); DB_PRINTSYM("\t", "ic_vap_delete", ic->ic_vap_delete); #if 0 /* operating mode attachment */ Index: sys/net80211/ieee80211_freebsd.c =================================================================== --- sys/net80211/ieee80211_freebsd.c (revision 287554) +++ sys/net80211/ieee80211_freebsd.c (working copy) @@ -55,6 +55,8 @@ __FBSDID("$FreeBSD$"); #include #include +#include +#include SYSCTL_NODE(_net, OID_AUTO, wlan, CTLFLAG_RD, 0, "IEEE 80211 parameters"); @@ -66,6 +68,181 @@ SYSCTL_INT(_net_wlan, OID_AUTO, debug, CTLFLAG_RW, static MALLOC_DEFINE(M_80211_COM, "80211com", "802.11 com state"); +static void +addmedia(struct ifmedia *media, int caps, int addsta, int mode, int mword) +{ +#define ADD(_ic, _s, _o) \ + ifmedia_add(media, \ + IFM_MAKEWORD(IFM_IEEE80211, (_s), (_o), 0), 0, NULL) + static const u_int mopts[IEEE80211_MODE_MAX] = { + [IEEE80211_MODE_AUTO] = IFM_AUTO, + [IEEE80211_MODE_11A] = IFM_IEEE80211_11A, + [IEEE80211_MODE_11B] = IFM_IEEE80211_11B, + [IEEE80211_MODE_11G] = IFM_IEEE80211_11G, + [IEEE80211_MODE_FH] = IFM_IEEE80211_FH, + [IEEE80211_MODE_TURBO_A] = IFM_IEEE80211_11A|IFM_IEEE80211_TURBO, + [IEEE80211_MODE_TURBO_G] = IFM_IEEE80211_11G|IFM_IEEE80211_TURBO, + [IEEE80211_MODE_STURBO_A] = IFM_IEEE80211_11A|IFM_IEEE80211_TURBO, + [IEEE80211_MODE_HALF] = IFM_IEEE80211_11A, /* XXX */ + [IEEE80211_MODE_QUARTER] = IFM_IEEE80211_11A, /* XXX */ + [IEEE80211_MODE_11NA] = IFM_IEEE80211_11NA, + [IEEE80211_MODE_11NG] = IFM_IEEE80211_11NG, + }; + u_int mopt; + + mopt = mopts[mode]; + if (addsta) + ADD(ic, mword, mopt); /* STA mode has no cap */ + if (caps & IEEE80211_C_IBSS) + ADD(media, mword, mopt | IFM_IEEE80211_ADHOC); + if (caps & IEEE80211_C_HOSTAP) + ADD(media, mword, mopt | IFM_IEEE80211_HOSTAP); + if (caps & IEEE80211_C_AHDEMO) + ADD(media, mword, mopt | IFM_IEEE80211_ADHOC | IFM_FLAG0); + if (caps & IEEE80211_C_MONITOR) + ADD(media, mword, mopt | IFM_IEEE80211_MONITOR); + if (caps & IEEE80211_C_WDS) + ADD(media, mword, mopt | IFM_IEEE80211_WDS); + if (caps & IEEE80211_C_MBSS) + ADD(media, mword, mopt | IFM_IEEE80211_MBSS); +#undef ADD +} + +/* + * Setup the media data structures according to the channel and + * rate tables. + */ +static int +ieee80211_media_setup(struct ieee80211com *ic, struct ifmedia *media, + int caps, int addsta) +{ + int i, j, rate, maxrate, mword, r; + enum ieee80211_phymode mode; + const struct ieee80211_rateset *rs; + struct ieee80211_rateset allrates; + + /* + * Fill in media characteristics. + */ + ifmedia_init(media, 0, + ic->ic_media_change ? ic->ic_media_change : ieee80211_media_change, + ic->ic_media_stat ? ic->ic_media_stat : ieee80211_media_status); + maxrate = 0; + /* + * Add media for legacy operating modes. + */ + memset(&allrates, 0, sizeof(allrates)); + for (mode = IEEE80211_MODE_AUTO; mode < IEEE80211_MODE_11NA; mode++) { + if (isclr(ic->ic_modecaps, mode)) + continue; + addmedia(media, caps, addsta, mode, IFM_AUTO); + if (mode == IEEE80211_MODE_AUTO) + continue; + rs = &ic->ic_sup_rates[mode]; + for (i = 0; i < rs->rs_nrates; i++) { + rate = rs->rs_rates[i]; + mword = ieee80211_rate2media(ic, rate, mode); + if (mword == 0) + continue; + addmedia(media, caps, addsta, mode, mword); + /* + * Add legacy rate to the collection of all rates. + */ + r = rate & IEEE80211_RATE_VAL; + for (j = 0; j < allrates.rs_nrates; j++) + if (allrates.rs_rates[j] == r) + break; + if (j == allrates.rs_nrates) { + /* unique, add to the set */ + allrates.rs_rates[j] = r; + allrates.rs_nrates++; + } + rate = (rate & IEEE80211_RATE_VAL) / 2; + if (rate > maxrate) + maxrate = rate; + } + } + for (i = 0; i < allrates.rs_nrates; i++) { + mword = ieee80211_rate2media(ic, allrates.rs_rates[i], + IEEE80211_MODE_AUTO); + if (mword == 0) + continue; + /* NB: remove media options from mword */ + addmedia(media, caps, addsta, + IEEE80211_MODE_AUTO, IFM_SUBTYPE(mword)); + } + /* + * Add HT/11n media. Note that we do not have enough + * bits in the media subtype to express the MCS so we + * use a "placeholder" media subtype and any fixed MCS + * must be specified with a different mechanism. + */ + for (; mode <= IEEE80211_MODE_11NG; mode++) { + if (isclr(ic->ic_modecaps, mode)) + continue; + addmedia(media, caps, addsta, mode, IFM_AUTO); + addmedia(media, caps, addsta, mode, IFM_IEEE80211_MCS); + } + if (isset(ic->ic_modecaps, IEEE80211_MODE_11NA) || + isset(ic->ic_modecaps, IEEE80211_MODE_11NG)) { + addmedia(media, caps, addsta, + IEEE80211_MODE_AUTO, IFM_IEEE80211_MCS); + i = ic->ic_txstream * 8 - 1; + if ((ic->ic_htcaps & IEEE80211_HTCAP_CHWIDTH40) && + (ic->ic_htcaps & IEEE80211_HTCAP_SHORTGI40)) + rate = ieee80211_htrates[i].ht40_rate_400ns; + else if ((ic->ic_htcaps & IEEE80211_HTCAP_CHWIDTH40)) + rate = ieee80211_htrates[i].ht40_rate_800ns; + else if ((ic->ic_htcaps & IEEE80211_HTCAP_SHORTGI20)) + rate = ieee80211_htrates[i].ht20_rate_400ns; + else + rate = ieee80211_htrates[i].ht20_rate_800ns; + if (rate > maxrate) + maxrate = rate; + } + return maxrate; +} + +/* + * Default reset method for use with the ioctl support. This + * method is invoked after any state change in the 802.11 + * layer that should be propagated to the hardware but not + * require re-initialization of the 802.11 state machine (e.g + * rescanning for an ap). We always return ENETRESET which + * should cause the driver to re-initialize the device. Drivers + * can override this method to implement more optimized support. + */ +static int +default_reset(struct ieee80211vap *vap, u_long cmd) +{ + return ENETRESET; +} + +/* + * Add underlying device errors to vap errors. + */ +static uint64_t +ieee80211_get_counter(struct ifnet *ifp, ift_counter cnt) +{ + struct ieee80211vap *vap = ifp->if_softc; + struct ieee80211com *ic = vap->iv_ic; + uint64_t rv; + + rv = if_get_counter_default(ifp, cnt); + switch (cnt) { + case IFCOUNTER_OERRORS: + rv += counter_u64_fetch(ic->ic_oerrors); + break; + case IFCOUNTER_IERRORS: + rv += counter_u64_fetch(ic->ic_ierrors); + break; + default: + break; + } + + return (rv); +} + static const char wlanname[] = "wlan"; static struct if_clone *wlan_cloner; @@ -73,9 +250,11 @@ static int wlan_clone_create(struct if_clone *ifc, int unit, caddr_t params) { struct ieee80211_clone_params cp; + struct ifmediareq imr; struct ieee80211vap *vap; struct ieee80211com *ic; - int error; + struct ifnet *ifp; + int maxrate, error; error = copyin(params, &cp, sizeof(cp)); if (error) @@ -103,12 +282,170 @@ wlan_clone_create(struct if_clone *ifc, int unit, ic_printf(ic, "TDMA not supported\n"); return EOPNOTSUPP; } - vap = ic->ic_vap_create(ic, wlanname, unit, - cp.icp_opmode, cp.icp_flags, cp.icp_bssid, - cp.icp_flags & IEEE80211_CLONE_MACADDR ? - cp.icp_macaddr : ic->ic_macaddr); + if (!TAILQ_EMPTY(&ic->ic_vaps) && + !(ic->ic_caps & IEEE80211_C_MULTIVAP)) { + ic_printf(ic, "can have only one interface configured"); + return (EBUSY); + } - return (vap == NULL ? EIO : 0); + if (ic->ic_vap_preattach && (error = + ic->ic_vap_preattach(ic, cp.icp_opmode, cp.icp_flags)) != 0) + return (error); + + vap = malloc(sizeof(struct ieee80211vap), M_80211_VAP, M_WAITOK | + M_ZERO); + ifp = if_alloc(IFT_ETHER); + KASSERT(ifp != NULL, ("%s: failed to allocate ifnet")); + + if_initname(ifp, wlanname, unit); + ifp->if_softc = vap; /* back pointer */ + ifp->if_flags = IFF_SIMPLEX | IFF_BROADCAST | IFF_MULTICAST; + ifp->if_transmit = ieee80211_vap_transmit; + ifp->if_qflush = ieee80211_vap_qflush; + ifp->if_ioctl = ieee80211_ioctl; + ifp->if_init = ieee80211_init; + ifp->if_get_counter = ieee80211_get_counter; + + vap->iv_ifp = ifp; + vap->iv_ic = ic; + vap->iv_flags = ic->ic_flags; /* propagate common flags */ + vap->iv_flags_ext = ic->ic_flags_ext; + vap->iv_flags_ven = ic->ic_flags_ven; + vap->iv_caps = ic->ic_caps &~ IEEE80211_C_OPMODE; + vap->iv_htcaps = ic->ic_htcaps; + vap->iv_htextcaps = ic->ic_htextcaps; + vap->iv_opmode = cp.icp_opmode; + vap->iv_caps |= ieee80211_opcap[cp.icp_opmode]; + switch (cp.icp_opmode) { + case IEEE80211_M_WDS: + /* + * WDS links must specify the bssid of the far end. + * For legacy operation this is a static relationship. + * For non-legacy operation the station must associate + * and be authorized to pass traffic. Plumbing the + * vap to the proper node happens when the vap + * transitions to RUN state. + */ + IEEE80211_ADDR_COPY(vap->iv_des_bssid, cp.icp_bssid); + vap->iv_flags |= IEEE80211_F_DESBSSID; + if (cp.icp_flags & IEEE80211_CLONE_WDSLEGACY) + vap->iv_flags_ext |= IEEE80211_FEXT_WDSLEGACY; + break; +#ifdef IEEE80211_SUPPORT_TDMA + case IEEE80211_M_AHDEMO: + if (cp.icp_flags & IEEE80211_CLONE_TDMA) { + /* NB: checked before clone operation allowed */ + KASSERT(ic->ic_caps & IEEE80211_C_TDMA, + ("not TDMA capable, ic_caps 0x%x", ic->ic_caps)); + /* + * Propagate TDMA capability to mark vap; this + * cannot be removed and is used to distinguish + * regular ahdemo operation from ahdemo+tdma. + */ + vap->iv_caps |= IEEE80211_C_TDMA; + } + break; +#endif + default: + break; + } + /* auto-enable s/w beacon miss support */ + if (cp.icp_flags & IEEE80211_CLONE_NOBEACONS) + vap->iv_flags_ext |= IEEE80211_FEXT_SWBMISS; + /* auto-generated or user supplied MAC address */ + if (cp.icp_flags & (IEEE80211_CLONE_BSSID|IEEE80211_CLONE_MACADDR)) + vap->iv_flags_ext |= IEEE80211_FEXT_UNIQMAC; + /* + * Enable various functionality by default if we're + * capable; the driver can override us if it knows better. + */ + if (vap->iv_caps & IEEE80211_C_WME) + vap->iv_flags |= IEEE80211_F_WME; + if (vap->iv_caps & IEEE80211_C_BURST) + vap->iv_flags |= IEEE80211_F_BURST; + /* NB: bg scanning only makes sense for station mode right now */ + if (vap->iv_opmode == IEEE80211_M_STA && + (vap->iv_caps & IEEE80211_C_BGSCAN)) + vap->iv_flags |= IEEE80211_F_BGSCAN; + vap->iv_flags |= IEEE80211_F_DOTH; /* XXX no cap, just ena */ + /* NB: DFS support only makes sense for ap mode right now */ + if (vap->iv_opmode == IEEE80211_M_HOSTAP && + (vap->iv_caps & IEEE80211_C_DFS)) + vap->iv_flags_ext |= IEEE80211_FEXT_DFS; + + vap->iv_des_chan = IEEE80211_CHAN_ANYC; /* any channel is ok */ + vap->iv_bmissthreshold = IEEE80211_HWBMISS_DEFAULT; + vap->iv_dtim_period = IEEE80211_DTIM_DEFAULT; + /* + * Install a default reset method for the ioctl support; + * the driver can override this. + */ + vap->iv_reset = default_reset; + + ieee80211_sysctl_vattach(vap); + ieee80211_crypto_vattach(vap); + ieee80211_node_vattach(vap); + ieee80211_power_vattach(vap); + ieee80211_proto_vattach(vap); +#ifdef IEEE80211_SUPPORT_SUPERG + ieee80211_superg_vattach(vap); +#endif + ieee80211_ht_vattach(vap); + ieee80211_scan_vattach(vap); + ieee80211_regdomain_vattach(vap); + ieee80211_radiotap_vattach(vap); + ieee80211_ratectl_set(vap, IEEE80211_RATECTL_NONE); + + /* + * Let device driver allocate its per-vap softc, and + * optionally override some vap methods. + */ + ic->ic_vap_postattach(ic, vap); + + /* Default to opmode of new vap. */ + ic->ic_opmode = cp.icp_opmode; + + /* + * Do late attach work that cannot happen until after + * the driver has had a chance to override defaults. + * + * XXXGL: the late attach requires iv_myaddr, so we + * need to temporarily set it. + */ + vap->iv_myaddr = cp.icp_flags & IEEE80211_CLONE_MACADDR ? + cp.icp_macaddr : ic->ic_macaddr; + ieee80211_node_latevattach(vap); + ieee80211_power_latevattach(vap); + + maxrate = ieee80211_media_setup(ic, &vap->iv_media, vap->iv_caps, + vap->iv_opmode == IEEE80211_M_STA); + ieee80211_media_status(ifp, &imr); + /* NB: strip explicit mode; we're actually in autoselect */ + ifmedia_set(&vap->iv_media, + imr.ifm_active &~ (IFM_MMASK | IFM_IEEE80211_TURBO)); + if (maxrate) + ifp->if_baudrate = IF_Mbps(maxrate); + ether_ifattach(ifp, cp.icp_flags & IEEE80211_CLONE_MACADDR ? + cp.icp_macaddr : ic->ic_macaddr); + vap->iv_myaddr = IF_LLADDR(ifp); + /* hook output method setup by ether_ifattach */ + vap->iv_output = ifp->if_output; + ifp->if_output = ieee80211_output; + /* NB: if_mtu set by ether_ifattach to ETHERMTU */ + + IEEE80211_LOCK(ic); + TAILQ_INSERT_TAIL(&ic->ic_vaps, vap, iv_next); + ieee80211_syncflag_locked(ic, IEEE80211_F_WME); +#ifdef IEEE80211_SUPPORT_SUPERG + ieee80211_syncflag_locked(ic, IEEE80211_F_TURBOP); +#endif + ieee80211_syncflag_locked(ic, IEEE80211_F_PCF); + ieee80211_syncflag_locked(ic, IEEE80211_F_BURST); + ieee80211_syncflag_ht_locked(ic, IEEE80211_FHT_HT); + ieee80211_syncflag_ht_locked(ic, IEEE80211_FHT_USEHT40); + IEEE80211_UNLOCK(ic); + + return (0); } static void Index: sys/net80211/ieee80211_proto.h =================================================================== --- sys/net80211/ieee80211_proto.h (revision 287554) +++ sys/net80211/ieee80211_proto.h (working copy) @@ -61,6 +61,9 @@ void ieee80211_allmulti(struct ieee80211vap *, boo void ieee80211_syncflag(struct ieee80211vap *, int flag); void ieee80211_syncflag_ht(struct ieee80211vap *, int flag); void ieee80211_syncflag_ext(struct ieee80211vap *, int flag); +void ieee80211_syncflag_locked(struct ieee80211com *, int); +void ieee80211_syncflag_ht_locked(struct ieee80211com *, int); +void ieee80211_syncflag_ext_locked(struct ieee80211com *, int); #define IEEE80211_R_NF 0x0000001 /* global NF value valid */ #define IEEE80211_R_RSSI 0x0000002 /* global RSSI value valid */ Index: sys/net80211/ieee80211_var.h =================================================================== --- sys/net80211/ieee80211_var.h (revision 287554) +++ sys/net80211/ieee80211_var.h (working copy) @@ -235,11 +235,10 @@ struct ieee80211com { int ic_montaps; /* active monitor mode taps */ /* virtual ap create/delete */ - struct ieee80211vap* (*ic_vap_create)(struct ieee80211com *, - const char [IFNAMSIZ], int, - enum ieee80211_opmode, int, - const uint8_t [IEEE80211_ADDR_LEN], - const uint8_t [IEEE80211_ADDR_LEN]); + int (*ic_vap_preattach)(struct ieee80211com *, + enum ieee80211_opmode, int); + void (*ic_vap_postattach)(struct ieee80211com *, + struct ieee80211vap *); void (*ic_vap_delete)(struct ieee80211vap *); /* device specific ioctls */ int (*ic_ioctl)(struct ieee80211com *, @@ -269,6 +268,10 @@ struct ieee80211com { int (*ic_raw_xmit)(struct ieee80211_node *, struct mbuf *, const struct ieee80211_bpf_params *); + /* media change */ + ifm_change_cb_t ic_media_change; + ifm_stat_cb_t ic_media_stat; + /* update device state for 802.11 slot time change */ void (*ic_updateslot)(struct ieee80211com *); /* handle multicast state changes */ @@ -353,6 +356,7 @@ struct ieee80211_hwmp_state; struct ieee80211vap { struct ifmedia iv_media; /* interface media config */ struct ifnet *iv_ifp; /* associated device */ + void *iv_softc; /* driver's softc */ struct bpf_if *iv_rawbpf; /* packet filter structure */ struct sysctl_ctx_list *iv_sysctl; /* dynamic sysctl context */ struct sysctl_oid *iv_oid; /* net.wlan.X sysctl oid */ @@ -644,7 +648,8 @@ MALLOC_DECLARE(M_80211_VAP); #define IEEE80211_C_DFS 0x00020000 /* CAPABILITY: DFS/radar avail*/ #define IEEE80211_C_MBSS 0x00040000 /* CAPABILITY: MBSS available */ #define IEEE80211_C_SWSLEEP 0x00080000 /* CAPABILITY: do sleep here */ -/* 0x7c0000 available */ +#define IEEE80211_C_MULTIVAP 0x00100000 /* CAPABILITY: > 1 vaps */ +/* 0x6c0000 available */ #define IEEE80211_C_WPA1 0x00800000 /* CAPABILITY: WPA1 avail */ #define IEEE80211_C_WPA2 0x01000000 /* CAPABILITY: WPA2 avail */ #define IEEE80211_C_WPA 0x01800000 /* CAPABILITY: WPA1+WPA2 avail*/ @@ -692,13 +697,6 @@ MALLOC_DECLARE(M_80211_VAP); int ic_printf(struct ieee80211com *, const char *, ...) __printflike(2, 3); void ieee80211_ifattach(struct ieee80211com *); void ieee80211_ifdetach(struct ieee80211com *); -int ieee80211_vap_setup(struct ieee80211com *, struct ieee80211vap *, - const char name[IFNAMSIZ], int unit, - enum ieee80211_opmode opmode, int flags, - const uint8_t bssid[IEEE80211_ADDR_LEN]); -int ieee80211_vap_attach(struct ieee80211vap *, - ifm_change_cb_t, ifm_stat_cb_t, - const uint8_t macaddr[IEEE80211_ADDR_LEN]); void ieee80211_vap_detach(struct ieee80211vap *); const struct ieee80211_rateset *ieee80211_get_suprates(struct ieee80211com *ic, const struct ieee80211_channel *); --mxv5cy4qt+RJ9ypb-- From owner-freebsd-net@freebsd.org Tue Sep 8 15:26:46 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8090D9CC62E for ; Tue, 8 Sep 2015 15:26:46 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 627081AF6 for ; Tue, 8 Sep 2015 15:26:46 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 618B59CC62C; Tue, 8 Sep 2015 15:26:46 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4749C9CC62B; Tue, 8 Sep 2015 15:26:46 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 113151AF5; Tue, 8 Sep 2015 15:26:46 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by ioii196 with SMTP id i196so122225199ioi.3; Tue, 08 Sep 2015 08:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=PjEEAJ6MXKlEi8jeDAZuQplNulqmDWvUc6dvu8VLBtY=; b=a9s+v3VsXigsetCb7csWhjcxmGajbZbQ0bzSkJiGdvFsjUhYoCXaXEu9JxuoPeusTg +9sP2u6AZA8CxHql9RGn/ONFb7/R6hgrviCJovSuRZ1TNtZCcE9eelaRREhOS0xO+IVg hMd9pVHB1YryswFlGOvdxUmkEIH+pAJWjW9XjtK+eNbVAH1PsSpQoBN7FTNjl3xEKa2G jy1G6REzz7z5uG7ru7HsMwGUG8s/JumX9tcmj4ql4vcHFlBJZqF/eyQQYc4zcYX8MYVh Up6zikXyxXGsorwPoQj6kHrp9WQA7wnN/hdUptXBlY/SEooLc33IbDsC3OyztbTIDoAh 96+Q== MIME-Version: 1.0 X-Received: by 10.107.13.75 with SMTP id 72mr39721631ion.75.1441726005448; Tue, 08 Sep 2015 08:26:45 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.28.208 with HTTP; Tue, 8 Sep 2015 08:26:45 -0700 (PDT) In-Reply-To: <20150908152233.GV1023@glebius.int.ru> References: <20150908152233.GV1023@glebius.int.ru> Date: Tue, 8 Sep 2015 08:26:45 -0700 X-Google-Sender-Auth: BeLM1sfX_R_hxFYAwlUTotdWfIw Message-ID: Subject: Re: more net80211 changes :/ From: Adrian Chadd To: Gleb Smirnoff , "freebsd-wireless@freebsd.org" Cc: Andriy Voskoboinyk , "net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 15:26:46 -0000 I'm fine with this. The main odd-ball here is iwm(4) that requires interrupts to be up before the NIC is initialised (firmware), and it will do firmware loading and commands before you can get the MAC which is required for attach. Flesh it out a bit more with iwm(4) and I'll take a look at the results. :) Thanks! -adrian On 8 September 2015 at 08:22, Gleb Smirnoff wrote: > Hi! > > It looks like another sweep over net80211 drivers is required. It isn't > going to be as huge as previous one. > > The problem is that in the "new world order", there will be only if_attach(), > instead of if_alloc() / fill & hack / ether_ifattach. What right now happens > with net80211 is that all drivers have the same copy & paste in their > ic_vap_create, which yields in a sequence of: > > - if_alloc > - driver specific code > - ether_ifattach > > Which isn't possible to collapse into if_attach(), since driver code is > in the middle. > > Another problem is embedding if ieee80211_vap into driver's softc. This > is a bad habit, which was proved by ifnet experience (fixed decade ago). > > What patch does: > > - Inline ieee80211_vap_setup() and ieee80211_vap_attach() into wlan_clone_create(). > Note, that this moves code from ieee80211.c to into ieee80211_freebsd.c, > which is good, since this code about interaction with ifnet layer, which > is FreeBSD specific and will be more FreeBSD specific. > As dependency ifmedia support code and ieee80211_get_counter() also naturally > move to the same file. > > - In the new long wlan_clone_create(), after initial error checking call > ic_vap_preattach() to allow driver do its own error checking. I predict > that for now ath(4) will be the only driver to use ic_vap_preattach(). > > - If no errors, go with allocating and attaching the interface, and then > call ic_vap_postattach. > > - The ic_vap_postattach() for all drivers (save ath) would be remnants > of ic_vap_create(), where all copy and paste is removed and only driver > specific bits remain. > > - ic_vap_postattach() may allocate driver specific softc for vap, which > now longer has ieee80211_vap embedded. > > This also removes all ambiguities with mac address handling, which was > juggled between three functions before. > > The current patch covers iwn(4) only. Now sending this mail with patched > driver. Changing MAC aldo tested - works. > > I'm starting to convert rest of drivers and meanwhile, waiting for your > input. May be you have ideas what else can be improved here. > > -- > Totus tuus, Glebius. From owner-freebsd-net@freebsd.org Tue Sep 8 16:31:48 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A8449CCD2D for ; Tue, 8 Sep 2015 16:31:48 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2B35C17DD for ; Tue, 8 Sep 2015 16:31:48 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2A2199CCD2C; Tue, 8 Sep 2015 16:31:48 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 29BCA9CCD2B for ; Tue, 8 Sep 2015 16:31:48 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA40317DC; Tue, 8 Sep 2015 16:31:47 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: by wicge5 with SMTP id ge5so123654330wic.0; Tue, 08 Sep 2015 09:31:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:to:cc:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; bh=rBdWQ+xt6eGHCadPgy7YADwNLWVtRWIYzuMv+9p2mqA=; b=zTsReLcRoGNsuav/FXnPR7C0jfZyNlc1/DfbMoTmqADFbw14FV1gCacqeI1V7Ty3NT Dp8y88ZFjueij8Qy6CFdOXeAwrQHEz3a8C2sb+yAgEjQpTGqNoLfUowKdp6heh9XM2k6 DAyKz3NtQbMqsz9XNWD89LbsJZCF4AmZIjLzMB7B7JEq+76UK8rahT3or1kVh2Od7CU4 iXXRlop7alijYCbMlgUl5bfkMpUKlQBmaWrvcBUS3MXduga2D4a4+GtqcG3C2a5eswIh MaLE1pJ7aFHSQc6/DnCILyKNXs5eqaIpfpNOROa20JhnjptaJ2+bhqruMqpfIdsbTV3B Q9aA== X-Received: by 10.180.108.39 with SMTP id hh7mr48104752wib.3.1441729906271; Tue, 08 Sep 2015 09:31:46 -0700 (PDT) Received: from localhost (host-176-37-109-22.la.net.ua. [176.37.109.22]) by smtp.gmail.com with ESMTPSA id vl1sm5703256wjc.0.2015.09.08.09.31.45 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 08 Sep 2015 09:31:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Gleb Smirnoff" Cc: "Adrian Chadd" , "net@freebsd.org" Subject: Re: more net80211 changes :/ References: <20150908152233.GV1023@glebius.int.ru> Date: Tue, 08 Sep 2015 19:31:41 +0300 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Andriy Voskoboinyk" Message-ID: In-Reply-To: <20150908152233.GV1023@glebius.int.ru> User-Agent: Opera Mail/12.16 (FreeBSD) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 16:31:48 -0000 > The current patch covers iwn(4) only. Now sending this mail with patched > driver. Changing MAC aldo tested - works. > > I'm starting to convert rest of drivers and meanwhile, waiting for your > input. May be you have ideas what else can be improved here. > Do not forget to free iv_softc - it's allocated separately. From owner-freebsd-net@freebsd.org Tue Sep 8 17:22:54 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BBCCF9CC859 for ; Tue, 8 Sep 2015 17:22:54 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9CA1A1B9D for ; Tue, 8 Sep 2015 17:22:54 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9B8499CC858; Tue, 8 Sep 2015 17:22:54 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B1EA9CC857 for ; Tue, 8 Sep 2015 17:22:54 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 362281B9C; Tue, 8 Sep 2015 17:22:54 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: by wicgb1 with SMTP id gb1so86772377wic.1; Tue, 08 Sep 2015 10:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:to:cc:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; bh=4qxSR9vPPAOnZNM9Gjrhqv5ZOp8rZbt3oEtiTx9TNIw=; b=ANtsO66tnnMMc4ICxo/Fz+5St2SAb3nd9suWwrdb+n49W1akLlntdlwp0yCqlU1MNT VXRmW+zWLucwZZ31ufm1XNY1I8SjbcqoZORCkIHUfXdSKpUgPJgjeS7yhsi7dnxVMUBK BeLT6PVZI8kQbCwNGp1viq1jdNHG86IevieQsv5mY/26yurZmDPhKngXSC25OyArWJDv 8fngRsKB6pFdKrAPWAlYJZEX1Xt0JaJL1HS6UcxFtl0RdsLA6pFBxcPcluBwyv+RID3e XzJrJBOUNvJWKGlJBNn9jJAO5A8uWZKpwm4fbuyY6cLMSifhv9YIOkIrmXq6SetMn7dZ N6qA== X-Received: by 10.194.172.33 with SMTP id az1mr48430383wjc.57.1441732972639; Tue, 08 Sep 2015 10:22:52 -0700 (PDT) Received: from localhost (host-176-37-109-22.la.net.ua. [176.37.109.22]) by smtp.gmail.com with ESMTPSA id o10sm5916925wia.4.2015.09.08.10.22.51 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 08 Sep 2015 10:22:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Gleb Smirnoff" Cc: "Adrian Chadd" , "net@freebsd.org" Subject: Re: more net80211 changes :/ References: <20150908152233.GV1023@glebius.int.ru> Date: Tue, 08 Sep 2015 20:22:48 +0300 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Andriy Voskoboinyk" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (FreeBSD) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 17:22:54 -0000 >> The current patch covers iwn(4) only. Now sending this mail with patched >> driver. Changing MAC aldo tested - works. >> >> I'm starting to convert rest of drivers and meanwhile, waiting for your >> input. May be you have ideas what else can be improved here. >> > > Do not forget to free iv_softc - it's allocated separately. struct ieee80211_beacon_offsets can be moved to the ieee80211_vap too. From owner-freebsd-net@freebsd.org Tue Sep 8 17:28:47 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97FA59CCB46 for ; Tue, 8 Sep 2015 17:28:47 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7F5661D0A for ; Tue, 8 Sep 2015 17:28:47 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 7E4049CCB44; Tue, 8 Sep 2015 17:28:47 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7DD999CCB43 for ; Tue, 8 Sep 2015 17:28:47 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D702A1D09; Tue, 8 Sep 2015 17:28:45 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.15.2/8.15.2) with ESMTPS id t88HSfOQ052218 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 8 Sep 2015 20:28:41 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.15.2/8.15.2/Submit) id t88HSfAx052217; Tue, 8 Sep 2015 20:28:41 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 8 Sep 2015 20:28:41 +0300 From: Gleb Smirnoff To: Andriy Voskoboinyk Cc: Adrian Chadd , "net@freebsd.org" Subject: Re: more net80211 changes :/ Message-ID: <20150908172841.GW1023@glebius.int.ru> References: <20150908152233.GV1023@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 17:28:47 -0000 On Tue, Sep 08, 2015 at 07:31:41PM +0300, Andriy Voskoboinyk wrote: A> > The current patch covers iwn(4) only. Now sending this mail with patched A> > driver. Changing MAC aldo tested - works. A> > A> > I'm starting to convert rest of drivers and meanwhile, waiting for your A> > input. May be you have ideas what else can be improved here. A> > A> A> Do not forget to free iv_softc - it's allocated separately. Thanks for review :) -- Totus tuus, Glebius. From owner-freebsd-net@freebsd.org Tue Sep 8 20:31:02 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F1282A004B7 for ; Tue, 8 Sep 2015 20:31:02 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CBDA91516 for ; Tue, 8 Sep 2015 20:31:02 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id C91EBA004B6; Tue, 8 Sep 2015 20:31:02 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8AA9A004B5 for ; Tue, 8 Sep 2015 20:31:02 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8138F1508 for ; Tue, 8 Sep 2015 20:31:01 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from alph.d.allbsd.org (alph.d.allbsd.org [IPv6:2001:2f0:104:e010:862b:2bff:febc:8956] (may be forged)) (authenticated bits=56) by mail.allbsd.org (8.14.9/8.14.9) with ESMTP id t88KUl7I064860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 9 Sep 2015 05:30:47 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.9/8.14.9) with ESMTP id t88KUjM0049739 for ; Wed, 9 Sep 2015 05:30:47 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 09 Sep 2015 05:30:03 +0900 (JST) Message-Id: <20150909.053003.1234482271945809368.hrs@allbsd.org> To: net@FreeBSD.org Subject: PF_LOCAL support in getaddrinfo/getnameinfo From: Hiroki Sato X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Wed_Sep__9_05_30_03_2015_796)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.98.6 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Wed, 09 Sep 2015 05:30:53 +0900 (JST) X-Spam-Status: No, score=-98.0 required=13.0 tests=CONTENT_TYPE_PRESENT, RCVD_IN_AHBL, RCVD_IN_AHBL_PROXY, RCVD_IN_AHBL_SPAM, RDNS_NONE, USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on gatekeeper.allbsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 20:31:03 -0000 ----Security_Multipart0(Wed_Sep__9_05_30_03_2015_796)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Wed_Sep__9_05_30_03_2015_346)--" Content-Transfer-Encoding: 7bit ----Next_Part(Wed_Sep__9_05_30_03_2015_346)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Is there any problem with adding PF_LOCAL support into getaddrinfo() and getnameinfo()? It was not standardized but can be implemented in a straight forward way (attached). Some old posts in mailing list archives (not for FreeBSD) said it was removed in glibc due to a security issue that getaddrinfo() call with PF_UNSPEC could create /tmp/ unintentionally when no hostname was resolved. IIRC KAME's original implementation included this functionality, but I am not sure of why it was removed. Does anyone know the reason, or other potential problems? In the attached patch PF_LOCAL is not used when getaddrinfo() is called with PF_UNSPEC, and only an absolute pathname is accepted. This should not have a bad side-effect for the existing programs which use them. -- Hiroki ----Next_Part(Wed_Sep__9_05_30_03_2015_346)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="getaddrinfo_unix.20150909-1.diff" Index: lib/libc/net/getaddrinfo.c =================================================================== --- lib/libc/net/getaddrinfo.c (revision 287348) +++ lib/libc/net/getaddrinfo.c (working copy) @@ -137,13 +137,19 @@ offsetof(struct sockaddr_in6, sin6_addr), in6_addrany, in6_loopback, 1}, #define N_INET 1 +#define N_LOCAL 2 #else #define N_INET 0 +#define N_LOCAL 1 #endif {PF_INET, sizeof(struct in_addr), sizeof(struct sockaddr_in), offsetof(struct sockaddr_in, sin_addr), in_addrany, in_loopback, 0}, + {PF_LOCAL, sizeof(char[104]), + sizeof(struct sockaddr_un), + offsetof(struct sockaddr_un, sun_path), + NULL, NULL, 0}, {0, 0, 0, 0, NULL, NULL, 0}, }; @@ -158,9 +164,9 @@ }; static const struct explore explore[] = { -#if 0 - { PF_LOCAL, ANY, ANY, 0x01 }, -#endif + { PF_LOCAL, SOCK_DGRAM, ANY, 0x04 }, + { PF_LOCAL, SOCK_STREAM, ANY, 0x04 }, + { PF_LOCAL, SOCK_SEQPACKET, ANY, 0x04 }, #ifdef INET6 { PF_INET6, SOCK_DGRAM, IPPROTO_UDP, 0x07 }, { PF_INET6, SOCK_STREAM, IPPROTO_TCP, 0x07 }, @@ -408,6 +414,7 @@ ERR(EAI_BADFLAGS); switch (hints->ai_family) { case PF_UNSPEC: + case PF_LOCAL: case PF_INET: #ifdef INET6 case PF_INET6: @@ -1130,6 +1137,9 @@ *res = NULL; ai = NULL; + if (pai->ai_family == PF_LOCAL) + return (0); + /* * filter out AFs that are not supported by the kernel * XXX errno? @@ -1172,7 +1182,7 @@ const struct afd *afd; struct addrinfo *ai; int error; - char pton[PTON_MAX]; + char pton[PTON_MAX], path[PATH_MAX], *p; *res = NULL; ai = NULL; @@ -1182,6 +1192,15 @@ return 0; switch (afd->a_af) { + case AF_LOCAL: + if (hostname[0] != '/') + ERR(EAI_FAIL); + if (strlen(hostname) > afd->a_addrlen) + ERR(EAI_MEMORY); + /* NUL-termination does not need to be guaranteed. */ + strncpy(path, hostname, afd->a_addrlen); + p = &path[0]; + break; case AF_INET: /* * RFC3493 requires getaddrinfo() to accept AF_INET formats @@ -1192,15 +1211,17 @@ */ if (inet_aton(hostname, (struct in_addr *)pton) != 1) return 0; + p = pton; break; default: if (inet_pton(afd->a_af, hostname, pton) != 1) return 0; + p = pton; break; } if (pai->ai_family == afd->a_af) { - GET_AI(ai, afd, pton); + GET_AI(ai, afd, p); GET_PORT(ai, servname); if ((pai->ai_flags & AI_CANONNAME)) { /* @@ -1320,6 +1341,12 @@ memset(ai->ai_addr, 0, (size_t)afd->a_socklen); ai->ai_addr->sa_len = afd->a_socklen; ai->ai_addrlen = afd->a_socklen; + if (ai->ai_family == PF_LOCAL) { + size_t n = strlen(addr); + + ai->ai_addrlen -= afd->a_addrlen - n; + ai->ai_addr->sa_len -= afd->a_addrlen - n; + } ai->ai_addr->sa_family = ai->ai_family = afd->a_af; p = (char *)(void *)(ai->ai_addr); memcpy(p + afd->a_off, addr, (size_t)afd->a_addrlen); Index: lib/libc/net/getnameinfo.c =================================================================== --- lib/libc/net/getnameinfo.c (revision 287404) +++ lib/libc/net/getnameinfo.c (working copy) @@ -49,6 +49,7 @@ #include #include +#include #include #include #include @@ -72,6 +73,8 @@ static int getnameinfo_link(const struct sockaddr *, socklen_t, char *, size_t, char *, size_t, int); static int hexname(const u_int8_t *, size_t, char *, size_t); +static int getnameinfo_un(const struct sockaddr *, socklen_t, char *, + size_t, char *, size_t, int); int getnameinfo(const struct sockaddr *sa, socklen_t salen, @@ -89,6 +92,9 @@ case AF_LINK: return getnameinfo_link(sa, salen, host, hostlen, serv, servlen, flags); + case AF_LOCAL: + return getnameinfo_un(sa, salen, host, hostlen, serv, + servlen, flags); default: return EAI_FAMILY; } @@ -106,6 +112,8 @@ #endif {PF_INET, sizeof(struct in_addr), sizeof(struct sockaddr_in), offsetof(struct sockaddr_in, sin_addr)}, + {PF_LOCAL, sizeof(char[104]), sizeof(struct sockaddr_un), + offsetof(struct sockaddr_un, sun_path)}, {0, 0, 0}, }; @@ -469,3 +477,39 @@ } return 0; } + +/* + * getnameinfo_un(): + * Format a pathname of UNIX IPC domain socket. + */ +/* ARGSUSED */ +static int +getnameinfo_un(const struct sockaddr *sa, socklen_t salen, + char *host, size_t hostlen, char *serv, size_t servlen, int flags) +{ + const struct afd *afd; + size_t pathlen; + const char *addr; + + for (afd = &afdl[0]; afd != NULL; afd++) { + if (afd->a_af == AF_LOCAL) + break; + } + if (afd == NULL) + return (EAI_FAIL); + + if (serv != NULL && servlen > 0) + *serv = '\0'; + + pathlen = sa->sa_len - afd->a_off; + addr = (const char *)sa + afd->a_off; + + if (pathlen + 1 > hostlen) { + *host = '\0'; + return (EAI_MEMORY); + } + memcpy(host, addr, pathlen); + host[pathlen] = '\0'; + + return (0); +} ----Next_Part(Wed_Sep__9_05_30_03_2015_346)---- ----Security_Multipart0(Wed_Sep__9_05_30_03_2015_796)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlXvRUsACgkQTyzT2CeTzy1ntwCfVVjKrge/tit8wG8mxSzi6slf +nEAn1qhOGKsve8Zx7xz8rDKeNsyEZQZ =bzYI -----END PGP SIGNATURE----- ----Security_Multipart0(Wed_Sep__9_05_30_03_2015_796)---- From owner-freebsd-net@freebsd.org Tue Sep 8 23:53:17 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 768949CD1D6 for ; Tue, 8 Sep 2015 23:53:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 631D61E86 for ; Tue, 8 Sep 2015 23:53:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t88NrHlG010477 for ; Tue, 8 Sep 2015 23:53:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202960] Kernel panic when bridging e1000 NIC with pf rules Date: Tue, 08 Sep 2015 23:53:17 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 23:53:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202960 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org Keywords| |IntelNetworking -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Wed Sep 9 00:13:16 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BC2B7A00069 for ; Wed, 9 Sep 2015 00:13:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A8FF4184D for ; Wed, 9 Sep 2015 00:13:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t890DG84083794 for ; Wed, 9 Sep 2015 00:13:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202960] Kernel panic when bridging e1000 NIC with pf rules Date: Wed, 09 Sep 2015 00:13:16 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: jeffrey@endrift.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 00:13:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202960 --- Comment #2 from jeffrey@endrift.com --- I was able to work around this by adding a pf rule that drops incoming IPv6 multicast traffic to em0. Suboptimal, but no more kernel panics. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Wed Sep 9 04:57:16 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 852049CCDEC for ; Wed, 9 Sep 2015 04:57:16 +0000 (UTC) (envelope-from bored_to_death85@yahoo.com) Received: from nm35-vm2.bullet.mail.gq1.yahoo.com (nm35-vm2.bullet.mail.gq1.yahoo.com [98.136.216.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 53A13190D for ; Wed, 9 Sep 2015 04:57:16 +0000 (UTC) (envelope-from bored_to_death85@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1441774530; bh=QB3qZvS3qM2E1wmx+HXOu5SD/ur+U5BoAuaB9WFkuWM=; h=Date:From:Subject:To:Cc:In-Reply-To:From:Subject; b=CObEVVYoUUIYYjySvp0p3T0TjZhVFn/LvuH5xlEkY2IVEK7zwiZdQDGeK4i0P8H8dD0AmGMT7Nr3tTuaZaQrAOmIP+0vRzMjOiQH0f+DvKdhabiedP6sJNInWstmix8WWtKesKTD29zIn6IVkJ3Nqk4OzHjU+pt1t1pI728AUxLSvISFTKHzx+4Y+buLrxAcjJs4FVPqrfjy/DMwsrWqf2rUlfqsL7BD7wHxJhK5psyY0ovdM60U7nqFcaBA9mTjUfv9Lw6/dPgtU9QyWk61KiC+bfP0UlC6oESSsASBW8sRJL7jlY40k+yCFc6QAYXw8eSq2zQ1BG9QddoRI3CatA== Received: from [127.0.0.1] by nm35.bullet.mail.gq1.yahoo.com with NNFMP; 09 Sep 2015 04:55:30 -0000 Received: from [216.39.60.184] by nm35.bullet.mail.gq1.yahoo.com with NNFMP; 09 Sep 2015 04:52:38 -0000 Received: from [98.139.215.143] by tm20.bullet.mail.gq1.yahoo.com with NNFMP; 09 Sep 2015 04:52:38 -0000 Received: from [98.139.212.227] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 09 Sep 2015 04:52:38 -0000 Received: from [127.0.0.1] by omp1036.mail.bf1.yahoo.com with NNFMP; 09 Sep 2015 04:52:38 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 196316.5692.bm@omp1036.mail.bf1.yahoo.com Received: (qmail 75978 invoked by uid 60001); 9 Sep 2015 04:52:38 -0000 X-YMail-OSG: 8JJWy8QVM1ksA2z.ZPvhfAH2V_h9nH4KrFK_.XmNAn_9eej lNQC5wslCxC_XLiu7UA4dMxvteG9yajYiYAY3ntMhHctMYeniwfHnkKMBkWs 0xdt2CKJ2pk1O7Fqs.MF.6J4ZtWMvUeWgASbIijPN_U3_vIgWPt4k6H.Q68c qgDjU9htGEZBDSnSFuoZtBiq5Cctosh9wT1LNZ8.OuWrae8aldj3Vo6j1bqf Gec4z6b_I9pFIE8XP06m6yOcVYvyACaKevJGf4n2XYB7y7GTQElA_h2K.d7Z Ss9gS1LFl1Cho.mTmSdpKRMI.m3NWXXjVWYcWx46j3UgsAUfY21WNK8zEW31 bFdctjntmrFvXVgFr8F5IqTOBtzcrLSPifzq0XAG0I51meOcuvoOI2JJzAsS .LF1wq493dUG9KLpbpFmZhsYieBUX3mh06_5ChBrqug4A98YZmoFLD6PQ3mS bmsFiT2KRpbO8WrkrHAh0St8vTJRhddF0mrKr64ExoCr_A4ZIgid2oV4ZmYF XhykFxcdlucn5080g0vYj1JONVyVNcQsVNr0cC9sjI75OfARLfU2APRhq8FT 0zwi5xSdhk20SgaKFhd_SqBgtAi8Cfv9H Received: from [2.180.36.214] by web165005.mail.bf1.yahoo.com via HTTP; Tue, 08 Sep 2015 21:52:38 PDT X-Rocket-MIMEInfo: 002.001, SGkgZ3V5cywNCg0KT24gU3VuLCA5LzYvMTUsIEFydGVtIEJlbGV2aWNoIDxhcnRlbWJAZ21haWwuY29tPiB3cm90ZToNCj4gV2hpbGUgeW91IGNhbiBpbmRlZWQgc2V0IHNwZWVkL2R1cGxleCBtYW51YWxseSwgeW91IHdpbGwgYWxzbyBuZWVkDQo.IHRvIG1ha2Ugc3VyZSBib3RoIGhhdmUgaGF2ZSBwcm9wZXIgY2xvY2sgbWFzdGVyL3NsYXZlDQo.IMKgc2VsZWN0aW9uIMKgd2hpY2ggaXMgbm9ybWFsbHkgZG9uZSB2aWEgYXV0b25lZ290aWF0aW9uLiBPbg0KPiBGcmVlYnNkIHNvbWUgaW50ZXJmYWNlcyBzdXABMAEBAQE- X-Mailer: YahooMailBasic/651 YahooMailWebService/0.8.203.813 Message-ID: <1441774358.73226.YahooMailBasic@web165005.mail.bf1.yahoo.com> Date: Tue, 8 Sep 2015 21:52:38 -0700 From: "M. V." Subject: Re: Problem with receiving packets right after remote-interface is up To: Artem Belevich Cc: "freebsd-net@freebsd.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 04:57:16 -0000 Hi guys, On Sun, 9/6/15, Artem Belevich wrote: > While you can indeed set speed/duplex manually, you will also need > to make sure both have have proper clock master/slave > =A0selection =A0which is normally done via autonegotiation. On > Freebsd some interfaces support "mediaopt master" > option .. Thanks again for your answer. I continuted tests on this yesterday, and I f= ound root of the problem. As I told you, I checked ifconfig and there was n= o support for changing master/slave option. Yesterday I tested to see if th= is master/slave option affects my tests. I found out every time interface o= f remote system gets down and up, If our interface gets slave, everything i= s ok, but anytime our interface gets master, we don't receive sent packets = in the first second after getting up. So I changed driver code to manualy force interface to get slave (by changi= ng values of 82574's related registers) and my problem was solved completel= y (even with auto-neg. enabled) It seems getting master needs extra work and extra time to setup in hardwar= e level ('cause I didn't find any code in driver to do things differently w= hen we are master).=20 So my question is,=20 - Is there anything I can do to make my scenario work in master-mode too? (= interestingly cisco router doesn't have this problem in both master/slave m= odes) - Is it OK to force interface to always gets slave like this? (I found no p= roblem in my tests. I even checked what happens if 2 connected ports both w= ere forced to be slave. In that situation one of the ports gets master even= though we manually set it to slave, so connection is OK) Thank you. > On Saturday, September 5, 2015, M. V. via freebsd-net > < freebsd-net@freebsd.org> wrote:=20 >> Our product is being tested with Spirent TestCenter, >> and we're facing an unusual problem with the tests. >> We use NICs with intel 82574 and 82576 on FreeBSD 9.2 >> with latest em and igb drivers (we also tested this on=20 >> FreeBSD-10.1) It seems what Spirent TestCenter does to=20 >> start any individual test is, it disables its own interface,=20 >> and at the beginning of the new test, it suddenly "up"s its=20 >> interface and sends test packet right after that. >> This is where we have problem, and we don't receive this >> first packets most of the time (result is vary, in 100 tests,=20 >> we lose about 60~70% of this "first" packets on each test, >> so we FAIL most of tests because apparently we need >> about 0.5~1 seconds after setup and renegotiation >> before we can receive packets) =20 From owner-freebsd-net@freebsd.org Wed Sep 9 06:09:47 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 185BEA0032E for ; Wed, 9 Sep 2015 06:09:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 047CA1875 for ; Wed, 9 Sep 2015 06:09:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8969kS9075270 for ; Wed, 9 Sep 2015 06:09:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202875] ixv driver in 11.0-CURRENT doesn't pass traffic using KVM hypervisor Date: Wed, 09 Sep 2015 06:09:47 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: jlpetz@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 06:09:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202875 Jarrod Petz changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jlpetz@gmail.com --- Comment #7 from Jarrod Petz --- This bug reminded me that I have the same issue. But instead of KVM on Xen+Qemu(AWS EC2). So as not to pollute this Bug I filled it separately as Bug 202983. But thought I would post an FYI here incase it is related or incase you think patches/changes here might help me and would like them tested. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Wed Sep 9 06:13:51 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B9A2A00619 for ; Wed, 9 Sep 2015 06:13:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 177AE1BE2 for ; Wed, 9 Sep 2015 06:13:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t896Do0C015988 for ; Wed, 9 Sep 2015 06:13:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202983] ixv driver in 11.0-CURRENT(10.1 & 10.2 RELEASE) doesn't pass traffic using XEN hypervisor(AWS EC2) Date: Wed, 09 Sep 2015 06:13:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 06:13:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202983 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Wed Sep 9 16:39:15 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23AFFA00C76 for ; Wed, 9 Sep 2015 16:39:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0FF551DCD for ; Wed, 9 Sep 2015 16:39:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t89GdEri001706 for ; Wed, 9 Sep 2015 16:39:14 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202875] ixv driver in 11.0-CURRENT doesn't pass traffic using KVM hypervisor Date: Wed, 09 Sep 2015 16:39:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: jeffrey.e.pieper@intel.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 16:39:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202875 --- Comment #8 from Jeff Pieper --- (In reply to Patrick Kelsey from comment #6) After performing some additional testing, this is what I have discovered: - Reverting r285590 and r285592 do not fix the issue. - I can reproduce the issue using our OOT driver on CURRENT. - in ALL failing scenarios, I see the following in dmesg on the host after init: ixgbe 0000:08:00.0 eth0: VF max_frame 1522 out of range So I think it's safe to say that it isn't the driver causing this, but something else that is causing oversized frames. In summary: - 10.2 works using in-kernel and OOT drivers. - CURRENT fails using in-kernel and OOT drivers. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Thu Sep 10 00:13:43 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8F4F09CDA37 for ; Thu, 10 Sep 2015 00:13:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7B404153B for ; Thu, 10 Sep 2015 00:13:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8A0Dh3Y049876 for ; Thu, 10 Sep 2015 00:13:43 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202960] Kernel panic when bridging e1000 NIC with pf rules Date: Thu, 10 Sep 2015 00:13:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 00:13:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202960 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress CC| |ae@FreeBSD.org, | |kp@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Thu Sep 10 00:14:05 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9922C9CDA70 for ; Thu, 10 Sep 2015 00:14:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 852681600 for ; Thu, 10 Sep 2015 00:14:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8A0E5Bi053546 for ; Thu, 10 Sep 2015 00:14:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202960] Kernel panic when bridging e1000 NIC with pf rules Date: Thu, 10 Sep 2015 00:14:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 00:14:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202960 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|In Progress |Closed --- Comment #3 from Andrey V. Elsukov --- *** This bug has been marked as a duplicate of bug 202351 *** -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Thu Sep 10 00:18:13 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33AA19CDD17 for ; Thu, 10 Sep 2015 00:18:13 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.strugglingcoder.info", Issuer "mail.strugglingcoder.info" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2372D187F; Thu, 10 Sep 2015 00:18:12 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 20359BF60D; Wed, 9 Sep 2015 17:18:06 -0700 (PDT) Date: Wed, 9 Sep 2015 17:18:06 -0700 From: hiren panchasara To: freebsd-net@FreeBSD.org, lstewart@FreeBSD.org Cc: kmacy@FreeBSD.org Subject: Wrong cwnd calculation in cubic when blackhole detection is on Message-ID: <20150910001806.GB64965@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MW5yreqqjyrRcusr" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 00:18:13 -0000 --MW5yreqqjyrRcusr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline When blackhole detection is turned on with FreeBSD 10.2, I see really large (overflowed) values close to ulong max returning from cubic_cwnd() in netinet/cc/cc_cubic.h The culprit is this equation at the end of the function: cwnd = ((cwnd * CUBIC_C_FACTOR * smss) >> CUBIC_SHIFT_4) + wmax; wmax is the cwnd when we entered congestion. In case of blackhole detection on, it can go down to 524. And when that happens, the equation above returns -ve value. Now, right before returning from that function, we cast it to ulong: return ((unsigned long)cwnd); That gives a really large value. In one particular example, we enter the function with following values: ticks:140 wmax=524 smss=524 K=430 and return with cwnd = 18446744073709551378. I still need to read the cubic draft [1] and see how this is supposed to work but if someone has any ideas, please let me know. I've thought about setting cwnd to 0 when cwnd < 0 but that's not fair and it'll hurt connection as it won't recover fast enough. Cheers, Hiren [1] https://tools.ietf.org/html/draft-rhee-tcpm-cubic-02 --MW5yreqqjyrRcusr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJV8Mw6XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/luD0H/i8eUIcW5NkcXSCN3AZxqLqP l0Gs2DShH51F1JnTvRldUgCi41LcaZnDKtBE5cVjnM+ao9aoTYkZuIKNS9O+Ev+6 SVrqPdGNM815gN4yFZLC97dsOoEnrv2hGXzfVeqqm8rUEM47Pq/pZDhWsItm4F2r WkR9+pvsC2JNDLA8yFmwr4VQMVrwhLG/sq7VKXarlZPpTvRWNjU8i+4gZJlFoHxw +gj8U8e1QskD0eSDr5AoUSG0iOtpforUuUW0V4mpT46b45VltK7RJws8n0X0m1rr xWpnV/R+iux9OCvgZSk4wkjOgxe3MiswK4CGtyYhUmZw0sBS7APl7DWdnXkHya0= =bAGg -----END PGP SIGNATURE----- --MW5yreqqjyrRcusr-- From owner-freebsd-net@freebsd.org Thu Sep 10 07:45:10 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B0FCA006CE for ; Thu, 10 Sep 2015 07:45:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 579AF13C4 for ; Thu, 10 Sep 2015 07:45:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8A7jAeB060125 for ; Thu, 10 Sep 2015 07:45:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202907] 10.2 on SolarFlare SFN5162F 10Gb/s NIC missing out traffic Date: Thu, 10 Sep 2015 07:45:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: arybchik@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: arybchik@freebsd.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 07:45:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202907 Andrew Rybchenko changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |arybchik@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Thu Sep 10 10:29:33 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CA728A00B89 for ; Thu, 10 Sep 2015 10:29:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B62F818B6 for ; Thu, 10 Sep 2015 10:29:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8AATXxt033640 for ; Thu, 10 Sep 2015 10:29:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 201488] dummynet appears broken in 10.0-RELEASE and onwards (can't traffic shape on bridges) Date: Thu, 10 Sep 2015 10:29:32 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: fbsd@peralex.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: luigi@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 10:29:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201488 Mark C changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fbsd@peralex.com --- Comment #3 from Mark C --- I have the same problem (FreeBSD 10.2). I've tried Hiren Panchasara's suggestion in Comment 1, but that doesn't fix the problem. Note that traffic to and from either of the adapters that form part of the bridge DOES go via the pipe. It's just traffic that gets bridged that doesn't go through the pipe. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-net@freebsd.org Thu Sep 10 15:25:38 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F94BA0054C for ; Thu, 10 Sep 2015 15:25:38 +0000 (UTC) (envelope-from gondim@bsdinfo.com.br) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [191.243.120.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B19EC18AD for ; Thu, 10 Sep 2015 15:25:37 +0000 (UTC) (envelope-from gondim@bsdinfo.com.br) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id CBC1130FCCD for ; Thu, 10 Sep 2015 12:25:05 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-transfer-encoding:content-type:content-type:subject :subject:to:mime-version:user-agent:from:from:date:date :message-id; s=dkim; t=1441898704; x=1442762705; bh=UfnBOvDXjEsp RO8QOI4pFP82/UOo9/0Hgx4UpS7ghY4=; b=O9uWYIHRjKbR1lDbhr3+Wfjc4c6c GNWmOg2ZCCzIqZHDu2MF1GYj7AHXmgMdupQJQVzQ9yvjezWZxHQMHUfPEDf/RVYX k8cGYJ/dOS1VowOcM2BsAUsmC/V1D9mrQYe4hgKTh1kp8SO1rXUM0H/7CxL85jbj co4ZvoiJDmiPS7U= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9Mlq1qLKpBK for ; Thu, 10 Sep 2015 12:25:04 -0300 (BRT) Received: from [192.168.0.101] (unknown [191.243.120.190]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id B427B30FCAF for ; Thu, 10 Sep 2015 12:25:04 -0300 (BRT) Message-ID: <55F1A095.6010001@bsdinfo.com.br> Date: Thu, 10 Sep 2015 12:24:05 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: FreeBSD Net Subject: Possible LACP problem with FreeBSD 10.2-RELEASE and Juniper MX5 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 15:25:38 -0000 Hi All, We have a router configured with 2 LACP (lagg0 and lagg1): lagg0: flags=8843 metric 0 mtu 1500 options=403bb ether 00:1b:21:7b:ee:98 inet6 fe80::21b:21ff:fe7b:ee98%lagg0 prefixlen 64 scopeid 0x12 nd6 options=21 media: Ethernet autoselect status: active laggproto lacp lagghash l2,l3,l4 laggport: igb6 flags=1c laggport: igb7 flags=1c lagg1: flags=8843 metric 0 mtu 1500 options=403bb ether 00:1b:21:7b:ee:6c inet 189.xxx.xxx.34 netmask 0xfffffffc broadcast 189.113.78.35 inet6 fe80::21b:21ff:fe7b:ee6c%lagg1 prefixlen 64 scopeid 0xf inet6 2804:56c:0:8::2 prefixlen 64 nd6 options=21 media: Ethernet autoselect status: active laggproto lacp lagghash l2,l3,l4 laggport: igb4 flags=1c laggport: igb5 flags=1c When my Internet traffic is high at night, my BGP session in lagg1 is giving up and down 4 in 4 minutes. After upgraded to FreeBSD 2.10-RELEASE-p2, this problem started. Before we were using the FreeBSD 10.1-STABLE r281235 without any problem. The log have the following messages: /var/log/messages:Sep 9 19:21:43 rt01 kernel: igb5: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 19:21:44 rt01 kernel: igb4: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 19:27:01 rt01 kernel: igb5: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 19:27:01 rt01 kernel: igb4: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 19:29:13 rt01 kernel: igb5: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 19:29:14 rt01 kernel: igb4: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 19:46:10 rt01 kernel: igb5: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 19:46:11 rt01 kernel: igb4: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 20:01:02 rt01 kernel: igb4: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 20:01:03 rt01 kernel: igb5: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 20:02:08 rt01 kernel: igb5: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 20:02:09 rt01 kernel: igb4: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 20:03:54 rt01 kernel: igb5: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 20:03:57 rt01 kernel: igb4: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 20:07:05 rt01 kernel: igb5: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 20:07:06 rt01 kernel: igb4: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 20:20:49 rt01 kernel: igb5: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 20:20:50 rt01 kernel: igb4: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 20:25:39 rt01 kernel: igb4: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 20:25:40 rt01 kernel: igb5: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 20:28:55 rt01 kernel: igb5: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 20:28:56 rt01 kernel: igb4: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 20:31:39 rt01 kernel: igb5: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 20:31:39 rt01 kernel: igb4: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 20:33:29 rt01 kernel: igb4: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 20:33:30 rt01 kernel: igb5: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 21:03:38 rt01 kernel: igb5: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 21:03:38 rt01 kernel: igb4: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 21:09:39 rt01 kernel: igb5: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 21:09:39 rt01 kernel: igb4: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 21:20:51 rt01 kernel: igb5: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 21:20:52 rt01 kernel: igb4: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 21:25:24 rt01 kernel: igb5: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 21:25:25 rt01 kernel: igb4: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 21:36:22 rt01 kernel: igb5: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 21:36:23 rt01 kernel: igb4: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 21:39:26 rt01 kernel: igb5: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 21:39:27 rt01 kernel: igb4: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 21:47:40 rt01 kernel: igb5: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 21:47:40 rt01 kernel: igb4: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 21:52:19 rt01 kernel: igb5: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 21:52:19 rt01 kernel: igb4: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 21:53:01 rt01 kernel: igb5: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 21:53:01 rt01 kernel: igb4: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 21:58:53 rt01 kernel: igb5: Interface stopped DISTRIBUTING, possible flapping /var/log/messages:Sep 9 21:58:53 rt01 kernel: igb4: Interface stopped DISTRIBUTING, possible flapping Has there been any change in the LACP, during this period, which could be causing this problem? I'm doing a downgrade in our system to see if this problem happen tonight. Thanks and best regards, From owner-freebsd-net@freebsd.org Thu Sep 10 15:33:14 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7CBB0A00A7D for ; Thu, 10 Sep 2015 15:33:14 +0000 (UTC) (envelope-from sreenathbh@rocketmail.com) Received: from nm15-vm3.bullet.mail.ne1.yahoo.com (nm15-vm3.bullet.mail.ne1.yahoo.com [98.138.91.145]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 40CD91D9F for ; Thu, 10 Sep 2015 15:33:13 +0000 (UTC) (envelope-from sreenathbh@rocketmail.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rocketmail.com; s=s2048; t=1441901147; bh=+XNihR9hQQ3Nk4pM+H0bdWgBw6jNqwtR/3tpf4kb+bI=; h=Date:From:Subject:To:From:Subject; b=RVZg/q8iCsRYOFzp+CkNlwPgLv+zItfP+kamybPl5+PClrOZOadmjsl7IyEHXS/Dz1RXWlmJfXcOg1rI44Me0lkeP8yba8h/ErfLoptXMS/grc3N6x6M2GsZqZOo2GaCKWpDSgMuDv0xJ+aHxBV10dEVh7QqYJ01R1C1wimv0Xr7eMH79a4lSFW/N00l9K6OtShhn8LQ7M40tHD5/Yw2BFpbom06+eteWzFNoMS7MIZQ9A7gINiQblVULuXuEX126wsZcGW9XBCov4u1Odi6kpz97UfZGTwPrNvEdUUHuDRSiFncNfpDX9xOzSXcelfwfkB41UYftuqRBD1vKHBbYA== Received: from [98.138.226.179] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 10 Sep 2015 16:05:47 -0000 Received: from [98.138.226.163] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 10 Sep 2015 15:33:06 -0000 Received: from [127.0.0.1] by omp1064.mail.ne1.yahoo.com with NNFMP; 10 Sep 2015 15:33:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 854852.98465.bm@omp1064.mail.ne1.yahoo.com Received: (qmail 99338 invoked by uid 60001); 10 Sep 2015 15:33:06 -0000 X-YMail-OSG: avPfeEIVM1nASP8iZ5n6Rcf.c_fvrAC116qdmhNjlbqrzA3 .KaGywZi6oOZV4yF4YpL58RGqhmFm68mRSgTafoAjTY7KIjukG3U3hG6Z6OL fhJ8NiOp82US0ym6xSePdZuoyRUjLqxQ61mN4157FiCVv2kdDsQDrinQyC1W VkmyRI2.3qxK7ctay59SSf1IqEgomjrnPSNjmCLpkWf.Fs8p2IHWod4pnsyK RT0_.YyiGkI8T81ioCQLFoq0c2KCAIkihSvaw.6jyIJiTTF7SsHyj0EoAGx7 V_H6wJUI5S_KONJdF.VLD7dWiUfLxJP5Fudv4H2ki4siZhsCzqYawsY564tw C_I.KsUEIUi1v_2rW.QzEpc2HS_G6ozzBm66bplpHxy0JyOnuw5Pb0bCURl_ hov9d5Sy8RaQVhwdh5GevlbnJ8X_Q0qs1vGPOZAZQBKGv00ly4.DtWi.LHta 49D9XFaO6wbpkjMKS8avsaaSu63PeHfWhiLxeX5IdL9xuwRHJrSRgJPJb9Li 2lbdTmyhOAIi3EjzPgWRX8h3dcJfItxrlWA1a37Qr_VPzig_aUeu7Id9Tjy7 7pL6wFJw- Received: from [61.1.245.58] by web122104.mail.ne1.yahoo.com via HTTP; Thu, 10 Sep 2015 08:33:06 PDT X-Rocket-MIMEInfo: 002.001, SGkgDQoNCkkgZ290ICBhIG5ldyBsYXB0b3AgKEFjZXIgRTUtNTczKSB0aGF0IGhhcyBhIFJlYWx0ZWsgMUdicHMgYWRhcHRlci4NCmlmY29uZmlnIGFmdGVyIGJvb3RpbmcgZG9lcyBub3QgbGlzdCByZTAgaW50ZXJmYWNlLg0KDQpIZXJlIGFyZSByZWxldmFudCBsaW5lcyBmcm9tIGRtZXNnOg0KDQpyZTA6IDxSZWFsVGVrIDgxNjgvODExMSBCL0MvQ1AvRC9EUC9FL0YvRyBQQ0llIEdpZ2FiaXQgRXRoZXJuZXQ.IHBvcnQgMHgzMDAwLTB4Mw0KMGZmIG1lbSAweGIwNjA0MDAwLTB4YjA2MDRmZmYsMHhiMDYwMDABMAEBAQE- X-Mailer: YahooMailBasic/654 YahooMailWebService/0.8.203.813 Message-ID: <1441899186.70362.YahooMailBasic@web122104.mail.ne1.yahoo.com> Date: Thu, 10 Sep 2015 08:33:06 -0700 From: Sreenath Battalahalli Subject: realtek interface not working To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 15:33:14 -0000 Hi I got a new laptop (Acer E5-573) that has a Realtek 1Gbps adapter. ifconfig after booting does not list re0 interface. Here are relevant lines from dmesg: re0: port 0x3000-0x3 0ff mem 0xb0604000-0xb0604fff,0xb0600000-0xb0603fff irq 18 at device 0.0 on pci2 re0: Using 1 MSI-X message re0: turning off MSI enable bit. re0: ASPM disabled re0: Chip rev. 0x54000000 re0: MAC rev. 0x00100000 re0: Unknown H/W revision: 0x54000000 device_attach: re0 attach returned 6 Looks like this hardware is not supported by the driver. Freebsd version is 10.2 amd64 any help if getting this to work appreciated. thanks, Sreenath From owner-freebsd-net@freebsd.org Thu Sep 10 16:46:04 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2D2CCA01D00 for ; Thu, 10 Sep 2015 16:46:04 +0000 (UTC) (envelope-from trtrmitya@gmail.com) Received: from mail-la0-x241.google.com (mail-la0-x241.google.com [IPv6:2a00:1450:4010:c03::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA1C81C25 for ; Thu, 10 Sep 2015 16:46:03 +0000 (UTC) (envelope-from trtrmitya@gmail.com) Received: by labmm4 with SMTP id mm4so2936061lab.3 for ; Thu, 10 Sep 2015 09:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=wOzCsNHj3iQHRN26Rnt5D6wlkVfaptr1KtcdXpwNONg=; b=ELnzNeFR9kNlYyccoB9WbY4HMfZEBqCSuptlNsfMehkOfzvu3a/G4Jdf8vB3gHUasp oEHWadqjyXR7I+RKPh19T2f9F5Df1pFSIG/0jYCwg7Bv0C0Ko0lMgwaBY8jXp0Fcq4uu 9IWwZhZDlt2EDFCzctSC1/X4yF6qdh5zQ/cItKASV5Xhl9J1weqk/74FfAucGA1xGgna h+xPB1iUb4QTLg/TsVTE4L+VhCqUTheN+nz5T0aJ9jnolhVleuPaguUQtU/m2KYX31ts IJAyL2HUhIoqloMITDa+GmzOPIv8UYWfl3k8O9nsDVyvfiadZ79+1mpTxj8LczaS4J5z ZYUw== X-Received: by 10.112.136.170 with SMTP id qb10mr37517704lbb.34.1441903561777; Thu, 10 Sep 2015 09:46:01 -0700 (PDT) Received: from ?IPv6:2a02:6b8::408:759a:1d37:18cd:1cf1? ([2a02:6b8:0:408:759a:1d37:18cd:1cf1]) by smtp.gmail.com with ESMTPSA id ok2sm2809761lbb.0.2015.09.10.09.46.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Sep 2015 09:46:00 -0700 (PDT) From: Dmitry Sivachenko Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: netisr process eats 100% cpu Message-Id: Date: Thu, 10 Sep 2015 19:45:59 +0300 To: FreeBSD Net Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 16:46:04 -0000 Hello! I am using fresh FreeBSD-10/stable. I have a program which establish a TCP connection to server and sends a = lot of small requests over it. I put haproxy load balancer working in TCP mode in the middle, which = listens some port on localhost. Under the relatively low network load (20MB/sec, ~100 kpps), netisr = process starts to consume close to 100% CPU, and does not allow to = utilize more network bandwidth: 11 root -72 - 0K 944K CPU27 27 0:34 98.06% = intr{swi1: netisr 0} If I do not pass traffic through haproxy but connect directly to remote = server, netisr process consumes 0% CPU and everything works well. Is it rather expected or this can be fixed? Thanks in advance.= From owner-freebsd-net@freebsd.org Thu Sep 10 19:12:51 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15EA3A00A33 for ; Thu, 10 Sep 2015 19:12:51 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 869ED115C for ; Thu, 10 Sep 2015 19:12:50 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id t8AJCeZ9098858 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 10 Sep 2015 21:12:41 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id t8AJCekP098857; Thu, 10 Sep 2015 21:12:40 +0200 (CEST) (envelope-from marius) Date: Thu, 10 Sep 2015 21:12:40 +0200 From: Marius Strobl To: Sreenath Battalahalli Cc: freebsd-net@freebsd.org Subject: Re: realtek interface not working Message-ID: <20150910191240.GA97360@alchemy.franken.de> References: <1441899186.70362.YahooMailBasic@web122104.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="RnlQjJ0d97Da+TV1" Content-Disposition: inline In-Reply-To: <1441899186.70362.YahooMailBasic@web122104.mail.ne1.yahoo.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Thu, 10 Sep 2015 21:12:41 +0200 (CEST) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 19:12:51 -0000 --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Sep 10, 2015 at 08:33:06AM -0700, Sreenath Battalahalli wrote: > Hi > > I got a new laptop (Acer E5-573) that has a Realtek 1Gbps adapter. > ifconfig after booting does not list re0 interface. > > Here are relevant lines from dmesg: > > re0: port 0x3000-0x3 > 0ff mem 0xb0604000-0xb0604fff,0xb0600000-0xb0603fff irq 18 at device 0.0 on pci2 > re0: Using 1 MSI-X message > re0: turning off MSI enable bit. > re0: ASPM disabled > re0: Chip rev. 0x54000000 > re0: MAC rev. 0x00100000 > re0: Unknown H/W revision: 0x54000000 > device_attach: re0 attach returned 6 > > Looks like this hardware is not supported by the driver. > > Freebsd version is 10.2 amd64 > > any help if getting this to work appreciated. > Please give the attached patch a try. Marius --RnlQjJ0d97Da+TV1 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="re_8168h.diff" Index: re/if_re.c =================================================================== --- re/if_re.c (revision 287625) +++ re/if_re.c (working copy) @@ -238,6 +238,7 @@ static const struct rl_hwrev re_hwrevs[] = { { RL_HWREV_8168F, RL_8169, "8168F/8111F", RL_JUMBO_MTU_9K}, { RL_HWREV_8168G, RL_8169, "8168G/8111G", RL_JUMBO_MTU_9K}, { RL_HWREV_8168GU, RL_8169, "8168GU/8111GU", RL_JUMBO_MTU_9K}, + { RL_HWREV_8168H, RL_8169, "8168H/8111H", RL_JUMBO_MTU_9K}, { RL_HWREV_8411, RL_8169, "8411", RL_JUMBO_MTU_9K}, { RL_HWREV_8411B, RL_8169, "8411B", RL_JUMBO_MTU_9K}, { 0, 0, NULL, 0 } @@ -1485,6 +1486,7 @@ re_attach(device_t dev) break; case RL_HWREV_8168EP: case RL_HWREV_8168G: + case RL_HWREV_8168H: case RL_HWREV_8411B: sc->rl_flags |= RL_FLAG_PHYWAKE | RL_FLAG_PAR | RL_FLAG_DESCV2 | RL_FLAG_MACSTAT | RL_FLAG_CMDSTOP | Index: rl/if_rlreg.h =================================================================== --- rl/if_rlreg.h (revision 287625) +++ rl/if_rlreg.h (working copy) @@ -195,6 +195,7 @@ #define RL_HWREV_8168G 0x4C000000 #define RL_HWREV_8168EP 0x50000000 #define RL_HWREV_8168GU 0x50800000 +#define RL_HWREV_8168H 0x54000000 #define RL_HWREV_8411B 0x5C800000 #define RL_HWREV_8139 0x60000000 #define RL_HWREV_8139A 0x70000000 --RnlQjJ0d97Da+TV1-- From owner-freebsd-net@freebsd.org Thu Sep 10 20:27:41 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0BEEA00029 for ; Thu, 10 Sep 2015 20:27:41 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.strugglingcoder.info", Issuer "mail.strugglingcoder.info" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F18C1554 for ; Thu, 10 Sep 2015 20:27:40 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 3A636C0624; Thu, 10 Sep 2015 13:27:40 -0700 (PDT) Date: Thu, 10 Sep 2015 13:27:40 -0700 From: hiren panchasara To: Dmitry Sivachenko Cc: FreeBSD Net Subject: Re: netisr process eats 100% cpu Message-ID: <20150910202740.GG64965@strugglingcoder.info> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WkfBGePaEyrk4zXB" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 20:27:41 -0000 --WkfBGePaEyrk4zXB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 09/10/15 at 07:45P, Dmitry Sivachenko wrote: > Hello! >=20 > I am using fresh FreeBSD-10/stable. >=20 > I have a program which establish a TCP connection to server and sends a l= ot of small requests over it. > I put haproxy load balancer working in TCP mode in the middle, which list= ens some port on localhost. >=20 > Under the relatively low network load (20MB/sec, ~100 kpps), netisr proce= ss starts to consume close to 100% CPU, and does not allow to utilize more = network bandwidth: >=20 > 11 root -72 - 0K 944K CPU27 27 0:34 98.06% intr{s= wi1: netisr 0} >=20 > If I do not pass traffic through haproxy but connect directly to remote s= erver, netisr process consumes 0% CPU and everything works well. >=20 > Is it rather expected or this can be fixed? Unsure at the moment if loopback is causing the trouble for you or not. See: https://lists.freebsd.org/pipermail/freebsd-net/2015-February/041239.html You may want to try: 1) pmcstat and see if you can catch something 2) disable checksum on localhost 3) look at netisr settings. sysctl net.isr o/p and how it looks under netstat -Q. I am not sure if adding more threads to netisr via net.isr.numthreads would help. (Note its a loader.conf variable) As I said, I am not sure whats up. Just throwing some ideas here. Cheers, Hiren --WkfBGePaEyrk4zXB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJV8ee5XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lj88H/24ZLjb/FFF0r82I2usBwP8y MK8bs+DpLuucki5EErKGSbBv38L9VpgYRXZEUUl99f1DudAbI0IqkHzmLeFjSG7Q VaseM/OZkbTnQlMSYnGstboQFtbFtJVh3A9jVVz3/StqvgTNe/P4y5ig/R1rkbgK hBtNKg46d//q+g+NHrbyMcvlvci3+D72oJaMYUlwUBKwhUs4yirHBEk4qulitGiB OmkNAo64VEKTYXY8mUqHO7l8SrHmm3wy7m0IU4MC1mZtKK8dhPph447CtLVu3km1 Og8Ze0uRlzhAt/9oXf+SeWwYioEmJwHrU4oGkn4cpLSh8FABI0o330W/woHVlKE= =+R5U -----END PGP SIGNATURE----- --WkfBGePaEyrk4zXB-- From owner-freebsd-net@freebsd.org Thu Sep 10 22:14:39 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E5761A02F79 for ; Thu, 10 Sep 2015 22:14:39 +0000 (UTC) (envelope-from gondim@bsdinfo.com.br) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [191.243.120.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7492C10D8 for ; Thu, 10 Sep 2015 22:14:39 +0000 (UTC) (envelope-from gondim@bsdinfo.com.br) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id 2F22A30FCD7 for ; Thu, 10 Sep 2015 19:13:42 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-transfer-encoding:content-type:content-type :in-reply-to:references:subject:subject:to:mime-version :user-agent:from:from:date:date:message-id; s=dkim; t= 1441923221; x=1442787222; bh=PAVzliWXGHQLN/baT8kVfGIbVZ3/ak3m6bG oAali1vM=; b=EYZYRNvmNrFpTzqQ95wEIFATAeMUEIe2+rEWMBIRgIE7aiGFku/ B+MW2o4MNfwmj5tEpzOK9umKUa5cYx/VucrY6rw9ulAr64odJZ79ma6JaHXLYpEJ FoDJoHmQb3smUqKHki6k1htBjR256QDXbPVnj92GFQQIZdWnPF7Johf8= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zs8kze_u7WOG for ; Thu, 10 Sep 2015 19:13:41 -0300 (BRT) Received: from [192.168.10.208] (unknown [186.193.54.69]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id 5171230FCAF for ; Thu, 10 Sep 2015 19:13:41 -0300 (BRT) Message-ID: <55F2005A.1020904@bsdinfo.com.br> Date: Thu, 10 Sep 2015 19:12:42 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: FreeBSD Net Subject: Re: Possible LACP problem with FreeBSD 10.2-RELEASE and Juniper MX5 References: <55F1A095.6010001@bsdinfo.com.br> In-Reply-To: <55F1A095.6010001@bsdinfo.com.br> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 22:14:40 -0000 On 10-09-2015 12:24, Marcelo Gondim wrote: > Hi All, > > We have a router configured with 2 LACP (lagg0 and lagg1): > > lagg0: flags=8843 metric 0 mtu > 1500 > options=403bb > > ether 00:1b:21:7b:ee:98 > inet6 fe80::21b:21ff:fe7b:ee98%lagg0 prefixlen 64 scopeid 0x12 > nd6 options=21 > media: Ethernet autoselect > status: active > laggproto lacp lagghash l2,l3,l4 > laggport: igb6 flags=1c > laggport: igb7 flags=1c > > lagg1: flags=8843 metric 0 mtu > 1500 > options=403bb > > ether 00:1b:21:7b:ee:6c > inet 189.xxx.xxx.34 netmask 0xfffffffc broadcast 189.113.78.35 > inet6 fe80::21b:21ff:fe7b:ee6c%lagg1 prefixlen 64 scopeid 0xf > inet6 2804:56c:0:8::2 prefixlen 64 > nd6 options=21 > media: Ethernet autoselect > status: active > laggproto lacp lagghash l2,l3,l4 > laggport: igb4 flags=1c > laggport: igb5 flags=1c > > When my Internet traffic is high at night, my BGP session in lagg1 is > giving up and down 4 in 4 minutes. > After upgraded to FreeBSD 2.10-RELEASE-p2, this problem started. > Before we were using the FreeBSD 10.1-STABLE r281235 without any problem. > > The log have the following messages: > > /var/log/messages:Sep 9 19:21:43 rt01 kernel: igb5: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 19:21:44 rt01 kernel: igb4: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 19:27:01 rt01 kernel: igb5: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 19:27:01 rt01 kernel: igb4: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 19:29:13 rt01 kernel: igb5: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 19:29:14 rt01 kernel: igb4: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 19:46:10 rt01 kernel: igb5: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 19:46:11 rt01 kernel: igb4: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 20:01:02 rt01 kernel: igb4: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 20:01:03 rt01 kernel: igb5: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 20:02:08 rt01 kernel: igb5: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 20:02:09 rt01 kernel: igb4: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 20:03:54 rt01 kernel: igb5: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 20:03:57 rt01 kernel: igb4: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 20:07:05 rt01 kernel: igb5: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 20:07:06 rt01 kernel: igb4: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 20:20:49 rt01 kernel: igb5: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 20:20:50 rt01 kernel: igb4: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 20:25:39 rt01 kernel: igb4: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 20:25:40 rt01 kernel: igb5: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 20:28:55 rt01 kernel: igb5: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 20:28:56 rt01 kernel: igb4: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 20:31:39 rt01 kernel: igb5: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 20:31:39 rt01 kernel: igb4: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 20:33:29 rt01 kernel: igb4: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 20:33:30 rt01 kernel: igb5: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 21:03:38 rt01 kernel: igb5: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 21:03:38 rt01 kernel: igb4: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 21:09:39 rt01 kernel: igb5: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 21:09:39 rt01 kernel: igb4: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 21:20:51 rt01 kernel: igb5: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 21:20:52 rt01 kernel: igb4: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 21:25:24 rt01 kernel: igb5: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 21:25:25 rt01 kernel: igb4: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 21:36:22 rt01 kernel: igb5: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 21:36:23 rt01 kernel: igb4: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 21:39:26 rt01 kernel: igb5: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 21:39:27 rt01 kernel: igb4: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 21:47:40 rt01 kernel: igb5: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 21:47:40 rt01 kernel: igb4: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 21:52:19 rt01 kernel: igb5: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 21:52:19 rt01 kernel: igb4: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 21:53:01 rt01 kernel: igb5: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 21:53:01 rt01 kernel: igb4: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 21:58:53 rt01 kernel: igb5: Interface stopped > DISTRIBUTING, possible flapping > /var/log/messages:Sep 9 21:58:53 rt01 kernel: igb4: Interface stopped > DISTRIBUTING, possible flapping > > Has there been any change in the LACP, during this period, which could > be causing this problem? > I'm doing a downgrade in our system to see if this problem happen > tonight. Confirmed. I did downgrade the system to 10.1-STABLE r281235 and the problem stopped happening. Some change occurred between 10.1-STABLE r281235 and 10.2-RELEASE-p2 causing this problem in the system. From owner-freebsd-net@freebsd.org Fri Sep 11 00:42:09 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1282A01FAE for ; Fri, 11 Sep 2015 00:42:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8D94E18B4 for ; Fri, 11 Sep 2015 00:42:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8B0g9Yo006699 for ; Fri, 11 Sep 2015 00:42:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 203031] LACP problem with FreeBSD 10.2-RELEASE Date: Fri, 11 Sep 2015 00:42:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 00:42:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203031 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Fri Sep 11 00:42:27 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 581DFA02002 for ; Fri, 11 Sep 2015 00:42:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 43D83198E for ; Fri, 11 Sep 2015 00:42:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8B0gRKo007036 for ; Fri, 11 Sep 2015 00:42:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 203022] [patch] Can't destroy vlan dev with vtnet parent that is down and doing vlanhwfilter Date: Fri, 11 Sep 2015 00:42:27 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 00:42:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203022 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Fri Sep 11 09:12:47 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B463CA0044C for ; Fri, 11 Sep 2015 09:12:47 +0000 (UTC) (envelope-from trtrmitya@gmail.com) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B6CF1E7C for ; Fri, 11 Sep 2015 09:12:47 +0000 (UTC) (envelope-from trtrmitya@gmail.com) Received: by lamp12 with SMTP id p12so43296383lam.0 for ; Fri, 11 Sep 2015 02:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=lTjhLWKTlPpHgVs0ZZ1XrfloNADI+bOBmcxJ5n++2/w=; b=XElMI8WDqMLCIZuMJ0o0WGUsgUlm4IP23KsvhoLNdYKlJ65LcPtnQwDHmQWqrYfut9 4H/sgHlegliMnt3hVrk5AFm2OYztUWhQlHNmSqPGOENelvYnr8jgA8SrzTOfryO4/Lk7 KOJHoFTeIa07z1raxhnguJrX1bziylV0mNafoISxX9pO+5jBj5nTGydCGJIYAiOH17lm GjMQrttRbhf9G2gtYuh0O2efKCPGEsJQZGe4puccYhZ5xMD4Cw8DAKn612ULaWYtKw8a J+GTIJLjf+JZN4jsSDalqL+GZ5BWz1yV4fha2vjDw83nFLAx7Dzx2KW5ZPeORPcKLlpe 1Jng== X-Received: by 10.112.13.40 with SMTP id e8mr21304569lbc.82.1441962765130; Fri, 11 Sep 2015 02:12:45 -0700 (PDT) Received: from ?IPv6:2a02:6b8::408:6468:ef0e:8c24:602b? ([2a02:6b8:0:408:6468:ef0e:8c24:602b]) by smtp.gmail.com with ESMTPSA id w3sm99886lag.13.2015.09.11.02.12.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Sep 2015 02:12:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: netisr process eats 100% cpu From: Dmitry Sivachenko In-Reply-To: Date: Fri, 11 Sep 2015 12:12:41 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: FreeBSD Net X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 09:12:47 -0000 > On 10 =D1=81=D0=B5=D0=BD=D1=82. 2015 =D0=B3., at 19:45, Dmitry = Sivachenko wrote: >=20 > Hello! >=20 > I am using fresh FreeBSD-10/stable. >=20 > I have a program which establish a TCP connection to server and sends = a lot of small requests over it. > I put haproxy load balancer working in TCP mode in the middle, which = listens some port on localhost. >=20 > Under the relatively low network load (20MB/sec, ~100 kpps), netisr = process starts to consume close to 100% CPU, and does not allow to = utilize more network bandwidth: >=20 > 11 root -72 - 0K 944K CPU27 27 0:34 98.06% = intr{swi1: netisr 0} >=20 > If I do not pass traffic through haproxy but connect directly to = remote server, netisr process consumes 0% CPU and everything works well. >=20 > Is it rather expected or this can be fixed? >=20 > Thanks in advance. Also I want to add that netisr process consume CPU only when TCP client = and haproxy are running on the same host. If I move haproxy to a = separate machine, netisr process does show in top(1) output at all. So this looks weird at least.= From owner-freebsd-net@freebsd.org Fri Sep 11 09:46:30 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A72EDA0166F for ; Fri, 11 Sep 2015 09:46:30 +0000 (UTC) (envelope-from trtrmitya@gmail.com) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E51D102A for ; Fri, 11 Sep 2015 09:46:30 +0000 (UTC) (envelope-from trtrmitya@gmail.com) Received: by lbcjc2 with SMTP id jc2so36719365lbc.0 for ; Fri, 11 Sep 2015 02:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=I8LK/wOa9uM0e/1TwA3EC3ei96GuMOqwAl9ryoxxAyU=; b=P2naPShfREErYXwWTSgdm1Vt+wMMOe3ebaluQIc04A1K0OfPOH3TjXjqVOfdk2ioCE VnqKoPLaxyYDwD5dx/+bkQvR8IDKwzjxjJC5gNP5lZOEUbcydAH71P1Qi9rjJtLJbMkX A4S+VFw4fOwI0RysmjuetslKnRREug2kRLVXkKwSis5VoeJ/drUhteY7bzS1oekYAJ1t UaFblj5HhO6w5iztdARlSIYC2sU8Gq5pNgnBqt4h1By2vCrZcfsz9sDotkyo6GxeTwhi DwVcNHQwzNuuTNjzhNP2tATx4QHgw+Evq19fs/EotWam9Oj5rbiVnQsHvFj9pvNfRWaY ehOQ== X-Received: by 10.152.29.167 with SMTP id l7mr40839883lah.57.1441964788118; Fri, 11 Sep 2015 02:46:28 -0700 (PDT) Received: from ?IPv6:2a02:6b8::408:6468:ef0e:8c24:602b? ([2a02:6b8:0:408:6468:ef0e:8c24:602b]) by smtp.gmail.com with ESMTPSA id po6sm113180lbc.33.2015.09.11.02.46.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Sep 2015 02:46:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: netisr process eats 100% cpu From: Dmitry Sivachenko In-Reply-To: Date: Fri, 11 Sep 2015 12:46:25 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: FreeBSD Net , hiren@strugglingcoder.info X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 09:46:30 -0000 > hiren panchasara wrote: >=20 > Unsure at the moment if loopback is causing the trouble for you or = not. > See: (please keep me CC'ed, I am not subscribed to -net) > > = https://lists.freebsd.org/pipermail/freebsd-net/2015-February/041239.html > > Yes, this thread looks similar. > You may want to try: > 1) pmcstat and see if you can catch something What particular should I look for? Here is first lines of pmcstat -T -S = instructions -w 1: PMC: [INSTR_RETIRED_ANY] Samples: 157198 (100.0%) , 0 unresolved %SAMP IMAGE FUNCTION CALLERS 13.2 kernel cpu_search_highest cpu_search_highest:12.0 = sched_idletd:1.2 8.3 kernel ipfw_chk ipfw_check_packet 3.1 myprogram memsetAVX _ZN12TLz4Compress7DoWriteEPKv 2.3 kernel tcp_output tcp_usr_send:1.0 = tcp_do_segment:0.9 > 2) disable checksum on localhost I tried, but nothing has changed. > 3) look at netisr settings. sysctl net.isr o/p and how it looks under > netstat -Q. I am not sure if adding more threads to netisr via What should I look for? > net.isr.numthreads would help. (Note its a loader.conf variable) This netisr load looks parasitical to me (as I noted, moving haproxy to = a separate machine does not burn CPU cycles on netisr, why is localhost = special?) Even if adding more threads to netisr would boost network utilization, = wouldn't those CPU cycles spent for netisr just be a waste of energy? I = have other tasks for these CPU. > > As I said, I am not sure whats up. Just throwing some ideas here. Thanks!= From owner-freebsd-net@freebsd.org Fri Sep 11 17:19:16 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3BE5A0255C for ; Fri, 11 Sep 2015 17:19:16 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.strugglingcoder.info", Issuer "mail.strugglingcoder.info" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C1F051352 for ; Fri, 11 Sep 2015 17:19:16 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 171A3C09DA; Fri, 11 Sep 2015 10:19:10 -0700 (PDT) Date: Fri, 11 Sep 2015 10:19:10 -0700 From: hiren panchasara To: Dmitry Sivachenko Cc: FreeBSD Net Subject: Re: netisr process eats 100% cpu Message-ID: <20150911171910.GN64965@strugglingcoder.info> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IpgPcFyQO6wM49Um" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 17:19:17 -0000 --IpgPcFyQO6wM49Um Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 09/11/15 at 12:46P, Dmitry Sivachenko wrote: >=20 > > hiren panchasara wrote: > >=20 > > Unsure at the moment if loopback is causing the trouble for you or not. > > See: >=20 > (please keep me CC'ed, I am not subscribed to -net) >=20 >=20 > > > > https://lists.freebsd.org/pipermail/freebsd-net/2015-February/041239.ht= ml > > > > >=20 > Yes, this thread looks similar. >=20 >=20 > > You may want to try: > > 1) pmcstat and see if you can catch something >=20 > What particular should I look for? Here is first lines of pmcstat -T -S = instructions -w 1: > PMC: [INSTR_RETIRED_ANY] Samples: 157198 (100.0%) , 0 unresolved >=20 > %SAMP IMAGE FUNCTION CALLERS > 13.2 kernel cpu_search_highest cpu_search_highest:12.0 sched_idlet= d:1.2 > 8.3 kernel ipfw_chk ipfw_check_packet > 3.1 myprogram memsetAVX _ZN12TLz4Compress7DoWriteEPKv > 2.3 kernel tcp_output tcp_usr_send:1.0 tcp_do_segment:0.9 >=20 >=20 > > 2) disable checksum on localhost >=20 >=20 > I tried, but nothing has changed. >=20 >=20 > > 3) look at netisr settings. sysctl net.isr o/p and how it looks under > > netstat -Q. I am not sure if adding more threads to netisr via >=20 >=20 > What should I look for? >=20 >=20 > > net.isr.numthreads would help. (Note its a loader.conf variable) >=20 >=20 > This netisr load looks parasitical to me (as I noted, moving haproxy to a= separate machine does not burn CPU cycles on netisr, why is localhost spec= ial?) >=20 > Even if adding more threads to netisr would boost network utilization, wo= uldn't those CPU cycles spent for netisr just be a waste of energy? I have= other tasks for these CPU. > I am not sure what keep cpu busy with netisr when localhost is involved. You may want to post o/p of=20 # sysctl net.isr # netstat -Q # sysctl net.inet | grep queue A suggestion I see at https://calomel.org/freebsd_network_tuning.html is to increase localhost n/w buffers. Not sure if this'll help your case. net.local.stream.sendspace=3D164240 # (default 8192) net.local.stream.recvspace=3D164240 # (default 8192) Now I'll let someone else with more ideas/clues comment. Cheers, Hiren --IpgPcFyQO6wM49Um Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJV8w0KXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/l0m8H/0xmKSS0SNp9uxn9I2k39uNG 7Mx+w2S4FlAvzOuVEhK8kteWSWTdaIhLIAYj45edU4tJNB0oBGmkvY7rRWqmwydf +2QaedAw1eph6N3NkcsVEgcx6muSXcSGYG5DgX7Tfrz2UKuf3qiXrJfSw6JHmqTO tTycvuAjNrEc4OLnm7R8OWsk+hwIHkwc/+K7AEUMCr+pnJ5DBt+yMIhIEDoLmqWV 8S+AMHe7zYJKHno45csqXwZuSNSSCcv3YhXmPFqcgtDzNIQt1Xo5Q1UPxF0XSGEa ypQG1H9m1QtaT6/lfefYWDk75zBK6dbM9yBx6QauN1ij6dAx21obJzm8kwgneVM= =3bgx -----END PGP SIGNATURE----- --IpgPcFyQO6wM49Um-- From owner-freebsd-net@freebsd.org Sat Sep 12 06:04:15 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 21010A02729 for ; Sat, 12 Sep 2015 06:04:15 +0000 (UTC) (envelope-from sreenathbh@rocketmail.com) Received: from nm42.bullet.mail.ne1.yahoo.com (nm42.bullet.mail.ne1.yahoo.com [98.138.120.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DF088198B for ; Sat, 12 Sep 2015 06:04:14 +0000 (UTC) (envelope-from sreenathbh@rocketmail.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rocketmail.com; s=s2048; t=1442037637; bh=LAY4uNMfwcGO5mWMA0nqs1H1cvhO46et7J1ZE1kZgtg=; h=Date:From:Subject:To:Cc:In-Reply-To:From:Subject; b=egfEIpD2o88cFcxlcDf1MLaENBPA4DLyoKGelbMypVUkgNaIWWWf2rfRQ41epEZoek/KWSm+yb+YLciMUAyNs8byisXRVX64G44AnCq+bSRfzGVpkK1sT9mUnA1pNljCdaxiEvZI89/wYCuJlj2x6Q3pNZPqIbMems3aBQ0z8TqXPXU6pbwGipqeQzMmV768WtpC58i67G1mjOiXFGb4dWWFJOwT56ifcKzGCfsUWDY33bGn3SlUK1OMEveMvR5dwFUJjIckZBnBxbfY2WYyDQ0K1uKuSv0vUF0gqA+OmVqiH2zvZgWOODVOFXk2ZTt/Wv6QG+uJ6sKKoZFGhYE4ow== Received: from [127.0.0.1] by nm42.bullet.mail.ne1.yahoo.com with NNFMP; 12 Sep 2015 06:00:37 -0000 Received: from [98.138.100.115] by nm42.bullet.mail.ne1.yahoo.com with NNFMP; 12 Sep 2015 05:57:37 -0000 Received: from [98.138.87.7] by tm106.bullet.mail.ne1.yahoo.com with NNFMP; 12 Sep 2015 05:57:36 -0000 Received: from [127.0.0.1] by omp1007.mail.ne1.yahoo.com with NNFMP; 12 Sep 2015 05:57:36 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 914788.55546.bm@omp1007.mail.ne1.yahoo.com Received: (qmail 45458 invoked by uid 60001); 12 Sep 2015 05:57:36 -0000 X-YMail-OSG: JyxxvYwVM1mn3FwCbR._IHm_HJDDcnVbf0TkvhQ9MHPZ4mk P7hGma0V.vEUDxipmzgJo9qYvu0uqlwE4y25_D6XXeBcUT9bg7i6tphbgv49 lKW7_S_X2MwXCnqmnSbstBDmIMgqndS.MUknFa8zKsgcGrC7iWgLKOKOy_t8 dWtlbVJvtqCvJIcedxsBndACNPhVm8oyE5yslr22YRjwQekg.KnY7Es1cr_G A1nIH6bBj2Zg3TEFvsG7Aj3vq_ZEIdQ7WOnMLZ9ZHBBfYgrXBi.aEbrSa5SQ zgMuFtdnHKVuYEzS8w.Pzxz1ueD9pwf2GCptj17mvSoaDKm0xnrNBR7CKCgq tOflASI5eepKB7Fg3LZALNfKNd9UChefFk5r.OS1Yan3V374ctTL7IDNoCh2 WkXWd.JzbgCccDDGfBzDE8hUuorad6BOzo.LvPeyQXgFkCoG5j.LueWltoT4 Age7dLWg6iLRA.m1dNXGho4B_6vTm9e0wHiOmgDvCi2i2xAgkelXCLJ_EGkR uyQCS4lMkx.Y.4d.XqqdEsAc0BNAdwW_MV5_0WwLp8tFKjIptqRvUW2KIfWu BTN7sqraJhKwD1lohljsuz_aOTGvD7A-- Received: from [61.1.239.214] by web122106.mail.ne1.yahoo.com via HTTP; Fri, 11 Sep 2015 22:57:36 PDT X-Rocket-MIMEInfo: 002.001, SGkgTWFyaXVzLA0KDQpUaGFua3MgZm9yIHRoZSBwYXRjaC4gSSBtYW51YWxseSBtYWRlIGNoYW5nZXMgdG8gdGhlIHR3byBmaWxlcywgYW5kIGFmdGVyIGJ1aWxkaW5nIHRoZSBrZXJuZWwgYW5kIGluc3RhbGxpbmcgaXQsDQpJIGNhbiBzZWUgdGhlIHJlMCBpbnRlcmZhY2UuIEkgYW0gbm93IHNlbmRpbmcgdGhpcyBlbWFpbCB1c2luZyB0aGUgbmV3IGxhcHRvcC4NCg0KSG93ZXZlciwgSSBhbSBhIGJpdCBjb25mdXNlZCBieSB0aGUgZG1lc2cgb3V0cHV0LiBJIHNlZSB0d28gc2V0cyBvZiBsaW5lcyBwZXJ0YWkBMAEBAQE- X-Mailer: YahooMailBasic/654 YahooMailWebService/0.8.203.813 Message-ID: <1442037456.3232.YahooMailBasic@web122106.mail.ne1.yahoo.com> Date: Fri, 11 Sep 2015 22:57:36 -0700 From: Sreenath Battalahalli Subject: Re: realtek interface not working To: Marius Strobl Cc: freebsd-net@freebsd.org In-Reply-To: <20150910191240.GA97360@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2015 06:04:15 -0000 Hi Marius, Thanks for the patch. I manually made changes to the two files, and after b= uilding the kernel and installing it, I can see the re0 interface. I am now sending this email using the new lapt= op. However, I am a bit confused by the dmesg output. I see two sets of lines p= ertaining to the re0 device. $dmesg | grep -i re0 re0: port 0x300= 0-0x30ff mem 0xb0604000-0xb0604fff,0xb0600000-0xb0603fff irq 18 at device 0= .0 on pci2 re0: Using 1 MSI-X message re0: turning off MSI enable bit. re0: ASPM disabled re0: Chip rev. 0x54000000 re0: MAC rev. 0x00100000 re0: Unknown H/W revision: 0x54000000 device_attach: re0 attach returned 6 re0: port 0x300= 0-0x30ff mem 0xb0604000-0xb0604fff,0xb0600000-0xb0603fff irq 18 at device 0= .0 on pci2 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip rev. 0x54000000 re0: MAC rev. 0x00100000 miibus0: on re0 re0: Using defaults for TSO: 65518/35/2048 re0: Ethernet address: 2c:60:0c:92:0f:c2 seems the driver attempted to initialize the device twice? Anyway, it is working now. thanks, Sreenath -------------------------------------------- On Thu, 9/10/15, Marius Strobl wrote: Subject: Re: realtek interface not working To: "Sreenath Battalahalli" Cc: freebsd-net@freebsd.org Date: Thursday, September 10, 2015, 7:12 PM =20 On Thu, Sep 10, 2015 at 08:33:06AM -0700, Sreenath Battalahalli wrote: > Hi=20 >=20 > I got=A0 a new laptop (Acer E5-573) that has a Realtek 1Gbps adapter. > ifconfig after booting does not list re0 interface. >=20 > Here are relevant lines from dmesg: >=20 > re0: port 0x3000-0x3 > 0ff mem 0xb0604000-0xb0604fff,0xb0600000-0xb0603fff irq 18 at device 0.0 on pci2 > re0: Using 1 MSI-X message > re0: turning off MSI enable bit. > re0: ASPM disabled > re0: Chip rev. 0x54000000 > re0: MAC rev. 0x00100000 > re0: Unknown H/W revision: 0x54000000 > device_attach: re0 attach returned 6 >=20 > Looks like this hardware is not supported by the driver. >=20 > Freebsd version is 10.2 amd64=20 >=20 > any help if getting this to work appreciated. >=20 =20 Please give the attached patch a try. =20 Marius =20 From owner-freebsd-net@freebsd.org Sat Sep 12 08:47:53 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3345DA0207C for ; Sat, 12 Sep 2015 08:47:53 +0000 (UTC) (envelope-from trtrmitya@gmail.com) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD9101831 for ; Sat, 12 Sep 2015 08:47:52 +0000 (UTC) (envelope-from trtrmitya@gmail.com) Received: by lamp12 with SMTP id p12so59815653lam.0 for ; Sat, 12 Sep 2015 01:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kUSYFX3ahckE+/N7F1XMKQxxEyNKWXbIJGRqqU8eMJw=; b=jIRADvYQj5QQu7t8qyWaFMsjyDETg1wuRTM0uYbLc+SFB1beEL8Ph19GSp2a0scxFq S/T3DUR8TZXlPNNOmFEr4NZO3gI9A+/QIAa+VVWQOmdGNqMOI/cswTXv7oDCqJs1DF3c o4Zq3Ny2Xl9EEAEbTDM6LjaiTSgNSfNRTyUWJjpawZHCIG5NNmb66SIh0ycevoTtxWA/ Yva+CVfvos57lcWWKeJvh2fKD/DCePLVqpB9KS74OqJr/nUkQeSpOVpsd8kDMeTnZPUd UpkcGMhwxVBeHInuv0bAJfX5VZcWuOWf9m900NkWXzZQB/F902MbJI5O0eXBZYmQWuKN IK6g== X-Received: by 10.112.180.137 with SMTP id do9mr2951531lbc.78.1442047669329; Sat, 12 Sep 2015 01:47:49 -0700 (PDT) Received: from [172.20.10.4] ([213.87.146.32]) by smtp.gmail.com with ESMTPSA id h10sm649960lam.29.2015.09.12.01.47.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 12 Sep 2015 01:47:47 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: netisr process eats 100% cpu From: Dmitry Sivachenko In-Reply-To: <20150911171910.GN64965@strugglingcoder.info> Date: Sat, 12 Sep 2015 11:47:45 +0300 Cc: FreeBSD Net Content-Transfer-Encoding: quoted-printable Message-Id: <5599DAD0-55CD-4B36-B667-F943737C2D85@gmail.com> References: <20150911171910.GN64965@strugglingcoder.info> To: hiren panchasara X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2015 08:47:53 -0000 > On 11 =D1=81=D0=B5=D0=BD=D1=82. 2015 =D0=B3., at 20:19, hiren = panchasara wrote: >=20 > On 09/11/15 at 12:46P, Dmitry Sivachenko wrote: >>=20 >>> hiren panchasara wrote: >>>=20 >>> Unsure at the moment if loopback is causing the trouble for you or = not. >>> See: >>=20 >> (please keep me CC'ed, I am not subscribed to -net) >>=20 >>=20 >>>=20 >>> = https://lists.freebsd.org/pipermail/freebsd-net/2015-February/041239.html >>>=20 >>>=20 >>=20 >> Yes, this thread looks similar. >>=20 >>=20 >>> You may want to try: >>> 1) pmcstat and see if you can catch something >>=20 >> What particular should I look for? Here is first lines of pmcstat -T = -S instructions -w 1: >> PMC: [INSTR_RETIRED_ANY] Samples: 157198 (100.0%) , 0 unresolved >>=20 >> %SAMP IMAGE FUNCTION CALLERS >> 13.2 kernel cpu_search_highest cpu_search_highest:12.0 = sched_idletd:1.2 >> 8.3 kernel ipfw_chk ipfw_check_packet >> 3.1 myprogram memsetAVX _ZN12TLz4Compress7DoWriteEPKv >> 2.3 kernel tcp_output tcp_usr_send:1.0 = tcp_do_segment:0.9 >>=20 >>=20 >>> 2) disable checksum on localhost >>=20 >>=20 >> I tried, but nothing has changed. >>=20 >>=20 >>> 3) look at netisr settings. sysctl net.isr o/p and how it looks = under >>> netstat -Q. I am not sure if adding more threads to netisr via >>=20 >>=20 >> What should I look for? >>=20 >>=20 >>> net.isr.numthreads would help. (Note its a loader.conf variable) >>=20 >>=20 >> This netisr load looks parasitical to me (as I noted, moving haproxy = to a separate machine does not burn CPU cycles on netisr, why is = localhost special?) >>=20 >> Even if adding more threads to netisr would boost network = utilization, wouldn't those CPU cycles spent for netisr just be a waste = of energy? I have other tasks for these CPU. >>=20 >=20 > I am not sure what keep cpu busy with netisr when localhost is = involved. >=20 > You may want to post o/p of=20 > # sysctl net.isr net.isr.numthreads: 1 net.isr.maxprot: 16 net.isr.defaultqlimit: 256 net.isr.maxqlimit: 10240 net.isr.bindthreads: 0 net.isr.maxthreads: 1 net.isr.dispatch: direct > # netstat -Q Configuration: Setting Current Limit Thread count 1 1 Default queue limit 256 10240 Dispatch policy direct n/a Threads bound to CPUs disabled n/a Protocols: Name Proto QLimit Policy Dispatch Flags ip 1 4096 flow default --- igmp 2 256 source default --- rtsock 3 256 source default --- arp 7 256 source default --- ether 9 256 source direct --- ip6 10 256 flow default --- Workstreams: WSID CPU Name Len WMark Disp'd HDisp'd QDrops Queued = Handled 0 0 ip 8 165 9862463 0 0 126594714 = 136424969 0 0 igmp 0 0 0 0 0 0 = 0 0 0 rtsock 0 1 0 0 0 10 = 10 0 0 arp 0 0 15640 0 0 0 = 15640 0 0 ether 0 0 9878107 0 0 0 = 9878107 0 0 ip6 0 2 4 0 0 12 = 16 > # sysctl net.inet | grep queue net.inet.ip.intr_queue_maxlen: 4096 net.inet.ip.intr_queue_drops: 0 net.inet.ip.dummynet.queue_count: 0 >=20 > A suggestion I see at https://calomel.org/freebsd_network_tuning.html = is > to increase localhost n/w buffers. Not sure if this'll help your case. > net.local.stream.sendspace=3D164240 # (default 8192) > net.local.stream.recvspace=3D164240 # (default 8192) I already had 65536 for that, but increased up to 164240, nothing has = changed. >=20 > Now I'll let someone else with more ideas/clues comment. >=20 From owner-freebsd-net@freebsd.org Sat Sep 12 10:43:50 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8DA50A027C3 for ; Sat, 12 Sep 2015 10:43:50 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5187D1395 for ; Sat, 12 Sep 2015 10:43:50 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by mail.in-addr.com with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1ZaiHb-000Fqw-2d; Sat, 12 Sep 2015 11:43:47 +0100 Date: Sat, 12 Sep 2015 11:43:47 +0100 From: Gary Palmer To: Sreenath Battalahalli Cc: Marius Strobl , freebsd-net@freebsd.org Subject: Re: realtek interface not working Message-ID: <20150912104347.GA45080@in-addr.com> References: <20150910191240.GA97360@alchemy.franken.de> <1442037456.3232.YahooMailBasic@web122106.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1442037456.3232.YahooMailBasic@web122106.mail.ne1.yahoo.com> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2015 10:43:50 -0000 On Fri, Sep 11, 2015 at 10:57:36PM -0700, Sreenath Battalahalli wrote: > Hi Marius, > > Thanks for the patch. I manually made changes to the two files, and after building the kernel and installing it, > I can see the re0 interface. I am now sending this email using the new laptop. > > However, I am a bit confused by the dmesg output. I see two sets of lines pertaining to the re0 device. > > $dmesg | grep -i re0 > > re0: port 0x3000-0x30ff mem 0xb0604000-0xb0604fff,0xb0600000-0xb0603fff irq 18 at device 0.0 on pci2 > re0: Using 1 MSI-X message > re0: turning off MSI enable bit. > re0: ASPM disabled > re0: Chip rev. 0x54000000 > re0: MAC rev. 0x00100000 > re0: Unknown H/W revision: 0x54000000 > device_attach: re0 attach returned 6 > re0: port 0x3000-0x30ff mem 0xb0604000-0xb0604fff,0xb0600000-0xb0603fff irq 18 at device 0.0 on pci2 > re0: Using 1 MSI-X message > re0: ASPM disabled > re0: Chip rev. 0x54000000 > re0: MAC rev. 0x00100000 > miibus0: on re0 > re0: Using defaults for TSO: 65518/35/2048 > re0: Ethernet address: 2c:60:0c:92:0f:c2 > > seems the driver attempted to initialize the device twice? > > Anyway, it is working now. The kernel dmesg buffer can be preserved over a reboot, so it's possible the lines up to and including "device_attach: re0 attach returned 6" are from the reboot before you installed the patch. Rather than just grep for re0, do "dmesg | less" or "dmesg | more" and check the context of the "device_attach: re0 attach returned 6" error and see if there are any indications of a reboot between that line and the next re0 probe lines, e.g. "Copyright (c) 1992-2015 The FreeBSD Project" Regards, Gary From owner-freebsd-net@freebsd.org Sat Sep 12 15:17:35 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 251A5A015FD for ; Sat, 12 Sep 2015 15:17:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 10EAF1CEC for ; Sat, 12 Sep 2015 15:17:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8CFHYOY094036 for ; Sat, 12 Sep 2015 15:17:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 202983] ixv driver in 11.0-CURRENT(10.1 & 10.2 RELEASE) doesn't pass traffic using XEN hypervisor(AWS EC2) Date: Sat, 12 Sep 2015 15:17:34 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: erj@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2015 15:17:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202983 Eric Joyner changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |IntelNetworking CC| |erj@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@freebsd.org Sat Sep 12 15:27:40 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3ACC4A01BD6 for ; Sat, 12 Sep 2015 15:27:40 +0000 (UTC) (envelope-from sreenathbh@rocketmail.com) Received: from nm26.bullet.mail.ne1.yahoo.com (nm26.bullet.mail.ne1.yahoo.com [98.138.90.89]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 066E9110C for ; Sat, 12 Sep 2015 15:27:39 +0000 (UTC) (envelope-from sreenathbh@rocketmail.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rocketmail.com; s=s2048; t=1442071652; bh=ia6n1Blzx8/OEEunzLyqURWfsps5dkJ2o68c4qy5e3k=; h=Date:From:Subject:To:Cc:In-Reply-To:From:Subject; b=VhwzdQOb6g54KeQ6IajuPvvfVqgnx1Q61xfsx4qZ9NUj8qEKJBJ3LqvN2sjHDVLdYnbwxUzJfSiD1Dr1ds130SRci/Q8hU2Cs5S9JKifbtjkhxcuO4Zz+lOnTijLvETAL4c4ZgXJxP2fd9Lv7lqwahcFt084lXn152tV2qpHA+ZKa6edW18QkhtsrKKwnwmuvGsmTlR59H1FPQ5bi6LbU/Q0JRAjJkfgG5kb3O87QP1nO6uhxfr+/F1x3GbbsBz6X4NNjKiUEZA3wirVBEbfYzlzu97mQzuk4XUxLF346FTU73ed/OTvSSevdxVHE+LEQNPvxywEG8crXbaw688bgQ== Received: from [98.138.100.112] by nm26.bullet.mail.ne1.yahoo.com with NNFMP; 12 Sep 2015 15:27:32 -0000 Received: from [98.138.226.161] by tm103.bullet.mail.ne1.yahoo.com with NNFMP; 12 Sep 2015 15:27:32 -0000 Received: from [127.0.0.1] by omp1062.mail.ne1.yahoo.com with NNFMP; 12 Sep 2015 15:27:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 790580.72842.bm@omp1062.mail.ne1.yahoo.com Received: (qmail 34137 invoked by uid 60001); 12 Sep 2015 15:27:32 -0000 X-YMail-OSG: xJ6mjIEVM1nUziGgnIVg7EuxJ4vlh9ckBY1W6boEPqS.fs9 OClwUAhGOncJW5iyd3ZGhHjjlhNGcD8iCJGhsxrqAx0QjsSWQH7lPnI9kzYe IX0Ju5Drv15l6jHkVs5k5P9vh4InkNAzPnLOckSPcGMg4aYIjofua8qU.dM2 qbAmNkfzDXn.lQgMdEdaHoAyCf5dEo.E9L2ca17pfQXFlN3vSClUoyrL8tlJ eoJVwOKDhr0NwyMO3wCuWPb6t7KYhZKXAiEUmQGKbkUN1nOK0jOtMhopA3YZ PW3_LVL9YwA2BTVewdrqhYOruYds_CclVGBJM6Ysf.hYlyHyq_w5OO7VzCNH YCEpeebqvlzKev6vefQQ7br4kNc0hQV12T4AD26tklR1R4EvsmFGclSoG9Po m87EJZM6UMSaohChx.TOwi7bOGk_lbmXpsB410Lyfvx0YBOWsjQe3Q1baQfl 8dlz0msWwJq2ysvRS68k4iWEOtIcrH89Q4f65oW.caV4wxUi7r3CcJEJ9.KB QEq8..2NUgkknsrs7pPjEajmit6qL_2W3t28s0PllDeAG1FdZQOuwkUoo8t. QPG0C.Oo- Received: from [61.1.246.48] by web122105.mail.ne1.yahoo.com via HTTP; Sat, 12 Sep 2015 08:27:32 PDT X-Rocket-MIMEInfo: 002.001, SGkgR2FyeSwNCg0KSXQgbXVzdCBoYXZlIGJlZW4gcmVzdWx0IG9mIHByZXZpb3VzIGJvb3QuIEl0IGlzIG5vdyBnb25lIGFmdGVyIGEgY291cGxlIG9mIHJlYm9vdHMuDQoNCnRoYW5rcywNClNyZWVuYXRoDQogDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KT24gU2F0LCA5LzEyLzE1LCBHYXJ5IFBhbG1lciA8Z3BhbG1lckBmcmVlYnNkLm9yZz4gd3JvdGU6DQoNCiBTdWJqZWN0OiBSZTogcmVhbHRlayBpbnRlcmZhY2Ugbm90IHdvcmtpbmcNCiBUbzogIlNyZWVuYXRoIEIBMAEBAQE- X-Mailer: YahooMailBasic/654 YahooMailWebService/0.8.203.813 Message-ID: <1442071652.20114.YahooMailBasic@web122105.mail.ne1.yahoo.com> Date: Sat, 12 Sep 2015 08:27:32 -0700 From: Sreenath Battalahalli Subject: Re: realtek interface not working To: Gary Palmer Cc: Marius Strobl , freebsd-net@freebsd.org In-Reply-To: <20150912104347.GA45080@in-addr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2015 15:27:40 -0000 Hi Gary, It must have been result of previous boot. It is now gone after a couple of= reboots. thanks, Sreenath =20 -------------------------------------------- On Sat, 9/12/15, Gary Palmer wrote: Subject: Re: realtek interface not working To: "Sreenath Battalahalli" Cc: "Marius Strobl" , freebsd-net@freebsd.org Date: Saturday, September 12, 2015, 10:43 AM =20 On Fri, Sep 11, 2015 at 10:57:36PM -0700, Sreenath Battalahalli wrote: > Hi Marius, >=20 > Thanks for the patch. I manually made changes to the two files, and after building the kernel and installing it, > I can see the re0 interface. I am now sending this email using the new laptop. >=20 > However, I am a bit confused by the dmesg output. I see two sets of lines pertaining to the re0 device. >=20 > $dmesg | grep -i re0 > =20 > re0: port 0x3000-0x30ff mem 0xb0604000-0xb0604fff,0xb0600000-0xb0603fff irq 18 at device 0.0 on pci2 > re0: Using 1 MSI-X message > re0: turning off MSI enable bit. > re0: ASPM disabled > re0: Chip rev. 0x54000000 > re0: MAC rev. 0x00100000 > re0: Unknown H/W revision: 0x54000000 > device_attach: re0 attach returned 6 > re0: port 0x3000-0x30ff mem 0xb0604000-0xb0604fff,0xb0600000-0xb0603fff irq 18 at device 0.0 on pci2 > re0: Using 1 MSI-X message > re0: ASPM disabled > re0: Chip rev. 0x54000000 > re0: MAC rev. 0x00100000 > miibus0: on re0 > re0: Using defaults for TSO: 65518/35/2048 > re0: Ethernet address: 2c:60:0c:92:0f:c2 >=20 > seems the driver attempted to initialize the device twice? >=20 > Anyway, it is working now. =20 The kernel dmesg buffer can be preserved over a reboot, so it's possible the lines up to and including "device_attach: re0 attach returned 6" are from the reboot before you installed the patch.=A0 Rather than just grep for re0, do "dmesg | less" or "dmesg | more" and check the context of the=20 "device_attach: re0 attach returned 6" error and see if there are any=20 indications of a reboot between that line and the next re0 probe lines, e.g. "Copyright (c) 1992-2015 The FreeBSD Project" =20 Regards, =20 Gary From owner-freebsd-net@freebsd.org Sat Sep 12 17:20:46 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34CA5A03C71 for ; Sat, 12 Sep 2015 17:20:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE9E419B6 for ; Sat, 12 Sep 2015 17:20:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id t8CHKd4q097636 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 12 Sep 2015 20:20:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua t8CHKd4q097636 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t8CHKdkD097634; Sat, 12 Sep 2015 20:20:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 12 Sep 2015 20:20:39 +0300 From: Konstantin Belousov To: Dmitry Sivachenko Cc: hiren panchasara , FreeBSD Net Subject: Re: netisr process eats 100% cpu Message-ID: <20150912172039.GP2072@kib.kiev.ua> References: <20150911171910.GN64965@strugglingcoder.info> <5599DAD0-55CD-4B36-B667-F943737C2D85@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5599DAD0-55CD-4B36-B667-F943737C2D85@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2015 17:20:46 -0000 On Sat, Sep 12, 2015 at 11:47:45AM +0300, Dmitry Sivachenko wrote: > > > On 11 сент. 2015 г., at 20:19, hiren panchasara wrote: > > > > On 09/11/15 at 12:46P, Dmitry Sivachenko wrote: > >> > >>> hiren panchasara wrote: > >>> > >>> Unsure at the moment if loopback is causing the trouble for you or not. > >>> See: > >> > >> (please keep me CC'ed, I am not subscribed to -net) > >> > >> > >>> > >>> https://lists.freebsd.org/pipermail/freebsd-net/2015-February/041239.html > >>> > >>> > >> > >> Yes, this thread looks similar. > >> > >> > >>> You may want to try: > >>> 1) pmcstat and see if you can catch something > >> > >> What particular should I look for? Here is first lines of pmcstat -T -S instructions -w 1: > >> PMC: [INSTR_RETIRED_ANY] Samples: 157198 (100.0%) , 0 unresolved > >> > >> %SAMP IMAGE FUNCTION CALLERS > >> 13.2 kernel cpu_search_highest cpu_search_highest:12.0 sched_idletd:1.2 > >> 8.3 kernel ipfw_chk ipfw_check_packet > >> 3.1 myprogram memsetAVX _ZN12TLz4Compress7DoWriteEPKv > >> 2.3 kernel tcp_output tcp_usr_send:1.0 tcp_do_segment:0.9 > >> > >> > >>> 2) disable checksum on localhost > >> > >> > >> I tried, but nothing has changed. > >> > >> > >>> 3) look at netisr settings. sysctl net.isr o/p and how it looks under > >>> netstat -Q. I am not sure if adding more threads to netisr via > >> > >> > >> What should I look for? > >> > >> > >>> net.isr.numthreads would help. (Note its a loader.conf variable) > >> > >> > >> This netisr load looks parasitical to me (as I noted, moving haproxy to a separate machine does not burn CPU cycles on netisr, why is localhost special?) > >> Loopback is special since network stack input path must return the packets into the output path, and doing it by direct function call would recurse the stack. Netisr allows to queue the packet and then deliver it using the safe context. At least this is my limited understanding of the loopback+netisr coupling. Why it takes so much CPU for output processing, is beyond my knowledge of the network. But some resources have to be spent on localhost. > >> Even if adding more threads to netisr would boost network utilization, wouldn't those CPU cycles spent for netisr just be a waste of energy? I have other tasks for these CPU. > >> > > > > I am not sure what keep cpu busy with netisr when localhost is involved. > > > > You may want to post o/p of > > # sysctl net.isr > > net.isr.numthreads: 1 > net.isr.maxprot: 16 > net.isr.defaultqlimit: 256 > net.isr.maxqlimit: 10240 > net.isr.bindthreads: 0 > net.isr.maxthreads: 1 > net.isr.dispatch: direct > > > > # netstat -Q > > Configuration: > Setting Current Limit > Thread count 1 1 > Default queue limit 256 10240 > Dispatch policy direct n/a > Threads bound to CPUs disabled n/a > > Protocols: > Name Proto QLimit Policy Dispatch Flags > ip 1 4096 flow default --- > igmp 2 256 source default --- > rtsock 3 256 source default --- > arp 7 256 source default --- > ether 9 256 source direct --- > ip6 10 256 flow default --- > > Workstreams: > WSID CPU Name Len WMark Disp'd HDisp'd QDrops Queued Handled > 0 0 ip 8 165 9862463 0 0 126594714 136424969 > 0 0 igmp 0 0 0 0 0 0 0 > 0 0 rtsock 0 1 0 0 0 10 10 > 0 0 arp 0 0 15640 0 0 0 15640 > 0 0 ether 0 0 9878107 0 0 0 9878107 > 0 0 ip6 0 2 4 0 0 12 16 > > > > # sysctl net.inet | grep queue > > net.inet.ip.intr_queue_maxlen: 4096 > net.inet.ip.intr_queue_drops: 0 > net.inet.ip.dummynet.queue_count: 0 > > > > > > A suggestion I see at https://calomel.org/freebsd_network_tuning.html is > > to increase localhost n/w buffers. Not sure if this'll help your case. > > net.local.stream.sendspace=164240 # (default 8192) > > net.local.stream.recvspace=164240 # (default 8192) > > > I already had 65536 for that, but increased up to 164240, nothing has changed. > > > > > > Now I'll let someone else with more ideas/clues comment. > > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"