From owner-freebsd-net@FreeBSD.ORG Sun Oct 21 05:19:32 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1BF11C37; Sun, 21 Oct 2012 05:19:32 +0000 (UTC) (envelope-from nevzorovn@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4C8098FC0A; Sun, 21 Oct 2012 05:19:30 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so1296816lag.13 for ; Sat, 20 Oct 2012 22:19:29 -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=hC2XunksSu064KAu/65fRk5n4ot1I9KVGJwvmjDosQg=; b=XEsq1eYQ4ktWE0ppf/YLpdyy+ozyIpWvUb4addE2ggtrYHTU26oI6Z044hZr3DCu84 cv2VdxTCk7zG5vEJ5WXQKp/vZCUMi/cIREW912AJ/Ze7h/Rx5O0rAJ2xDrVnTklS2AjO MohMnjVYqX0/IZfFu0I2pXPKPSyEbwKQjDK+wd3qeGY9Kq+Jdx+UPb1YCd6UPnP4pN1P jVoDR+Yy3ITeFtPyCNjlMYp8Pqs5m54m9DuwsyNkpcUORv2bNtTpgcxtVQo+cX7Fs2Nn 5wMwy1lCXHA0MgW7kv58IzSwOW0rLsuynd6rhNbFBkh9BdtTt5rV6F4k3m/N+t4Rm25x 3OxQ== MIME-Version: 1.0 Received: by 10.152.106.110 with SMTP id gt14mr4891093lab.1.1350796768914; Sat, 20 Oct 2012 22:19:28 -0700 (PDT) Received: by 10.112.42.70 with HTTP; Sat, 20 Oct 2012 22:19:28 -0700 (PDT) In-Reply-To: <50830F8B.4030204@rdtc.ru> References: <201210180141.q9I1f53s052539@freefall.freebsd.org> <50830F8B.4030204@rdtc.ru> Date: Sun, 21 Oct 2012 11:19:28 +0600 Message-ID: Subject: Re: kern/171520: [alc] alc network driver + tso + vlan does not work. From: Nikolay Nevzorov To: Eugene Grosbein Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org, yongari@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 05:19:32 -0000 There is libalias in my kernel config, and i use it on ng0, not on alc0. And libalias used not in ipfw - netgraph with it builded by mpd. Anyway this bug? 2012/10/21 Eugene Grosbein > 20.10.2012 20:06, Nikolay Nevzorov wrote: > > >> Synopsis: [alc] alc network driver + tso + vlan does not work. > > It seems you use libalias-based NAT, don't you? > > man ipfw says in the BUGS section: > > Due to the architecture of libalias(3), ipfw nat is not compatible > with > the TCP segmentation offloading (TSO). Thus, to reliably nat your > net- > work traffic, please disable TSO on your NICs using ifconfig(8). > > Eugene Grosbein > From owner-freebsd-net@FreeBSD.ORG Sun Oct 21 11:08:22 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7B50CBED; Sun, 21 Oct 2012 11:08:22 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id C7F2F8FC0A; Sun, 21 Oct 2012 11:08:21 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q9LB8HLC030660; Sun, 21 Oct 2012 18:08:17 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <5083D79C.4010309@rdtc.ru> Date: Sun, 21 Oct 2012 18:08:12 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Nikolay Nevzorov Subject: Re: kern/171520: [alc] alc network driver + tso + vlan does not work. References: <201210180141.q9I1f53s052539@freefall.freebsd.org> <50830F8B.4030204@rdtc.ru> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, yongari@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 11:08:22 -0000 21.10.2012 12:19, Nikolay Nevzorov wrote: > There is libalias in my kernel config, and i use it on ng0, not on alc0. And libalias used not in ipfw - netgraph with it builded by mpd. Anyway this bug? AFAIK, mpd uses ng_nat(4) that is based on kernel version of libalias, the same as ipfw nat is based on. So, the warning applies to mpd's internal NAT too. I guess this should be a culprit. Can you exclude NAT to perform "clean" experiment? Does the issue disappear when you do? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sun Oct 21 13:44:41 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AC8341D9 for ; Sun, 21 Oct 2012 13:44:41 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6CFB18FC16 for ; Sun, 21 Oct 2012 13:44:41 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id z9so983724dad.13 for ; Sun, 21 Oct 2012 06:44:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2KOyUwPIkC2QA/o4rnKxvyN/P63aX4lLEQANeDTB9hI=; b=biTAvjtgvFpqjlN5AFwji1GbyxpWyC3c0gJi2+Ga29d6luhpEPwDiuY/FKkFrePaPy X2EqdmPEBmAV5fD3WRGW4Uebo8g3qXFGMGE57M0Oe16Uk684PJzG8Bmjjy/2sH4m7P8L ccI3SeIvcRu9J1QjUufnzEfXU+DBaVFSsW8CA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=2KOyUwPIkC2QA/o4rnKxvyN/P63aX4lLEQANeDTB9hI=; b=GXxyAn80mUUtevCy+U2B3BJJaepdAQ/z4NSx3vWhZY15nvG+DQockXG5eIrs4LAtqr Q8+kWl6CqYjZJXPzPg5K4bT8Nhyr6MGgPeLwKjuGq2Or2M6hmNCRcDfUE0G3goygAYGO s/oS7F1t57nshgfwsOWOv/rMgrK/fsOcqZP7lKfYkJtHHRsk2jCjFCKZeXm5AnXdNe9v n4hXoi+MHwyQVXfHrFUGjY4v1swxat/MrelfWnJ3Okn+X2fm55GJNkrnQQwD1rccp0W+ r4qmuM0WszHNetg5ScRE27ZxjEgRgyViFSWr+O9HwZIlCWA/2E6blNpkcscP3JeRbEJL TydQ== Received: by 10.68.209.170 with SMTP id mn10mr22329620pbc.11.1350827080843; Sun, 21 Oct 2012 06:44:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.161.163 with HTTP; Sun, 21 Oct 2012 06:44:10 -0700 (PDT) In-Reply-To: <508138A4.5030901@FreeBSD.org> References: <508138A4.5030901@FreeBSD.org> From: Eitan Adler Date: Sun, 21 Oct 2012 09:44:10 -0400 Message-ID: Subject: Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time To: "Andrey V. Elsukov" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQl81XORcUrKXlo8b/mwMK1PN5ySReFmsdoZX1r2SanyKHhVyCR2UZFjror/vPhKrwFIYtYv Cc: ipfw@freebsd.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 13:44:41 -0000 On 19 October 2012 07:25, Andrey V. Elsukov wrote: > Hi All, > > Many years ago i have already proposed this feature, but at that time > several people were against, because as they said, it could affect > performance. Now, when we have high speed network adapters, SMP kernel > and network stack, several locks acquired in the path of each packet, > and i have an ability to test this in the lab. > > So, i prepared the patch, that removes IPFIREWALL_FORWARD option from > the kernel and makes this functionality always build-in, but it is > turned off by default and can be enabled via the sysctl(8) variable > net.pfil.forward=1. > > http://people.freebsd.org/~ae/pfil_forward.diff Please also modify man/man4/ipfirewall.4 -- Eitan Adler From owner-freebsd-net@FreeBSD.ORG Sun Oct 21 18:21:54 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3289C9D6; Sun, 21 Oct 2012 18:21:54 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id B4F908FC0C; Sun, 21 Oct 2012 18:21:53 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1TQ0DA-000Ct9-Fk; Sun, 21 Oct 2012 22:25:20 +0400 Message-ID: <50843D39.5000003@FreeBSD.org> Date: Sun, 21 Oct 2012 22:21:45 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120121 Thunderbird/9.0 MIME-Version: 1.0 To: Ryan Stone Subject: Re: ixgbe & if_igb RX ring locking References: <5079A9A1.4070403@FreeBSD.org> <20121015162926.GV89655@FreeBSD.org> <507D4F11.2030704@FreeBSD.org> <20121016124733.GC89655@glebius.int.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jack Vogel , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 18:21:54 -0000 On 16.10.2012 17:20, Ryan Stone wrote: > On Tue, Oct 16, 2012 at 8:47 AM, Gleb Smirnoff wrote: >> Can you please provide hints how can SIOCADDMULTI lead to obtaining RX >> lock in the stock driver? > > It doesn't. But it does acquire the core lock, and the core lock is > acquired before the RX lock (in ixgbe_init, for instance). I still can't get how any of these can happen. We basically has 2 related places where ixgbe driver interact with OS: 1) forwarding path (ixgbe_rxeof via ithread / taskq) 2) ioctl path I'm currently talking about multicast only. So, first can lead us to: ixgbe_rxeof() (rxr->rx_mtx "ix:rx") ether_input() ... udp_input() (V_udbinfo "udp" READ lock) udp_input() (inp->inp_lock "udpinp" READ lock) > 2) ioctl part can lead to the following locks to be held: IXGBE_CORE_LOCK() in every ioctl ("ix?:core" mtx) ixgbe_init_locked() ixgbe_setup_receive_structures() ixgbe_setup_receive_ring() (rxr->rx_mtx "ix:rx") .. with any possibly locks prepended (like in_multi_mtx or any other) > Last time I checked(FreeBSD 8.2), this is not true. The problematic > (and convoluted) ordering is: > > ix:rx -> udp -> udpinp -> in_multi_mtx -> ix:core -> ix:rx > > udp -> udpinp -> in_multi_mtx is defined in subr_witness.c. Actually subr_witness defines the following: 1) udp -> udpinp -> so_snd 2) udpinp -> in_multi_mtx -> .. -> .. > > ix:core -> ix:rx is fairly obvious, and happens in places like ixgbe_init. > Yes. But how can I trigger reverted order (e.g. ixgbe_init[_locked]() (actually, ioctl) on packet input ? (And if such place really exists we should consider fixing it, but not the driver side) > ix:rx -> udp is also fairly obvious (here's one backtrace): The same question, where "udp" -> "ix:rx" can happen ? From owner-freebsd-net@FreeBSD.ORG Sun Oct 21 19:04:47 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E7D2D289; Sun, 21 Oct 2012 19:04:47 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id AD8B88FC14; Sun, 21 Oct 2012 19:04:47 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so1545973pbb.13 for ; Sun, 21 Oct 2012 12:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=uq7T6Yrnz95wG1fhFQRkfDB1nstfvF9tfZSBFz+bVhY=; b=HI/euCG3XCHsOSs0+JQ4QhRz7yJEdaOtux1jkLfJg1+69R874dZYpA/EcR32lacWd7 vwK2c74/BRSDoyKxJBKdWHSKH3fynf8DNt8eyvaTkqD4HCP1vJy8oEPAYLoyWYme3ojr 2DX63MNVW0reRZTC2P+PhNI0ivow1/QpL0DJvaKXvKEeJDJ8RsAQGP8Da8H0VoUKElz5 3Qu5gLVvfhJWUOboPhFZ28mcjqMKTpREdgdV9X4zTb633GOTKiWrljqNy35D3X1FzAi7 3Hrsc1meNbcvvpSOVeL+DR6nOWM0GXInq+2PKliggTbL7g3bIeSHaUTtyL5rLD/RqeDm /0aw== MIME-Version: 1.0 Received: by 10.68.223.37 with SMTP id qr5mr23889260pbc.101.1350846281636; Sun, 21 Oct 2012 12:04:41 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.146.233 with HTTP; Sun, 21 Oct 2012 12:04:41 -0700 (PDT) Date: Sun, 21 Oct 2012 12:04:41 -0700 X-Google-Sender-Auth: PUggmPaaoMBg7H4PZrPpatlH9Lo Message-ID: Subject: VIMAGE crashes on 9.x with hotplug net80211 devices From: Adrian Chadd To: FreeBSD Net , freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 19:04:48 -0000 Hi all, I have some crashes in the VIMAGE code on releng_9. Specifically, when I enable VIMAGE and then hotplug some cardbus ath(4) NICs. The panics are dereferencing the V_ ifindex and related fields. If I start adding CURVNET_SET(vnet0) and CURVNET_RESTORE() around the ifnet calls (attach, detach) then things stop panicing - however, things are slightly more complicated than that. Since it's possible that the cloned interfaces (and maybe the parent interface?) are placed into other VNETs, I have to make sure that the right vnet context is switched to before I free interfaces. So, may I please have some help by some VIMAGE-cluey people to sort out how to _properly_ get VIMAGE up on net80211? I'd like to fix this in -HEAD and -9 so people are able to use VIMAGEs for hostapd interfaces (and so I can abuse it for lots of local testing on a single laptop.) Thanks! Adrian From owner-freebsd-net@FreeBSD.ORG Sun Oct 21 19:37:31 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 91D0A93B; Sun, 21 Oct 2012 19:37:31 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.zvne.fer.hr (mail.zvne.fer.hr [161.53.66.5]) by mx1.freebsd.org (Postfix) with ESMTP id 11D058FC0A; Sun, 21 Oct 2012 19:37:29 +0000 (UTC) Received: from munja.zvne.fer.hr (161.53.66.248) by mail.zvne.fer.hr (161.53.66.5) with Microsoft SMTP Server id 14.2.298.4; Sun, 21 Oct 2012 21:36:19 +0200 Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Sun, 21 Oct 2012 21:36:18 +0200 Received: from localhost ([161.53.19.8]) by sluga.fer.hr over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 21 Oct 2012 21:36:18 +0200 From: Marko Zec To: Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices Date: Sun, 21 Oct 2012 21:36:12 +0200 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <201210212136.12788.zec@fer.hr> X-OriginalArrivalTime: 21 Oct 2012 19:36:18.0437 (UTC) FILETIME=[5774D350:01CDAFC3] Cc: freebsd-hackers@freebsd.org, Adrian Chadd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 19:37:31 -0000 On Sunday 21 October 2012 21:04:41 Adrian Chadd wrote: > Hi all, > > I have some crashes in the VIMAGE code on releng_9. Specifically, when > I enable VIMAGE and then hotplug some cardbus ath(4) NICs. > > The panics are dereferencing the V_ ifindex and related fields. > > If I start adding CURVNET_SET(vnet0) and CURVNET_RESTORE() around the > ifnet calls (attach, detach) then things stop panicing - however, > things are slightly more complicated than that. > > Since it's possible that the cloned interfaces (and maybe the parent > interface?) are placed into other VNETs, I have to make sure that the > right vnet context is switched to before I free interfaces. > > So, may I please have some help by some VIMAGE-cluey people to sort > out how to _properly_ get VIMAGE up on net80211? I'd like to fix this > in -HEAD and -9 so people are able to use VIMAGEs for hostapd > interfaces (and so I can abuse it for lots of local testing on a > single laptop.) The right approach would be to do a single CURVNET_SET(vnet0) / CURVNET_RESTORE() somewhere near the root of the call graph being triggered by the hotplug attach event. Not having any hotpluggable hardware at hand I cannot be more specific where that place could be... But most certainly doing CURVNET_SET(vnet0) on detach events would be wrong: since ifnets may be assignet to non-default vnets, CURVNET_SET(ifp->if_vnet) should be more appropriate there. Another thing that may help could be turning on options VNET_DEBUG when, as that should reveal excessive (and probably redundant) CURVNET_SET() recursions. Hope this helps, Marko From owner-freebsd-net@FreeBSD.ORG Sun Oct 21 19:50:22 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A17DCBC; Sun, 21 Oct 2012 19:50:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 44A428FC0A; Sun, 21 Oct 2012 19:50:22 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so1492586pad.13 for ; Sun, 21 Oct 2012 12:50:21 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=8icWhKDQHJZo3nR717X8mO226QO0XOxuOhFYFv4NUXw=; b=bKELu/o9MBLt3z3wPDcEhBn/iLTZfVmP5IcAucLOfziF9SX+/f1pV+Uq505fz+7wk7 CuQM0VMw5KhUi14zEGj+v8fTOzJj03zSBr+lsBd2sMOraNoGlltr0P2csryaefiklaNe qVkaDzpx926wh4V5Zf4bZfZd/6nLYnSGPxoTJXc1w4HwHYJXhMnySMmAelA7EDd9R5D7 +si9YY0OABwxuXOlcMEuZ3X5XjZf2sMyuHIsxnfIqO/iKox660j+R1c9DN1hYa1ltxVB CpUCeiYL9cgVoJM6zi9djR4xHVtMtKN3RH3m+kmsf9lAM25IX6d9TshG0GdQ64fcBRmn 77kA== MIME-Version: 1.0 Received: by 10.68.223.37 with SMTP id qr5mr24128191pbc.101.1350849021773; Sun, 21 Oct 2012 12:50:21 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.146.233 with HTTP; Sun, 21 Oct 2012 12:50:21 -0700 (PDT) In-Reply-To: <201210212136.12788.zec@fer.hr> References: <201210212136.12788.zec@fer.hr> Date: Sun, 21 Oct 2012 12:50:21 -0700 X-Google-Sender-Auth: aK8bDgxtAYk1X4HI0zO1NPKCO-I Message-ID: Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices From: Adrian Chadd To: Marko Zec Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 19:50:22 -0000 On 21 October 2012 12:36, Marko Zec wrote: > The right approach would be to do a single CURVNET_SET(vnet0) / > CURVNET_RESTORE() somewhere near the root of the call graph being triggered > by the hotplug attach event. Not having any hotpluggable hardware at hand > I cannot be more specific where that place could be... Right; would that be at the net80211 side, or something higher up (eg at device_attach, which gets called from the cardbus/pci bridge enumeration code.) > But most certainly doing CURVNET_SET(vnet0) on detach events would be wrong: > since ifnets may be assignet to non-default vnets, > CURVNET_SET(ifp->if_vnet) should be more appropriate there. Thanks for that. I'll look at adding that in my next debug pass. > Another thing that may help could be turning on options VNET_DEBUG when, as > that should reveal excessive (and probably redundant) CURVNET_SET() > recursions. I've spotted a couple, however the crashing here is the important bit. :-) So - why is it that the V_* variables are NULL pointers at this stage? I thought the kernel would've been running with a default vnet context of vnet0? Why doesn't this impact other network device hotplugging? Or does it, and noone noticed? Adrian From owner-freebsd-net@FreeBSD.ORG Sun Oct 21 21:22:58 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 22A48A3E; Sun, 21 Oct 2012 21:22:58 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.zvne.fer.hr (mail.zvne.fer.hr [161.53.66.5]) by mx1.freebsd.org (Postfix) with ESMTP id 6ED818FC12; Sun, 21 Oct 2012 21:22:57 +0000 (UTC) Received: from munja.zvne.fer.hr (161.53.66.248) by mail.zvne.fer.hr (161.53.66.5) with Microsoft SMTP Server id 14.2.298.4; Sun, 21 Oct 2012 23:22:55 +0200 Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Sun, 21 Oct 2012 23:22:54 +0200 Received: from localhost ([161.53.19.8]) by sluga.fer.hr over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 21 Oct 2012 23:22:54 +0200 From: Marko Zec To: Adrian Chadd Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices Date: Sun, 21 Oct 2012 23:22:48 +0200 User-Agent: KMail/1.9.10 References: <201210212136.12788.zec@fer.hr> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <201210212322.48791.zec@fer.hr> X-OriginalArrivalTime: 21 Oct 2012 21:22:54.0647 (UTC) FILETIME=[3BE50470:01CDAFD2] Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 21:22:58 -0000 On Sunday 21 October 2012 21:50:21 Adrian Chadd wrote: > On 21 October 2012 12:36, Marko Zec wrote: > > The right approach would be to do a single CURVNET_SET(vnet0) / > > CURVNET_RESTORE() somewhere near the root of the call graph being > > triggered by the hotplug attach event. Not having any hotpluggable > > hardware at hand I cannot be more specific where that place could be... > > Right; would that be at the net80211 side, or something higher up (eg > at device_attach, which gets called from the cardbus/pci bridge > enumeration code.) As high as it gets - if you get lucky, as a side effect you might even fix similar issues with USB hotplugging. > > But most certainly doing CURVNET_SET(vnet0) on detach events would be > > wrong: since ifnets may be assignet to non-default vnets, > > CURVNET_SET(ifp->if_vnet) should be more appropriate there. > > Thanks for that. I'll look at adding that in my next debug pass. > > > Another thing that may help could be turning on options VNET_DEBUG > > when, as that should reveal excessive (and probably redundant) > > CURVNET_SET() recursions. > > I've spotted a couple, however the crashing here is the important bit. > :-) > > So - why is it that the V_* variables are NULL pointers at this stage? > I thought the kernel would've been running with a default vnet context > of vnet0? Why doesn't this impact other network device hotplugging? Or > does it, and noone noticed? By design, the kernel is never running "by default" in any of the vnets (vnet0 included). If it were, it would be extremely difficult to spot and catch many cases where a subsystem would be (implicitly) working with vnet0, while in fact it should be working in a different vnet context. Obviously, handling device attach events is an exception from this rule, and up to this date this was never properly addressed... Marko From owner-freebsd-net@FreeBSD.ORG Sun Oct 21 23:03:20 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 676F884D; Sun, 21 Oct 2012 23:03:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2EA838FC0C; Sun, 21 Oct 2012 23:03:19 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so1605201pbb.13 for ; Sun, 21 Oct 2012 16:03:19 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=MgcSrK6YkEFyCt6yEqt9hLK1mIzs6+21zehB/85verY=; b=D7gefFSv83/pcKrTLg2sMOhsp46v9QIIU2NVVkF2Mv7TByZp+TAT6D/6kkrYuTjNaq 0doRkxgIBXZfin2miuL0oO+AK5YsoMGj8BQaVFYhoiH40p/J0oYh2s7AAF8Mh+CJIi/t LuNlAaUH0tpmbITtsfXDDEzBBl5GUG7iRHfxCrNkVftzYymktpU78YiKt/tkm679oaCr 1eiobWp+Gr8HUPHa0yNlkRshOuzlHJu63zvx0WcvZEOVzxTjxZe586mIxmPdj2H+OgC/ W9mMieFr8YpjjevBt3/LgnE8Y0FDsK63SN3A5AERgSKXDbXKpVzmo6RqiYUd8ab32jeJ Jn0Q== MIME-Version: 1.0 Received: by 10.66.78.199 with SMTP id d7mr21235671pax.77.1350860599701; Sun, 21 Oct 2012 16:03:19 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.146.233 with HTTP; Sun, 21 Oct 2012 16:03:19 -0700 (PDT) In-Reply-To: <201210212322.48791.zec@fer.hr> References: <201210212136.12788.zec@fer.hr> <201210212322.48791.zec@fer.hr> Date: Sun, 21 Oct 2012 16:03:19 -0700 X-Google-Sender-Auth: 8G4_jzbZ1V8ahBqzP7sb3BbEy54 Message-ID: Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices From: Adrian Chadd To: Marko Zec Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 23:03:20 -0000 On 21 October 2012 14:22, Marko Zec wrote: >> Right; would that be at the net80211 side, or something higher up (eg >> at device_attach, which gets called from the cardbus/pci bridge >> enumeration code.) > > As high as it gets - if you get lucky, as a side effect you might even fix > similar issues with USB hotplugging. Right. There's three problems: * the device attach (ath_attach, calls if_* calls) * the net80211 device attach; * the net80211 vap attach. There's also detaching all of the above too. >> So - why is it that the V_* variables are NULL pointers at this stage? >> I thought the kernel would've been running with a default vnet context >> of vnet0? Why doesn't this impact other network device hotplugging? Or >> does it, and noone noticed? > > By design, the kernel is never running "by default" in any of the vnets > (vnet0 included). If it were, it would be extremely difficult to spot and > catch many cases where a subsystem would be (implicitly) working with > vnet0, while in fact it should be working in a different vnet context. Right. Well, that's why it's panicing then. > Obviously, handling device attach events is an exception from this rule, and > up to this date this was never properly addressed... *laugh*. The problem now is figuring out how to do it without modifying all the drivers. The attach is easy - I can likely set it up during the device_attach() pass. I can do that, but it's enforcing "networking-ness" with the device attach, which will be called for networking and non-networking devices alike. However detach isn't easy - because I'm required to call CURVNET_SET(ifp->if_vnet) and CURVNET_RESTORE() around if_free(), and if_free() is called in the device specific detach() routine, I can't easily set the current VNET context from outside the driver. I _guess_ I could device_attach() to use CURVNET_SET(vnet0) but device_detach() can't do the same - it doesn't "know" about the networking-ness of the device. I'm open to other suggestions. (how the hell does this work for devices attached at probe time? What vnet context do they have, and why doesn't the kernel panic there?) Adrian From owner-freebsd-net@FreeBSD.ORG Mon Oct 22 00:06:53 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AEC07F88; Mon, 22 Oct 2012 00:06:53 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 789B18FC12; Mon, 22 Oct 2012 00:06:53 +0000 (UTC) Received: from JRE-MBP-2.local (c-50-143-149-146.hsd1.ca.comcast.net [50.143.149.146]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q9M06kO8078826 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 21 Oct 2012 17:06:46 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <50848E16.6060008@freebsd.org> Date: Sun, 21 Oct 2012 17:06:46 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Andrey V. Elsukov" Subject: Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time References: <508138A4.5030901@FreeBSD.org> In-Reply-To: <508138A4.5030901@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfw@freebsd.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 00:06:54 -0000 On 10/19/12 4:25 AM, Andrey V. Elsukov wrote: > Hi All, > > Many years ago i have already proposed this feature, but at that time > several people were against, because as they said, it could affect > performance. Now, when we have high speed network adapters, SMP kernel > and network stack, several locks acquired in the path of each packet, > and i have an ability to test this in the lab. > > So, i prepared the patch, that removes IPFIREWALL_FORWARD option from > the kernel and makes this functionality always build-in, but it is > turned off by default and can be enabled via the sysctl(8) variable > net.pfil.forward=1. > > http://people.freebsd.org/~ae/pfil_forward.diff > > Also we have done some tests with the ixia traffic generator connected > via 10G network adapter. Tests have show that there is no visible > difference, and there is no visible performance degradation. > > Any objections? > The number of times I've been brought to a running production system and asked "can you do (mumble) to solve problem 'X' ?", and my answer has been "well we'll have to recompile a kernel to get IPFIREWALL_FORWARD, but then, yes" to be met by "oh but we can't shutdown until XXX days from now due to uptime constraints and rules." is more than I can remember. (mostly back in Vicor days) but in fact, right now I have a system where I want to do this but the original source tree it was built from has been lost so I need to actually rebuild the entire system just to get it. (It's an embedded system) so yes please! From owner-freebsd-net@FreeBSD.ORG Mon Oct 22 01:25:34 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD409B35; Mon, 22 Oct 2012 01:25:34 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.FreeBSD.org [8.8.178.135]) by mx1.freebsd.org (Postfix) with ESMTP id A90BE8FC12; Mon, 22 Oct 2012 01:25:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q9M1PYN1086083; Mon, 22 Oct 2012 01:25:34 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q9M1PYTp086079; Mon, 22 Oct 2012 01:25:34 GMT (envelope-from linimon) Date: Mon, 22 Oct 2012 01:25:34 GMT Message-Id: <201210220125.q9M1PYTp086079@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/172895: [ixgb] [ixgbe] do not properly determine link-state X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 01:25:35 -0000 Old Synopsis: [ixgb,ixgbe] does not properly determine link-state for New Synopsis: [ixgb] [ixgbe] do not properly determine link-state Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Oct 22 01:24:47 UTC 2012 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=172895 From owner-freebsd-net@FreeBSD.ORG Mon Oct 22 01:43:23 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 249FEAA; Mon, 22 Oct 2012 01:43:23 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id A1E428FC08; Mon, 22 Oct 2012 01:43:22 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id v11so3028257vbm.13 for ; Sun, 21 Oct 2012 18:43:16 -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=C+eyZQMxpvYFmk5OahjX+5c16pYXjfrFx8Hps5XoPwg=; b=YAOLtOvR7ruHcrzawglgN5oM7AbSch0i87In+Wn2KFbbp5Vy0jNAP+6DTeul2HNh0A et3OywT5q4WIGsYLzPN/GnSSHOUxXArAjUFO925d3vs846xdKvc6s8ynUwVqYdTbrY8m 6+IDMLBrMvK1s1dV6e0rYhl3o8UDGAaGZlrvEFerHPTn2Jenaea2WP3mgnL6R+XVMxvi WQApu32iMc8sy93siBzNGKDWIFrXyHgYnQiqjfm0pa0TQiti23/WOF8Z3JuMe33wnJME d0Noj7ThQ5V/a3Mh+Jx6vH1yBjjpH1bphUqRoT5i1eU2aa7A5BKbPlHlAFTbVX/QF7Oi A4kQ== MIME-Version: 1.0 Received: by 10.221.2.10 with SMTP id ns10mr12497322vcb.25.1350870196088; Sun, 21 Oct 2012 18:43:16 -0700 (PDT) Received: by 10.58.207.114 with HTTP; Sun, 21 Oct 2012 18:43:16 -0700 (PDT) In-Reply-To: <50843D39.5000003@FreeBSD.org> References: <5079A9A1.4070403@FreeBSD.org> <20121015162926.GV89655@FreeBSD.org> <507D4F11.2030704@FreeBSD.org> <20121016124733.GC89655@glebius.int.ru> <50843D39.5000003@FreeBSD.org> Date: Sun, 21 Oct 2012 21:43:16 -0400 Message-ID: Subject: Re: ixgbe & if_igb RX ring locking From: Ryan Stone To: "Alexander V. Chernikov" Content-Type: text/plain; charset=ISO-8859-1 Cc: Jack Vogel , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 01:43:23 -0000 On Sun, Oct 21, 2012 at 2:21 PM, Alexander V. Chernikov wrote: >> ix:rx -> udp is also fairly obvious (here's one backtrace): > The same question, where "udp" -> "ix:rx" can happen ? It can't happen directly as far as I can tell. But to trigger a deadlock, "all" that has to happen is that a thread holds each mutex in the cycle while trying to acquire the next mutex in the cycle. I realize that in this case that requires five separate threads to all lose a race simultaneously, but it's still theoretically possible and needs to be avoided. From owner-freebsd-net@FreeBSD.ORG Mon Oct 22 04:15:30 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40BC3FB8; Mon, 22 Oct 2012 04:15:30 +0000 (UTC) (envelope-from nevzorovn@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 84A258FC08; Mon, 22 Oct 2012 04:15:29 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so1710622lag.13 for ; Sun, 21 Oct 2012 21:15:28 -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 :content-type; bh=+EKS4TuKDBmEn0GE4bMGZDP9yD2r9raw5NpUi8Eb4UU=; b=oqIa3yw9UYQn8C0QOIgEfC4J5dBcFrSpMyXdmbeCfE9tw1+Bjc73uw3OakpdpgZqdE Cg5jVAj0/ZA0qlMzf/ah+7DT6v07XKl5VVB51wfh4pX96fNCSl0YTdakvgqJ25NkPDiO KBcj2hJouuXhvFIxcEgWIaHMmvHKMiCT2QLQA+y1ZhO7Kppr+yxJBnB6b/0N9NAQSu/8 hQ00DwJUu4t9Td2BU3EzuvzPYpEJPAmhbqZrRb/QjWa7ujZyOoOFDj6aCNop75UWuz2t hlLJYmCzkBL8VMTz/yWP0UPtlYZx+EZB6fGQ82tyjkbOZJ4850avJ7G799U7e6JZIiKL Zmxg== MIME-Version: 1.0 Received: by 10.152.114.100 with SMTP id jf4mr7061007lab.47.1350879328306; Sun, 21 Oct 2012 21:15:28 -0700 (PDT) Received: by 10.112.42.70 with HTTP; Sun, 21 Oct 2012 21:15:28 -0700 (PDT) In-Reply-To: <5084C51E.7080300@rdtc.ru> References: <201210180141.q9I1f53s052539@freefall.freebsd.org> <50830F8B.4030204@rdtc.ru> <5083D79C.4010309@rdtc.ru> <5084C51E.7080300@rdtc.ru> Date: Mon, 22 Oct 2012 10:15:28 +0600 Message-ID: Subject: Re: kern/171520: [alc] alc network driver + tso + vlan does not work. From: Nikolay Nevzorov To: Eugene Grosbein , yongari@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 04:15:30 -0000 2012/10/22 Eugene Grosbein > 22.10.2012 10:55, Nikolay Nevzorov =D0=C9=DB=C5=D4: > > I can make clean test. > > > > What do you mean by clean: > > reboot with disable mpd (and so will be not enabled kernel NAT in > system) or remove LIBALIAS from kernel too? > > You need not reboot or disable mpd. Just make sure your testing traffic > does not pass through NAT. > > > Any traffic throuhg NAT does not cause problems. And any routed traffic s= o on. Problem only with traffic that generated on host with alc0, because host generate packets much more bigger than MTU (about 2300 bytes per packet with MTU 1500), a see it with tcpdump on alc0. From owner-freebsd-net@FreeBSD.ORG Mon Oct 22 04:15:37 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 87C69FBE; Mon, 22 Oct 2012 04:15:37 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id D50488FC16; Mon, 22 Oct 2012 04:15:36 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q9M4FXYu035670; Mon, 22 Oct 2012 11:15:33 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <5084C860.5060107@rdtc.ru> Date: Mon, 22 Oct 2012 11:15:28 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Nikolay Nevzorov Subject: Re: kern/171520: [alc] alc network driver + tso + vlan does not work. References: <201210180141.q9I1f53s052539@freefall.freebsd.org> <50830F8B.4030204@rdtc.ru> <5083D79C.4010309@rdtc.ru> <5084C51E.7080300@rdtc.ru> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: "net@freebsd.org" , bug-followup@freebsd.org, yongari@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 04:15:37 -0000 22.10.2012 11:09, Nikolay Nevzorov ÐÉÛÅÔ: > Any traffic throuhg NAT does not cause problems. And any routed traffic so on. > > Problem only with traffic that generated on host with alc0, because host generate packets much more bigger than MTU (about 2300 bytes per packet with MTU 1500), a see it with tcpdump on alc0. Perhaps, that's another problem then. Just to make in really clean, try kernel without LIBALIAS and do not start mpd during the test as it may load libalias.ko by itself. From owner-freebsd-net@FreeBSD.ORG Mon Oct 22 04:38:11 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78AC55EB; Mon, 22 Oct 2012 04:38:11 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3721C8FC0C; Mon, 22 Oct 2012 04:38:11 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so1741001pbb.13 for ; Sun, 21 Oct 2012 21:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=Gjq+7FoxBYrgFCdnhB9raSKGYmW7A6iuX8LbWqHaum0=; b=TtEG78/aZivR//Fbv4VPbPeb05xnvCT54DnCtWmiwxiw6vrL5pBLqMZSfDTpGsNwSF BnoWmlAAYEFTAqV1YOTso6ibiU15dRZw2BQnZGDDEJHJYkHFBdZc27FGEtF+kQq3PqMV 84FOwWHN1RyaQYMmWhSkXWeowSEoYRQRBk4B2l/OO65OWl4ErLAbgLB2zlMPiy+bC21F F6q31ZkwV87YNyZKq8xV+ZgfBZxcuAmspRuwnIGX0PE7JrtD3mzxc9g5QhmOTUWUuQZR iy2BSxEyc0V0UnM7ktZ8AAh9qveW3b9aDf8wTR3HL8mZYoW19YW5tGg1HRUZcpwwlzcA Px/w== Received: by 10.66.77.40 with SMTP id p8mr22789083paw.78.1350880690692; Sun, 21 Oct 2012 21:38:10 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id ms11sm5290366pbc.74.2012.10.21.21.38.07 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 21 Oct 2012 21:38:10 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 22 Oct 2012 13:38:04 -0700 From: YongHyeon PYUN Date: Mon, 22 Oct 2012 13:38:04 -0700 To: Nikolay Nevzorov Subject: Re: kern/171520: [alc] alc network driver + tso + vlan does not work. Message-ID: <20121022203804.GA1523@michelle.cdnetworks.com> References: <201210180141.q9I1f53s052539@freefall.freebsd.org> <50830F8B.4030204@rdtc.ru> <5083D79C.4010309@rdtc.ru> <5084C51E.7080300@rdtc.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, Eugene Grosbein , yongari@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 04:38:11 -0000 On Mon, Oct 22, 2012 at 10:15:28AM +0600, Nikolay Nevzorov wrote: > 2012/10/22 Eugene Grosbein > > > 22.10.2012 10:55, Nikolay Nevzorov пишет: > > > I can make clean test. > > > > > > What do you mean by clean: > > > reboot with disable mpd (and so will be not enabled kernel NAT in > > system) or remove LIBALIAS from kernel too? > > > > You need not reboot or disable mpd. Just make sure your testing traffic > > does not pass through NAT. > > > > > > Any traffic throuhg NAT does not cause problems. And any routed traffic so > on. > > Problem only with traffic that generated on host with alc0, because host > generate packets much more bigger than MTU (about 2300 bytes per packet > with MTU 1500), a see it with tcpdump on alc0. It's completely normal to see bigger MTU sized packets on TSO-capable controllers. bpf sees these packets *before* hardware actually segments these packets. From owner-freebsd-net@FreeBSD.ORG Mon Oct 22 10:08:45 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 865C7872; Mon, 22 Oct 2012 10:08:45 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.zvne.fer.hr (mail.zvne.fer.hr [161.53.66.5]) by mx1.freebsd.org (Postfix) with ESMTP id 085C58FC1D; Mon, 22 Oct 2012 10:08:44 +0000 (UTC) Received: from munja.zvne.fer.hr (161.53.66.248) by mail.zvne.fer.hr (161.53.66.5) with Microsoft SMTP Server id 14.2.298.4; Mon, 22 Oct 2012 12:08:42 +0200 Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Oct 2012 12:08:42 +0200 Received: from localhost ([161.53.19.8]) by sluga.fer.hr over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Oct 2012 12:08:41 +0200 From: Marko Zec To: Adrian Chadd Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices Date: Mon, 22 Oct 2012 12:08:37 +0200 User-Agent: KMail/1.9.10 References: <201210212322.48791.zec@fer.hr> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <201210221208.37592.zec@fer.hr> X-OriginalArrivalTime: 22 Oct 2012 10:08:41.0884 (UTC) FILETIME=[3694FDC0:01CDB03D] Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 10:08:45 -0000 On Monday 22 October 2012 01:03:19 Adrian Chadd wrote: ... > > Obviously, handling device attach events is an exception from this > > rule, and up to this date this was never properly addressed... > > *laugh*. > > The problem now is figuring out how to do it without modifying all the > drivers. > > The attach is easy - I can likely set it up during the device_attach() > pass. I can do that, but it's enforcing "networking-ness" with the > device attach, which will be called for networking and non-networking > devices alike. > > However detach isn't easy - because I'm required to call > CURVNET_SET(ifp->if_vnet) and CURVNET_RESTORE() around if_free(), and > if_free() is called in the device specific detach() routine, I can't > easily set the current VNET context from outside the driver. > > I _guess_ I could device_attach() to use CURVNET_SET(vnet0) but > device_detach() can't do the same - it doesn't "know" about the > networking-ness of the device. > > I'm open to other suggestions. The only option I can think of now is to update all of the hotunpluggable device_detach() handlers to do CURVNET_SET(ifp->if_vnet) before calling further down into the networking stack, because as you already observed, whatever triggers a device_detach() handler is not aware of the nature of the driver. > (how the hell does this work for devices attached at probe time? What > vnet context do they have, and why doesn't the kernel panic there?) Because at boot / autoconfiguration time curvnet is implicitly set to vnet0 between SI_SUB_VNET and SI_SUB_VNET_DONE (i.e. before going SMP). Similarly, curvnet is set to vnet0 during kldload events. Marko From owner-freebsd-net@FreeBSD.ORG Mon Oct 22 11:06:38 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 52960259 for ; Mon, 22 Oct 2012 11:06:38 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.FreeBSD.org [8.8.178.135]) by mx1.freebsd.org (Postfix) with ESMTP id 385698FC1B for ; Mon, 22 Oct 2012 11:06:38 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q9MB6ciJ044488 for ; Mon, 22 Oct 2012 11:06:38 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q9MB6b7U044486 for freebsd-net@FreeBSD.org; Mon, 22 Oct 2012 11:06:37 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 22 Oct 2012 11:06:37 GMT Message-Id: <201210221106.q9MB6b7U044486@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 11:06:38 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172364 net [cxbge] cxbge_vlan_config() Fatal trap 12: page fault o kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171838 net [oce] [patch] Possible lock reversal and duplicate loc o kern/171739 net [bce] [panic] bce related kernel panic o kern/171728 net [arp] arp issue o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171697 net [ip6] [ndp] panic when changing routes o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net [tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel p kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 424 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Oct 22 14:12:58 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 57FC2E7C; Mon, 22 Oct 2012 14:12:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 063558FC14; Mon, 22 Oct 2012 14:12:57 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id wc20so3290930obb.13 for ; Mon, 22 Oct 2012 07:12:57 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=67VTMkU+JlSCEgDpiB3cOxrzm5fnUFdT+yPtDiIMd9U=; b=ORw5bAAjR9UDGrpbE2k+zuzSz33FBWtUb3vJUUIDSpRIMBZCeo2VupiFYpMxybDlO8 SlhJfZdJsQSL8hcqjIrEI+SJClt7xvPJ6/2Ul/Mta/k3GpMG/bJ8IdlItOg5Nl9Je0AC 9XJgivnUvlxA5ToP/TUfUe9PHbvCPklMOVthAyI9t6mqCvE/rn9W9U6ETkNOd/xydYmz D6eg+SlQL7VKRIPEdcs/e5LDBJCF2NmYkI8+PSqhMDkedukDFqd5Xg68Z4nVA/5JPfZX rBY55JF0bwZp3VyfDK2EQiLols++EnqxIeZLeJDOfUgYt3yDVago1BfXaZnBOvsr797r BxlQ== MIME-Version: 1.0 Received: by 10.182.154.70 with SMTP id vm6mr7292629obb.50.1350915177132; Mon, 22 Oct 2012 07:12:57 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.76.75.69 with HTTP; Mon, 22 Oct 2012 07:12:57 -0700 (PDT) In-Reply-To: <201210221208.37592.zec@fer.hr> References: <201210212322.48791.zec@fer.hr> <201210221208.37592.zec@fer.hr> Date: Mon, 22 Oct 2012 07:12:57 -0700 X-Google-Sender-Auth: ixxynEG1VCVa90_2bXmj7Yd0OpA Message-ID: Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices From: Adrian Chadd To: Marko Zec Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 14:12:58 -0000 On 22 October 2012 03:08, Marko Zec wrote: > The only option I can think of now is to update all of the hotunpluggable > device_detach() handlers to do CURVNET_SET(ifp->if_vnet) before calling > further down into the networking stack, because as you already observed, > whatever triggers a device_detach() handler is not aware of the nature of > the driver. Right. Well, since most things are in theory hotpluggable these days (or soon will be, with pcie hotplug), I think we need a slightly more generic solution. >> (how the hell does this work for devices attached at probe time? What >> vnet context do they have, and why doesn't the kernel panic there?) > > Because at boot / autoconfiguration time curvnet is implicitly set to vnet0 > between SI_SUB_VNET and SI_SUB_VNET_DONE (i.e. before going SMP). > > Similarly, curvnet is set to vnet0 during kldload events. .. like this. The trouble is going to be handling unplug and kldunload events too. Does curvnet -> vnet0 during kldunload events? Thanks, Adrian From owner-freebsd-net@FreeBSD.ORG Mon Oct 22 16:20:38 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 54D794D1; Mon, 22 Oct 2012 16:20:38 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) by mx1.freebsd.org (Postfix) with ESMTP id 1337B8FC08; Mon, 22 Oct 2012 16:20:36 +0000 (UTC) X-Loopcount0: from 64.238.244.148 X-IronPort-AV: E=Sophos;i="4.80,630,1344229200"; d="scan'208";a="6571789" Message-ID: <50857210.3090200@vangyzen.net> Date: Mon, 22 Oct 2012 11:19:28 -0500 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120822 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org, "Bjoern A. Zeeb" Subject: [patch] Review: Fix Tahi "Redirected On-link" Test Case Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:20:38 -0000 Bjoern and net@: I would appreciate your review and comments on the following patches. http://vangyzen.net/FreeBSD/patches/redir_onlink_8_rev1.diff http://vangyzen.net/FreeBSD/patches/redir_onlink_9_rev1.diff http://vangyzen.net/FreeBSD/patches/redir_onlink_10_rev1.diff Thanks in advance, Eric ==== Fix the Redirected On-Link test cases in the Tahi IPv6 Ready Logo Phase 2 test suite. On receipt of a redirect message, install an interface route for the redirected destination. On removal of the corresponding Neighbor Cache entry, remove the interface route. This requires changes in rtredirect_fib() to cope with an AF_LINK address for the gateway and with the absence of RTF_GATEWAY. Unrelated to the above, fix a recursion on the radix node head lock triggered by the Redirected to Alternate Router test cases. All Section 2 (Neighbor Discovery) test cases pass on 10-CURRENT and 9-STABLE. (8-STABLE pending) Other test cases: * the RTF_MODIFIED case, with IPv4 and IPv6 (using a RTF_HOST|RTF_GATEWAY route for the destination) * the redirected-to-self case, with IPv4 and IPv6 * a valid IPv4 redirect All testing was done with WITNESS and INVARIANTS. Submitted by: Eric van Gyzen , Mark Kelley , Terence Telkamp Sponsored by: Dell, Inc. PR: kern/152791 From owner-freebsd-net@FreeBSD.ORG Mon Oct 22 17:29:39 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 93130107; Mon, 22 Oct 2012 17:29:39 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 5AADB8FC08; Mon, 22 Oct 2012 17:29:39 +0000 (UTC) Received: from JRE-MBP-2.local (c-50-143-149-146.hsd1.ca.comcast.net [50.143.149.146]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q9MHTXVA083302 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 10:29:34 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5085827D.5090108@freebsd.org> Date: Mon, 22 Oct 2012 10:29:33 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices References: <201210212322.48791.zec@fer.hr> <201210221208.37592.zec@fer.hr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Marko Zec , freebsd-hackers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:29:39 -0000 On 10/22/12 7:12 AM, Adrian Chadd wrote: > On 22 October 2012 03:08, Marko Zec wrote: > >> The only option I can think of now is to update all of the hotunpluggable >> device_detach() handlers to do CURVNET_SET(ifp->if_vnet) before calling >> further down into the networking stack, because as you already observed, >> whatever triggers a device_detach() handler is not aware of the nature of >> the driver. > Right. Well, since most things are in theory hotpluggable these days > (or soon will be, with pcie hotplug), I think we need a slightly more > generic solution. > >>> (how the hell does this work for devices attached at probe time? What >>> vnet context do they have, and why doesn't the kernel panic there?) >> Because at boot / autoconfiguration time curvnet is implicitly set to vnet0 >> between SI_SUB_VNET and SI_SUB_VNET_DONE (i.e. before going SMP). >> >> Similarly, curvnet is set to vnet0 during kldload events. > .. like this. > > The trouble is going to be handling unplug and kldunload events too. > Does curvnet -> vnet0 during kldunload events? I think in unload events we probably need to cycle through all vnets and do individual shutdowns of anything that is set up on that vnet.. (but I'm not reading the code to say that, it's possible to ignore me safely) > > Thanks, > > > > Adrian > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Oct 22 17:41:20 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6D80487A; Mon, 22 Oct 2012 17:41:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 086698FC0C; Mon, 22 Oct 2012 17:41:19 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so3626754oag.13 for ; Mon, 22 Oct 2012 10:41:19 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=cfIItJ/N69fEvzDLxn4N+v9HjU/1GScc0Ez1YHu22kk=; b=iSaLGO3jM34KUQZlYezf5nIzNybEWoo497/Ybk3/nDdL+fnFBiBQcj8AZ6l5xr593f 3/dt1xQwV5SFM6yk83Nn/8dLWBtPDST/Bse4Wm6mN5wp21hrF+nZP5YAEmVYcKvunpPw PlQI6aEj47eLtKUv6uWTA5kWwLRm3c6SLcUlLI4/OwNbKld3bRAmjjngOxj47SyjU7SO ngJ0KYYRKA7UTrf0lzLXcXFCxBl7RCW3Rq4uoNqNbDSAXY2V18Cv2ax0s/K1GhgNQfXR +Q74GNCOUlMPUNYjMqLcIVaFWQlwU6uRyLR02agaC1QcTvdYsOQk4FS3ziKjsYGnHtgi yD1Q== MIME-Version: 1.0 Received: by 10.60.170.200 with SMTP id ao8mr8680174oec.104.1350927679450; Mon, 22 Oct 2012 10:41:19 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.76.75.69 with HTTP; Mon, 22 Oct 2012 10:41:19 -0700 (PDT) In-Reply-To: <5085827D.5090108@freebsd.org> References: <201210212322.48791.zec@fer.hr> <201210221208.37592.zec@fer.hr> <5085827D.5090108@freebsd.org> Date: Mon, 22 Oct 2012 10:41:19 -0700 X-Google-Sender-Auth: -l9gehXv5QIFVzihQPoVc-FjOMI Message-ID: Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices From: Adrian Chadd To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Marko Zec , freebsd-hackers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:41:20 -0000 On 22 October 2012 10:29, Julian Elischer wrote: >> The trouble is going to be handling unplug and kldunload events too. >> Does curvnet -> vnet0 during kldunload events? > > I think in unload events we probably need to cycle through all vnets and > do individual shutdowns of anything that is set up on that vnet.. > (but I'm not reading the code to say that, it's possible to ignore me > safely) Well, in an unload event you know the device you're unloading. However, there may be clones and such involved. It's not like a kldunload will kill a specific VAP on an ath(4) interface, it'll kill the whole interface with all vaps. So in net80211 I need to teach the VAP setup/destroy path to use CURVNET_*() correctly. That's a given. I still however need to ensure that CURVNET_SET(vnet0)/CURVNET_RESTORE() is used around the device attach/detach, as right now the hotplug code doesn't do this. So Marko: * Given that you've "fixed" the kldload path and bootup path to set CURVNET_SET(vnet0) as a special case, how about we teach the device_attach() path to just do this in general? * How does kldunload work right now if any devices are in a vnet? If I kldunload if_bridge with vnets everywhere, what happens? if_bridge doesn't at all know anything about VIMAGE. How do the cloned interfaces get correctly destroyed? I don't want to have to teach _every network device_ that they need to be vnet aware on attach or detach. * the device probe/attach path should just use vnet0; and * the device detach/destroy path, to things like if_free(), should have those functions just use ifp->if_vnet, rather than assuming CURVNET_SET() was called. I know you wanted to be warned if parts of the stack weren't correctly using CURVNET_SET()/CURVNET_RESTORE(), but I think this battle is already lost. :/ Adrian From owner-freebsd-net@FreeBSD.ORG Mon Oct 22 18:18:38 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6C218419 for ; Mon, 22 Oct 2012 18:18:38 +0000 (UTC) (envelope-from s.khanchi@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 290608FC08 for ; Mon, 22 Oct 2012 18:18:37 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id k10so5471377iea.13 for ; Mon, 22 Oct 2012 11:18:37 -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:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=pM1bQ+1oirf9udNvcy5AInbFe1HgQ5g9+0uqjjhhnFE=; b=LVIlBoxjsc6k0ZwHNvANCGavr+iypspWFdmU7g/G0UVmbVaUVRdhKY/UL5Ig19Km/K iQmbkGMKV3i6ESpz03rCRmMUWPNfP3cTLKBMYtDYFzWCJMBBWjeJj2a0AKT5VckPlPJ3 xwonrw10KoX11Q2z+rwwEiunYo9bMOSvSbv4CzieWcKnubVExShRHTdvytjTJXYKFgBb ivmG6BrRNiTxuvn+7qmaNgM/8RjEqlsnsFCBB0N74gIWJXDN3Tk0CHUZdba+uxz8BQTq Wg5KxE7aij5l8oTR3O13SiwZbpNf1n1rOnlxxW+5n6lN3QMaKXKiBmv9CMLBVWSGrRVR jcPA== Received: by 10.50.94.198 with SMTP id de6mr10047755igb.49.1350929917270; Mon, 22 Oct 2012 11:18:37 -0700 (PDT) MIME-Version: 1.0 Sender: s.khanchi@gmail.com Received: by 10.64.51.234 with HTTP; Mon, 22 Oct 2012 11:18:17 -0700 (PDT) In-Reply-To: <5080039E.9070202@networx.ch> References: <5080039E.9070202@networx.ch> From: h bagade Date: Mon, 22 Oct 2012 21:48:17 +0330 X-Google-Sender-Auth: GAOZxRl-RXXxUnlmHlNlTe0GEog Message-ID: Subject: Re: TCP_DROP_SYNFIN kernel option side effects?! To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 18:18:38 -0000 Thanks Andre for your answer:) On Thu, Oct 18, 2012 at 4:56 PM, Andre Oppermann wrote: > On 16.10.2012 17:27, h bagade wrote: > >> Hi all, >> >> I need to add this option to kernel in order to defeating Nmap >> OS-Fingerprinting. My system is running as Web Server and also it is the >> gateway on the network. >> I want to know if setting this option has any side effects on other parts >> of the system? Is there any situation that SYN and FIN bits are set both >> in >> TCP packets? Is it a normal situation? >> > > SYN and FIN is not normal. Doing TCP_DROP_SYNFIN is not RFC compliant > but doesn't cause any problems. > > -- > Andre > > From owner-freebsd-net@FreeBSD.ORG Mon Oct 22 21:17:14 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C273B3B2; Mon, 22 Oct 2012 21:17:14 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.zvne.fer.hr (mail.zvne.fer.hr [161.53.66.5]) by mx1.freebsd.org (Postfix) with ESMTP id 156B68FC0A; Mon, 22 Oct 2012 21:17:13 +0000 (UTC) Received: from munja.zvne.fer.hr (161.53.66.248) by mail.zvne.fer.hr (161.53.66.5) with Microsoft SMTP Server id 14.2.298.4; Mon, 22 Oct 2012 23:17:05 +0200 Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Oct 2012 23:17:05 +0200 Received: from localhost ([161.53.19.8]) by sluga.fer.hr over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Oct 2012 23:17:04 +0200 From: Marko Zec To: Adrian Chadd Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices Date: Mon, 22 Oct 2012 23:17:00 +0200 User-Agent: KMail/1.9.10 References: <5085827D.5090108@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <201210222317.00457.zec@fer.hr> X-OriginalArrivalTime: 22 Oct 2012 21:17:05.0213 (UTC) FILETIME=[96075ED0:01CDB09A] Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 21:17:14 -0000 On Monday 22 October 2012 19:41:19 Adrian Chadd wrote: > On 22 October 2012 10:29, Julian Elischer wrote: > >> The trouble is going to be handling unplug and kldunload events too. > >> Does curvnet -> vnet0 during kldunload events? > > > > I think in unload events we probably need to cycle through all vnets > > and do individual shutdowns of anything that is set up on that vnet.. > > (but I'm not reading the code to say that, it's possible to ignore me > > safely) > > Well, in an unload event you know the device you're unloading. > However, there may be clones and such involved. It's not like a > kldunload will kill a specific VAP on an ath(4) interface, it'll kill > the whole interface with all vaps. > > So in net80211 I need to teach the VAP setup/destroy path to use > CURVNET_*() correctly. That's a given. > > I still however need to ensure that > CURVNET_SET(vnet0)/CURVNET_RESTORE() is used around the device > attach/detach, as right now the hotplug code doesn't do this. > > So Marko: > > * Given that you've "fixed" the kldload path and bootup path to set > CURVNET_SET(vnet0) as a special case, how about we teach the > device_attach() path to just do this in general? While it's true that the kldunload path (most probably) does CURVNET_SET(vnet0), this is obviously just a kludge which works on pure luck, i.e. only when ifnets to be detached live inside vnet0. > * How does kldunload work right now if any devices are in a vnet? It (most probably) doesn't. > If I > kldunload if_bridge with vnets everywhere, what happens? if_bridge > doesn't at all know anything about VIMAGE. How do the cloned > interfaces get correctly destroyed? Haven't tried this out recently, really, though bz@ maintained a patch for a while which specifically targetted VNET issues with cloner ifnets, but I don't know the current status of that work... > I don't want to have to teach _every network device_ that they need to > be vnet aware on attach or detach. > > * the device probe/attach path should just use vnet0; and Right. > * the device detach/destroy path, to things like if_free(), should > have those functions just use ifp->if_vnet, rather than assuming > CURVNET_SET() was called. How many functions like if_free() are we talking about here? If only a few would need to be extended to do a CURVNET_SET(ifp->if_vnet), that doesn't sound like too big an issue, though I'm not completely convinced that such an approach could guarantee that every driver would survive hotunplugging with vnets. Still, that would be an improvement over what we have right now. > I know you wanted to be warned if parts of the stack weren't correctly > using CURVNET_SET()/CURVNET_RESTORE(), but I think this battle is > already lost. :/ It is absolutely critical that, at minimum, we always completely unwind the VNET stack when exiting the networking code, otherwise we risk to continue running with a fully random implicit curvnet context. As many of the networking subsystems or code paths are still not VNET-friendly, entering any of those on a VIMAGE kernel should lead to panics, not to obscure and silent inter-vnet leakages which may become a nightmare to nail down. OTOH, avoiding excessive recursions on curvnet remains an effort similar to our style(9) - if you don't stick to it to the letter, things will still work, but some code paths may become more difficult to debug when things go wrong... Plus, keep in mind that every CURVNET_SET() consumes a few CPU cycles here and there, and requires a few extra bytes on the stack... Marko From owner-freebsd-net@FreeBSD.ORG Mon Oct 22 21:43:12 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F6D6F3; Mon, 22 Oct 2012 21:43:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4165A8FC1E; Mon, 22 Oct 2012 21:43:11 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so2402873pbb.13 for ; Mon, 22 Oct 2012 14:43:11 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=s4yY5Y5HEPFTOU/+X8vYT+lyVqOEj1PZ/W46fdeBZYM=; b=VsmU/fWuMSPnGum+7DiB2NLvrh15t1eiZNlxTZlBhtnnC0CIIOZVzjtK0hle0MkBdD bNR4+3IMTtMfY83AdFSUQ4dwWqv8HcJg/sXnzGdr62rpsrDw9r4736OHuYv9f1ui6gvd VEbZ1GfUOhCnuIKSORa1C2yGlD+lCyx+jOlqLFDfu9hI4EFH0jaPptJfUPpoYTwlXUId qSf4ShrOt7z4T7OiTzKatm1NB5oVY5jyo/51YNRiguTEmuZN1qYIS3HLrfSc0f00/5Rc Yf0Bds+IP+C8CtxPiKrpolDIlMWOye2xAWYR52tQT/CnP5GT7f4CurTrZ6N3KmJZTYZE aTig== MIME-Version: 1.0 Received: by 10.66.80.133 with SMTP id r5mr29658954pax.24.1350942191776; Mon, 22 Oct 2012 14:43:11 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.146.233 with HTTP; Mon, 22 Oct 2012 14:43:11 -0700 (PDT) In-Reply-To: <201210222317.00457.zec@fer.hr> References: <5085827D.5090108@freebsd.org> <201210222317.00457.zec@fer.hr> Date: Mon, 22 Oct 2012 14:43:11 -0700 X-Google-Sender-Auth: 4NJ6mWnKmAtqU93tCntqSYS6YuY Message-ID: Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices From: Adrian Chadd To: Marko Zec Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 21:43:12 -0000 Hi, I don't mind tackling the net80211 clone detach path. I do mind how the default for hotplug is "argh, it doesn't work." :-) So I'd like to come up with something to fix the basic device detach, rather than having to actually add CURVNET_*() calls around each if_free() in each device detach method. Adrian From owner-freebsd-net@FreeBSD.ORG Tue Oct 23 01:20:01 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 97C8F5C7 for ; Tue, 23 Oct 2012 01:20:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.FreeBSD.org [8.8.178.135]) by mx1.freebsd.org (Postfix) with ESMTP id 807F38FC0A for ; Tue, 23 Oct 2012 01:20:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q9N1K1fW021966 for ; Tue, 23 Oct 2012 01:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q9N1K1vL021965; Tue, 23 Oct 2012 01:20:01 GMT (envelope-from gnats) Date: Tue, 23 Oct 2012 01:20:01 GMT Message-Id: <201210230120.q9N1K1vL021965@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Ryan Steinmetz Subject: Re: kern/156226: Lagg failover does not announce the failover to switch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Ryan Steinmetz List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 01:20:01 -0000 The following reply was made to PR kern/156226; it has been noted by GNATS. From: Ryan Steinmetz To: Per von Zweigbergk Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/156226: Lagg failover does not announce the failover to switch Date: Mon, 22 Oct 2012 21:12:40 -0400 This isn't a solution, but is a workaround that I've been using for a bit: http://people.freebsd.org/~zi/ping You can drop the file in /usr/local/etc/rc.d and then add ping_enable="YES" to /etc/rc.conf Basically, it sends an icmp echo request to your default gateway every 5 seconds by default, which forces the switch to update its FIB. This means that after a maximum of 5 seconds after lagg completes an interface failover, you should regain network connectivity. -r From owner-freebsd-net@FreeBSD.ORG Tue Oct 23 07:13:28 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F66FC53; Tue, 23 Oct 2012 07:13:28 +0000 (UTC) (envelope-from nino80@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id CD0FD8FC14; Tue, 23 Oct 2012 07:13:27 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id k10so6459298iea.13 for ; Tue, 23 Oct 2012 00:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rGNhiXzsOUch7jy9gw76WcJxqI+1yPdt/XTvjRUMIno=; b=hsGQOzSbgt4DPZKlZgbm1PRpwHkFaWGXx/Bfxc2FHKPR5u5hjZ47bGCum5j8Nn0NlE SlQnXIaaE1r7K0x0NcjLg3CjlSTYutuHyutzvaj1BCxKJHrC+HbNdCRH2fNs+3pIb4T/ KKkRHGZV3hQ3mUpnXEQB1lSR47MxOHdDGnILWTgJzTB6F/O/fA8xilnP49R7VVwnh6Pd M7hfxj0HjLT9BI9rElBWntDjZY6s6WT9U87LvMdGZMzWb6RkuAhtKoznILkf3MjHrWYz ZUfUkJK35FVbrPGUsyQVIwRi3P6X88fgPfuh2dVjr9uDXzNZnoK7C2UDCTc/rzMFLO2X 6i7A== Received: by 10.50.37.168 with SMTP id z8mr19163504igj.1.1350976407279; Tue, 23 Oct 2012 00:13:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.113.65 with HTTP; Tue, 23 Oct 2012 00:13:07 -0700 (PDT) In-Reply-To: <50848E16.6060008@freebsd.org> References: <508138A4.5030901@FreeBSD.org> <50848E16.6060008@freebsd.org> From: n j Date: Tue, 23 Oct 2012 09:13:07 +0200 Message-ID: Subject: Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time To: ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 07:13:28 -0000 > On 10/19/12 4:25 AM, Andrey V. Elsukov wrote: >> >> Hi All, >> >> Many years ago i have already proposed this feature, but at that time >> several people were against, because as they said, it could affect >> performance. Now, when we have high speed network adapters, SMP kernel >> and network stack, several locks acquired in the path of each packet, >> and i have an ability to test this in the lab. >> >> So, i prepared the patch, that removes IPFIREWALL_FORWARD option from >> the kernel and makes this functionality always build-in, but it is >> turned off by default and can be enabled via the sysctl(8) variable >> net.pfil.forward=1. >> >> http://people.freebsd.org/~ae/pfil_forward.diff >> >> Also we have done some tests with the ixia traffic generator connected >> via 10G network adapter. Tests have show that there is no visible >> difference, and there is no visible performance degradation. >> >> Any objections? Just another me-too mail - this is great news! I can't really comment on the quality of the patch or the performance results as I'm neither an expert in low-level coding nor do I have a test lab to give this patch a go, but if there are no concrete objections, I really hope this goes forward. Thanks for the good work. Regards, -- Nino From owner-freebsd-net@FreeBSD.ORG Tue Oct 23 07:17:20 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1EA18D4C; Tue, 23 Oct 2012 07:17:20 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.zvne.fer.hr (mail.zvne.fer.hr [161.53.66.5]) by mx1.freebsd.org (Postfix) with ESMTP id 8ECCF8FC08; Tue, 23 Oct 2012 07:17:19 +0000 (UTC) Received: from munja.zvne.fer.hr (161.53.66.248) by mail.zvne.fer.hr (161.53.66.5) with Microsoft SMTP Server id 14.2.298.4; Tue, 23 Oct 2012 09:17:17 +0200 Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Oct 2012 09:17:16 +0200 Received: from localhost ([161.53.19.8]) by sluga.fer.hr over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Oct 2012 09:17:16 +0200 From: Marko Zec To: Adrian Chadd Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices Date: Tue, 23 Oct 2012 09:16:11 +0200 User-Agent: KMail/1.9.10 References: <201210222317.00457.zec@fer.hr> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <201210230916.11513.zec@fer.hr> X-OriginalArrivalTime: 23 Oct 2012 07:17:16.0521 (UTC) FILETIME=[6E70E590:01CDB0EE] Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 07:17:20 -0000 On Monday 22 October 2012 23:43:11 Adrian Chadd wrote: > Hi, > > I don't mind tackling the net80211 clone detach path. > > I do mind how the default for hotplug is "argh, it doesn't work." :-) > > So I'd like to come up with something to fix the basic device detach, > rather than having to actually add CURVNET_*() calls around each > if_free() in each device detach method. As already mentioned earlier, I don't terribly object if you'd place CURVNET_SET(ifp->if_vnet) inside if_free() and a limited number of similar functions, but I don't quite believe this is will enough to solve the device_detach() issue without having to touch any of the drivers... Marko From owner-freebsd-net@FreeBSD.ORG Tue Oct 23 08:40:01 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E0155A5 for ; Tue, 23 Oct 2012 08:40:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.FreeBSD.org [8.8.178.135]) by mx1.freebsd.org (Postfix) with ESMTP id 455138FC14 for ; Tue, 23 Oct 2012 08:40:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q9N8e041066539 for ; Tue, 23 Oct 2012 08:40:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q9N8e038066538; Tue, 23 Oct 2012 08:40:00 GMT (envelope-from gnats) Date: Tue, 23 Oct 2012 08:40:00 GMT Message-Id: <201210230840.q9N8e038066538@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Andrey Simonenko Subject: kern/92880: [libc] [patch] almost rewritten inet_network(3) function X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Andrey Simonenko List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 08:40:01 -0000 The following reply was made to PR kern/92880; it has been noted by GNATS. From: Andrey Simonenko To: bug-followup@FreeBSD.org Cc: Subject: kern/92880: [libc] [patch] almost rewritten inet_network(3) function Date: Tue, 23 Oct 2012 11:36:04 +0300 I optimized inet_network() again. Difference between implementation of inet_network(3) from 9.1-PRERELEASE and my implementation. STRING INET_NETWORK INET_NETWORK_NEW "0x12" 0x00000012 0x00000012 "127.1" 0x00007f01 0x00007f01 "127.1.2.3" 0x7f010203 0x7f010203 "0x123456" INADDR_NONE INADDR_NONE "0x12.0x34" 0x00001234 0x00001234 "0x12.0x345" INADDR_NONE INADDR_NONE "1.2.3.4.5" INADDR_NONE INADDR_NONE "1..3.4" INADDR_NONE INADDR_NONE "." INADDR_NONE INADDR_NONE "1." INADDR_NONE INADDR_NONE ".1" INADDR_NONE INADDR_NONE "0x" 0x00000000 INADDR_NONE <--- "0" 0x00000000 0x00000000 "01.02.07.077" 0x0102073f 0x0102073f "0x1.23.045.0" 0x01172500 0x01172500 "" INADDR_NONE INADDR_NONE " " INADDR_NONE INADDR_NONE " f" INADDR_NONE INADDR_NONE "bar" INADDR_NONE INADDR_NONE "1.2bar" INADDR_NONE INADDR_NONE "1." INADDR_NONE INADDR_NONE "=CA=C3=D5=CB=C5=CE" INADDR_NONE INADDR_NONE "255.255.255.255" INADDR_NONE INADDR_NONE "x" INADDR_NONE INADDR_NONE "0X12" 0x00000012 0x00000012 "078" INADDR_NONE INADDR_NONE "1 bar" 0x00000001 INADDR_NONE <--- "127.0xabcd" INADDR_NONE INADDR_NONE "128" 0x00000080 0x00000080 "0.1.2" 0x00000102 0x00000102 "0xff.010.23.0xa0" 0xff0817a0 0xff0817a0 "x10" 0x00000010 INADDR_NONE <--- "X20" 0x00000020 INADDR_NONE <--- "x10.x20" 0x00001020 INADDR_NONE <--- "4294967297" 0x00000001 INADDR_NONE <--- "0x10000000f" 0x0000000f INADDR_NONE <--- "040000000003" 0x00000003 INADDR_NONE <--- #include #include #include #include #include #include #include #include #include #include static in_addr_t inet_network_new(const char *s) { u_int d, base, dots; in_addr_t addr, byte; u_char c; bool flag; addr =3D 0; dots =3D 0; for (;; ++s) { byte =3D 0; flag =3D false; if (*s =3D=3D '0') { ++s; if (*s =3D=3D 'x' || *s =3D=3D 'X') { ++s; base =3D 16; } else { base =3D 8; flag =3D true; } } else base =3D 10; for (; (c =3D *s) !=3D '\0'; ++s) { d =3D digittoint(c); if (c !=3D '0' && (d =3D=3D 0 || d >=3D base)) break; byte =3D byte * base + d; if (byte > UINT8_MAX) return (INADDR_NONE); flag =3D true; } if (!flag) return (INADDR_NONE); addr =3D (addr << 8) | byte; if (c !=3D '.') break; if (++dots =3D=3D 4) return (INADDR_NONE); } return (c =3D=3D '\0' ? addr : INADDR_NONE); } int main(void) { const char *const addr_str_tbl[] =3D { "0x12", "127.1", "127.1.2.3", "0x123456", "0x12.0x34", "0x12.0x345", "1.2.3.4.5", "1..3.4", ".", "1.", ".1", "0x", "0", "01.02.07.077", "0x1.23.045.0", "", " ", " f", "bar", "1.2bar", "1.", "=CA=C3=D5=CB=C5=CE", "255.255.255.255", "x", "0X12"= , "078", "1 bar", "127.0xabcd", "128", "0.1.2", "0xff.010.23.0xa0", "x10", "X20", "x10.x20", "4294967297", "0x10000000f", "040000000003", NULL }; const char *const *addr_str; size_t len; in_addr_t addr1, addr2; printf("STRING\t\t\tINET_NETWORK\tINET_NETWORK_NEW\n"); for (addr_str =3D addr_str_tbl; *addr_str !=3D NULL; ++addr_str) { printf("\"%s\"", *addr_str); len =3D strlen(*addr_str) + 2; if (len < 8) printf("\t\t\t"); else if (len < 16) printf("\t\t"); else printf("\t"); addr1 =3D inet_network(*addr_str); if (addr1 =3D=3D INADDR_NONE) printf("INADDR_NONE\t"); else printf("0x%08x\t", addr1); addr2 =3D inet_network_new(*addr_str); if (addr2 =3D=3D INADDR_NONE) printf("INADDR_NONE"); else printf("0x%08x", addr2); if (addr1 !=3D addr2) printf("\t<---"); printf("\n"); } return (0); } From owner-freebsd-net@FreeBSD.ORG Tue Oct 23 17:37:03 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9850087F; Tue, 23 Oct 2012 17:37:03 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 521AA8FC14; Tue, 23 Oct 2012 17:37:03 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so644999pbb.13 for ; Tue, 23 Oct 2012 10:37:02 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=864LoZucaSico/1QkOtjQS3qd8yQPOx5T8xyGBar2uM=; b=Q4Jbnicgn3vMdzFSiMaUDwK+IGotxi3X9jYabIsTPVCJo/N7kg2/cEYxnCydzAbObd F1ucuXKvT7puTzsd+Cis3S2cEe9DoG2mBDlk/YiGl63NWzaFTCvjVWM/Ghe2fNFLQx0F oGaG00DHUnzLICc25l++67Rdlm5Yy3tGyikyvywqCilkqxbWGvviYoaX51BlZ+ROszT3 RbiUy68IzZHJosvSDv9WlEXJXs/futNiCFVIwiuha8ImzrkmKWez9Fm3MGay+L9dwWf7 G3/82MFXUNBHq2rHW08/4DIxFvOCWNSN8fekD/B2RjiEaHpA+DywHs63hD6mALu/0zRF YFIg== MIME-Version: 1.0 Received: by 10.68.135.168 with SMTP id pt8mr43060977pbb.24.1351013822653; Tue, 23 Oct 2012 10:37:02 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.146.233 with HTTP; Tue, 23 Oct 2012 10:37:02 -0700 (PDT) In-Reply-To: <201210230916.11513.zec@fer.hr> References: <201210222317.00457.zec@fer.hr> <201210230916.11513.zec@fer.hr> Date: Tue, 23 Oct 2012 10:37:02 -0700 X-Google-Sender-Auth: Nb2vhf1AA3MPGTEWUU8N4AtIx9w Message-ID: Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices From: Adrian Chadd To: Marko Zec , Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 17:37:03 -0000 On 23 October 2012 00:16, Marko Zec wrote: > As already mentioned earlier, I don't terribly object if you'd place > CURVNET_SET(ifp->if_vnet) inside if_free() and a limited number of similar > functions, but I don't quite believe this is will enough to solve the > device_detach() issue without having to touch any of the drivers... That's why I'm asking for more/better ideas. So far my ideas are: * for hotplug insert - do the same as what you're doing during the kldload and boot device enumeration pass - call CURVNET_SET(vnet0) * for device unload (hotplug or otherwise) - if vnet isn't set, implicitly set it to vnet0 * for the net80211 vaps, they get destroyed in a few places (ioctl path, device detach path, I'm sure I saw one more) so I have to use CURVNET_SET(ifp->if_vnet) on those. Now, that _should_ fix it for ath(4) and net80211, and it should fix it for all the other non-USB wireless devices out there. Now as for USB - Hans, what do you think? Should we do something similar? How does VIMAGE work right now with USB wireless and USB ethernet devices? Marko - thanks for persisting with this. I'd like to try and make this work for 10.0. Adrian From owner-freebsd-net@FreeBSD.ORG Tue Oct 23 17:37:56 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DB0C6A1F for ; Tue, 23 Oct 2012 17:37:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id AB4578FC0A for ; Tue, 23 Oct 2012 17:37:56 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so3061296pad.13 for ; Tue, 23 Oct 2012 10:37:56 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6wxytLzUw8YGnOCybrc70pdpEiEr+51mLHs7jf8CUNQ=; b=M8G1efgk0zf36nELHsVG2rLWj4WqQ2vsiBw3DZKBecukvjAClg9nsI4XWVnBfhYOYb J4x3edt5AJ6QFf5t+yAu1/RxIm991tzsFMNmggUmm/9PqJ6tMpHOtBT2ijj2nEF+prqc pX2O+byPQMGpVypOBCINGgJouSHe6oNQY1ES6x2cHQ6mjizz7uyJAS7lNK8bQoMYKevA 5SPs3NSHyau4cPNdwb9RkHP6qau13tgKvCSB8s869qDxCJM2fum8IvXgP4tzoIBKcmuY jEx7NNQikxp6K1AqIrzkbEJaQMI69sPdHp1Wnu6l5ubdyUdeEFJK7IX4+H0c7RxCvxtB WiTg== MIME-Version: 1.0 Received: by 10.66.79.166 with SMTP id k6mr37148973pax.25.1351013876283; Tue, 23 Oct 2012 10:37:56 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.146.233 with HTTP; Tue, 23 Oct 2012 10:37:56 -0700 (PDT) In-Reply-To: <201210230840.q9N8e038066538@freefall.freebsd.org> References: <201210230840.q9N8e038066538@freefall.freebsd.org> Date: Tue, 23 Oct 2012 10:37:56 -0700 X-Google-Sender-Auth: 4sU0wQOVgZtBg7J_Mgzd9EJ6k5A Message-ID: Subject: Re: kern/92880: [libc] [patch] almost rewritten inet_network(3) function From: Adrian Chadd To: Andrey Simonenko Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 17:37:56 -0000 ... don't suppose you want to throw this into a test case somewhere in the tree? The new ATF import would be ideal for this. :) Adrian On 23 October 2012 01:40, Andrey Simonenko wrote: > The following reply was made to PR kern/92880; it has been noted by GNATS. > > From: Andrey Simonenko > To: bug-followup@FreeBSD.org > Cc: > Subject: kern/92880: [libc] [patch] almost rewritten inet_network(3) function > Date: Tue, 23 Oct 2012 11:36:04 +0300 > > I optimized inet_network() again. > > Difference between implementation of inet_network(3) from 9.1-PRERELEASE > and my implementation. > > STRING INET_NETWORK INET_NETWORK_NEW > "0x12" 0x00000012 0x00000012 > "127.1" 0x00007f01 0x00007f01 > "127.1.2.3" 0x7f010203 0x7f010203 > "0x123456" INADDR_NONE INADDR_NONE > "0x12.0x34" 0x00001234 0x00001234 > "0x12.0x345" INADDR_NONE INADDR_NONE > "1.2.3.4.5" INADDR_NONE INADDR_NONE > "1..3.4" INADDR_NONE INADDR_NONE > "." INADDR_NONE INADDR_NONE > "1." INADDR_NONE INADDR_NONE > ".1" INADDR_NONE INADDR_NONE > "0x" 0x00000000 INADDR_NONE <--- > "0" 0x00000000 0x00000000 > "01.02.07.077" 0x0102073f 0x0102073f > "0x1.23.045.0" 0x01172500 0x01172500 > "" INADDR_NONE INADDR_NONE > " " INADDR_NONE INADDR_NONE > " f" INADDR_NONE INADDR_NONE > "bar" INADDR_NONE INADDR_NONE > "1.2bar" INADDR_NONE INADDR_NONE > "1." INADDR_NONE INADDR_NONE > "=CA=C3=D5=CB=C5=CE" INADDR_NONE INADDR_NONE > "255.255.255.255" INADDR_NONE INADDR_NONE > "x" INADDR_NONE INADDR_NONE > "0X12" 0x00000012 0x00000012 > "078" INADDR_NONE INADDR_NONE > "1 bar" 0x00000001 INADDR_NONE <--- > "127.0xabcd" INADDR_NONE INADDR_NONE > "128" 0x00000080 0x00000080 > "0.1.2" 0x00000102 0x00000102 > "0xff.010.23.0xa0" 0xff0817a0 0xff0817a0 > "x10" 0x00000010 INADDR_NONE <--- > "X20" 0x00000020 INADDR_NONE <--- > "x10.x20" 0x00001020 INADDR_NONE <--- > "4294967297" 0x00000001 INADDR_NONE <--- > "0x10000000f" 0x0000000f INADDR_NONE <--- > "040000000003" 0x00000003 INADDR_NONE <--- > > #include > #include > > #include > #include > > #include > #include > #include > #include > #include > #include > > static in_addr_t > inet_network_new(const char *s) > { > u_int d, base, dots; > in_addr_t addr, byte; > u_char c; > bool flag; > > addr =3D 0; > dots =3D 0; > for (;; ++s) { > byte =3D 0; > flag =3D false; > if (*s =3D=3D '0') { > ++s; > if (*s =3D=3D 'x' || *s =3D=3D 'X') { > ++s; > base =3D 16; > } else { > base =3D 8; > flag =3D true; > } > } else > base =3D 10; > for (; (c =3D *s) !=3D '\0'; ++s) { > d =3D digittoint(c); > if (c !=3D '0' && (d =3D=3D 0 || d >=3D base)) > break; > byte =3D byte * base + d; > if (byte > UINT8_MAX) > return (INADDR_NONE); > flag =3D true; > } > if (!flag) > return (INADDR_NONE); > addr =3D (addr << 8) | byte; > if (c !=3D '.') > break; > if (++dots =3D=3D 4) > return (INADDR_NONE); > } > return (c =3D=3D '\0' ? addr : INADDR_NONE); > } > > int > main(void) > { > const char *const addr_str_tbl[] =3D { > "0x12", "127.1", "127.1.2.3", "0x123456", "0x12.0x34", > "0x12.0x345", "1.2.3.4.5", "1..3.4", ".", "1.", ".1", "0x", > "0", "01.02.07.077", "0x1.23.045.0", "", " ", " f", "bar", > "1.2bar", "1.", "=CA=C3=D5=CB=C5=CE", "255.255.255.255", "x", "0X12"= > , "078", > "1 bar", "127.0xabcd", "128", "0.1.2", "0xff.010.23.0xa0", > "x10", "X20", "x10.x20", "4294967297", "0x10000000f", > "040000000003", NULL }; > const char *const *addr_str; > size_t len; > in_addr_t addr1, addr2; > > printf("STRING\t\t\tINET_NETWORK\tINET_NETWORK_NEW\n"); > for (addr_str =3D addr_str_tbl; *addr_str !=3D NULL; ++addr_str) { > printf("\"%s\"", *addr_str); > len =3D strlen(*addr_str) + 2; > if (len < 8) > printf("\t\t\t"); > else if (len < 16) > printf("\t\t"); > else > printf("\t"); > addr1 =3D inet_network(*addr_str); > if (addr1 =3D=3D INADDR_NONE) > printf("INADDR_NONE\t"); > else > printf("0x%08x\t", addr1); > addr2 =3D inet_network_new(*addr_str); > if (addr2 =3D=3D INADDR_NONE) > printf("INADDR_NONE"); > else > printf("0x%08x", addr2); > if (addr1 !=3D addr2) > printf("\t<---"); > printf("\n"); > } > return (0); > } > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Oct 23 18:26:00 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9A6E6A05 for ; Tue, 23 Oct 2012 18:26:00 +0000 (UTC) (envelope-from seb@lineratesystems.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5D34C8FC14 for ; Tue, 23 Oct 2012 18:26:00 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so3094907pad.13 for ; Tue, 23 Oct 2012 11:25:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=tF6y2yvqSBIx4m6oKAtuZl3jC5GeNGi4iYpIK+3eZOM=; b=OAvUNY2DSZH81Lcfqxyw0aK5f64d8zbaYS24l1gwUCPT1OOxMAPtfN9V1ifL2E0OoH 0nh5KYIpVtB7JXVms3Znb4HSHSy0mZulfC1Iu+UzWavNWZSSXAcLhVYVrMYwMzESrSSs ppCjHhVxFOtw81RDbsOwWs+MrYMoPBbawAT/xuiRGsnqQEu5d+mJ2q1ZV3MeE4nqZ5fk IfVI0+zEtLmZ5w/6Y8B9ioNGGC33njTBrcYnNBWn0hPobl525jpfUkPV/6z66GE+QLtr dhzCcTEGtI9ieWNOvCxm+JKn8VTaD5JsvpMChag6Knx6JQUXB9PuRBAr0jtO0EgeuzDm MffA== MIME-Version: 1.0 Received: by 10.69.0.10 with SMTP id au10mr43023031pbd.18.1351016759882; Tue, 23 Oct 2012 11:25:59 -0700 (PDT) Received: by 10.68.85.137 with HTTP; Tue, 23 Oct 2012 11:25:59 -0700 (PDT) Date: Tue, 23 Oct 2012 12:25:59 -0600 Message-ID: Subject: fragmentation problem in FreeBSD 7 From: Sebastian Kuzminsky To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary=047d7b1605050ef51d04ccbe1a2c X-Gm-Message-State: ALoCoQks9Dvq3W0Sw6FRRixUE+sMiqtL5XMl5Sl64QN9XHN3vWbDWArwUGNbbMggyX6nzWtoUhd9 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 18:26:00 -0000 --047d7b1605050ef51d04ccbe1a2c Content-Type: text/plain; charset=ISO-8859-1 Hi folks, this is my first post to freebsd-net, and my first bug-fix submission... I hope this is the right mailing list for this issue, and the right format for sending in patches.... I'm working on a derivative of FreeBSD 7. I've run into a problem with IP header checksums when fragmenting to an e1000 (em) interface, and I've narrowed it down to a very simple test. The test setup is like this: [computer A]---(network 1)---[computer B]---(network 2)---[computer C] That gorgeous drawing shows computer A connected to computer B via network 1, and computer B connected to computer C via network 2. Computer B is set up to forward packets between networks 1 and 2. A can see B but not C. C can see B but not A. B forwards between A and C. Pretty simple. One of B's NICs is a Broadcom, handled by the bce driver; this one works fine in all my testing. B's other NIC is an Intel PRO/1000 handled by the em driver. This is the one giving me trouble. The test disables PMTUD on all three hosts. It then sets the MTU of the bce and em interfaces to the unrealistically low value of 72 bytes, and tries to pass TCP packets back and forth using nc on computers A and C (with computer B acting as a gateway). This is to force the B gateway to fragment the TCP frames it forwards. Receiving on the em and sending on the bce works just fine (as noted above). Small TCP frames that fit in the MTU, big TCP frames that get fragmented, no problems. Receiving on the bce and sending on the em interface works fine for small TCP frames that don't need fragmentation, but when B has to fragment the IP packets before sending them out the em, the IP header checksums in the IP packets that appear on the em's wires are wrong. I came to this conclusion by packet capture and by watching the 'bad header checksums' counter of 'netstat -s -p ip', both running on the computer receiving the fragments. Ok, those are all my observations, next comes thoughts about the cause & a proposed fix. The root of the problem is two-fold: 1. ip_output.c:ip_fragment() does not clear the CSUM_IP flag in the mbuf when it does software IP checksum computation, so the mbuf still looks like it needs IP checksumming. 2. The em driver does not advertise IP checksum offloading, but still checks the CSUM_IP flag in the mbuf and modifies the packet when that flag is set (this is in em_transmit_checksum_setup(), called by em_xmit()). Unfortunately the em driver gets the checksum wrong in this case, i guess that's why it doesn't advertise this capability in its if_hwassist! So the fragments that ip_fastfwd.c:ip_fastforward() gets from ip_output.c:ip_fragment() have ip->ip_sum set correctly, but the mbuf->m_pkthdr.csum_flags incorrectly has CSUM_IP still set, and this causes the em driver to emit incorrect packets. There are some other callers of ip_fragment(), notably ip_output(). ip_output() clears CSUM_IP in the mbuf csum_flags itself if it's not in if_hwassist, so avoids this problem. So, the fix is simple: clear the mbuf's CSUM_IP when computing ip->ip_sum in ip_fragment(). The first attached patch (against gitorious/svn_stable_7) does this. In looking at this issue, I noticed that ip_output()'s use of sw_csum is inconsistent. ip_output() splits the mbuf's csum_flags into two parts: the stuff that hardware will assist with (these flags get left in the mbuf) and the stuff that software needs to do (these get moved to sw_csum). But later ip_output() calls functions that don't get sw_csum, or that don't know to look in it and look in the mbuf instead. My second patch fixes these kinds of issues and (IMO) simplifies the code by leaving all the packet's checksumming needs in the mbuf, getting rid of sw_csum entirely. -- Sebastian Kuzminsky Linerate Systems --047d7b1605050ef51d04ccbe1a2c Content-Type: application/octet-stream; name="0001-Update-the-mbuf-csum_flags-of-IP-fragments-when-comp.patch" Content-Disposition: attachment; filename="0001-Update-the-mbuf-csum_flags-of-IP-fragments-when-comp.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h8nbm4sn0 RnJvbSBjMDRhN2E5NTg5MGVmNWQwMzJlNjk5ODY3NTQ5NmJiNDM4YzNhMTRiIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBTZWJhc3RpYW4gS3V6bWluc2t5IDxzZWJAbGluZXJhdGVzeXN0 ZW1zLmNvbT4KRGF0ZTogTW9uLCAyMiBPY3QgMjAxMiAyMTowODo0MCAtMDYwMApTdWJqZWN0OiBb UEFUQ0ggMS8yXSBVcGRhdGUgdGhlIG1idWYgY3N1bV9mbGFncyBvZiBJUCBmcmFnbWVudHMgd2hl bgogY29tcHV0aW5nIHRoZWlyIElQIGNoZWNrc3VtCgpCZWZvcmUgdGhpcyBjb21taXQsIHRoZSBp cF9mcmFnbWVudCgpIGZ1bmN0aW9uIGRvZXMgbm90IGNsZWFyIHRoZQptYnVmIENTVU1fSVAgZmxh ZyAoInRoaXMgbWJ1ZiBuZWVkcyBhbiBJUCBoZWFkZXIgY2hlY2tzdW0iKSwgZXZlbgp3aGVuIGl0 IGNvbXB1dGVzIHRoZSBJUCBoZWFkZXIgY2hlY2tzdW0gaXRzZWxmLiAgVGhpcyBiZWhhdmlvciBp cwphY2NlcHRhYmxlIHdoZW4gaXBfZnJhZ21lbnQoKSBpcyBjYWxsZWQgZnJvbSBpcF9vdXRwdXQo KSwgYmVjYXVzZQppcF9vdXRwdXQoKSBjbGVhcnMgdGhlIG1idWYncyBmbGFnLiAgQnV0IGl0IGlz IG5vdCBhY2NlcHRhYmxlIHdoZW4KaXBfZnJhZ21lbnQoKSBpcyBjYWxsZWQgZnJvbSBpcF9mYXN0 Zm9yd2FyZCgpLCBiZWNhdXNlIGlwX2Zhc3Rmb3J3YXJkKCkKZG9lcyBub3QgY2xlYXIgdGhlIG1i dWYncyBmbGFnLgoKVGhlIHJlc3VsdCBpcyB0aGF0LCB3aGVuIGZvcndhcmRpbmcgYSBwYWNrZXQg dGhhdCBuZWVkcyBmcmFnbWVudGF0aW9uLAphbmQgdGhlIGZyYWdtZW50cyBhcmUgc2VudCBieSBh IE5JQyB0aGF0IGRvZXMgbm90IGFkdmVydGlzZSBoYXJkd2FyZQpJUCBjaGVja3N1bSBvZmZsb2Fk aW5nLCBhbmQgdGhhdCBOSUMgKmRvZXMqIGNoZWNrIGZvciBmb3IgdGhlIENTVU1fSVAKZmxhZyBh bnl3YXkgYW5kIHRoZW4gZ2V0cyB0aGUgSVAgY2hlY2tzdW0gd3JvbmcsICp0aGVuKiB0aGUgZnJh Z21lbnRzCmdvaW5nIG91dCBvbiB0aGUgd2lyZSB3b3VsZCBoYXZlIHRoZSB3cm9uZyBjaGVja3N1 bS4KClRoZSBlbSBkcml2ZXIgZG9lcyBub3QgYWR2ZXJ0aXNlIElQIGhlYWRlciBjaGVja3N1bSBv ZmZsb2FkaW5nLCBidXQKZG9lcyB0cnkgdG8gc2V0IHVwIElQIGhlYWRlciBjaGVja3N1bSBvZmZs b2FkaW5nIGFueXdheSB3aGVuIHRoZQptYnVmIGlzIG1hcmtlZCBDU1VNX0lQLCBhbmQgaXQgZ2V0 cyB0aGUgSVAgY2hlY2tzdW0gd3JvbmcuCgpUaGUgZml4IGlzIHRvIGNsZWFyIHRoZSBDU1VNX0lQ IGZsYWcgaW4gdGhlIG1idWYgaW4gaXBfZnJhZ21lbnQoKQp3aGVuIHRoZSBJUCBjaGVja3N1bSBp cyBjb21wdXRlZCwgdG8gbGV0IHRoZSBsb3dlciBsYXllcnMga25vdyB0aGF0CnRoZXkgZG9uJ3Qg bmVlZCB0byBkbyBpdC4KLS0tCiBzeXMvbmV0aW5ldC9pcF9mYXN0ZndkLmMgfCAgICA5ICsrKysr KysrLQogc3lzL25ldGluZXQvaXBfb3V0cHV0LmMgIHwgICAzMCArKysrKysrKysrKysrKysrKysr KysrKysrKysrLS0KIDIgZmlsZXMgY2hhbmdlZCwgMzYgaW5zZXJ0aW9ucygrKSwgMyBkZWxldGlv bnMoLSkKCmRpZmYgLS1naXQgYS9zeXMvbmV0aW5ldC9pcF9mYXN0ZndkLmMgYi9zeXMvbmV0aW5l dC9pcF9mYXN0ZndkLmMKaW5kZXggZTg0Njk1ZS4uYWU2NWJmZSAxMDA2NDQKLS0tIGEvc3lzL25l dGluZXQvaXBfZmFzdGZ3ZC5jCisrKyBiL3N5cy9uZXRpbmV0L2lwX2Zhc3Rmd2QuYwpAQCAtNTU4 LDEyICs1NTgsMTkgQEAgcGFzc291dDoKIAkJCWdvdG8gY29uc3VtZWQ7CiAJCX0gZWxzZSB7CiAJ CQkvKgotCQkJICogV2UgaGF2ZSB0byBmcmFnbWVudCB0aGUgcGFja2V0CisJCQkgKiBXZSBoYXZl IHRvIGZyYWdtZW50IHRoaXMgcGFja2V0LCBhbmQgdGhlIGZyYWdtZW50cworCQkJICogd2lsbCBu ZWVkIGFsbC1uZXcgSVAgY2hlY2tzdW1zLiAgKFRoZSBwYXlsb2FkCisJCQkgKiBjaGVja3N1bXMs IGlmIGFueSwgZG9uJ3QgbmVlZCB0byBiZSBtb2RpZmllZAorCQkJICogYmVjYXVzZSB0aGUgcGF5 bG9hZCB3aWxsIGJlIHJlYXNzZW1ibGVkIGJlZm9yZQorCQkJICogZGVsaXZlcnkuKQogCQkJICov CiAJCQltLT5tX3BrdGhkci5jc3VtX2ZsYWdzIHw9IENTVU1fSVA7CiAJCQkvKgogCQkJICogaXBf ZnJhZ21lbnQgZXhwZWN0cyBpcF9sZW4gYW5kIGlwX29mZiBpbiBob3N0IGJ5dGUKIAkJCSAqIG9y ZGVyIGJ1dCByZXR1cm5zIGFsbCBwYWNrZXRzIGluIG5ldHdvcmsgYnl0ZSBvcmRlcgorCQkJICog SWYgaWZfaHdhc3Npc3QgZG9lc24ndCBhZHZlcnRpc2UgSVAgY2hlY2tzdW0KKwkJCSAqIG9mZmxv YWRpbmcsIGFzayBpcF9mcmFnbWVudCB0byBkbyBpdCBmb3IgdXMgaW4KKwkJCSAqIHNvZnR3YXJl IG5vdy4KIAkJCSAqLwogCQkJaWYgKGlwX2ZyYWdtZW50KGlwLCAmbSwgbXR1LCBpZnAtPmlmX2h3 YXNzaXN0LAogCQkJCQkofmlmcC0+aWZfaHdhc3Npc3QgJiBDU1VNX0RFTEFZX0lQKSkpIHsKZGlm ZiAtLWdpdCBhL3N5cy9uZXRpbmV0L2lwX291dHB1dC5jIGIvc3lzL25ldGluZXQvaXBfb3V0cHV0 LmMKaW5kZXggYWRiYjA3NC4uMDhjNDE4NSAxMDA2NDQKLS0tIGEvc3lzL25ldGluZXQvaXBfb3V0 cHV0LmMKKysrIGIvc3lzL25ldGluZXQvaXBfb3V0cHV0LmMKQEAgLTUwNiwxMiArNTA2LDMwIEBA IHBhc3NvdXQ6CiAJCX0KIAl9CiAKKwkvKiBBbm5vdGF0ZSB0aGUgb3V0Z29pbmcgcGFja2V0OiBp dCBuZWVkcyBpdHMgSVAgaGVhZGVyIGNoZWNrc3VtbWVkLiAqLwogCW0tPm1fcGt0aGRyLmNzdW1f ZmxhZ3MgfD0gQ1NVTV9JUDsKKworCS8qIHN3X2NzdW0gaXMgZXZlcnl0aGluZyB0aGUgcGFja2V0 IG5lZWRzIHRoYXQgKndvbid0KiBiZSBkb25lIGluCisJICogaGFyZHdhcmUuCisJICovCiAJc3df Y3N1bSA9IG0tPm1fcGt0aGRyLmNzdW1fZmxhZ3MgJiB+aWZwLT5pZl9od2Fzc2lzdDsKKworCS8q IERvIHBheWxvYWQgY2hlY2tzdW1taW5nIGluIHNvZnR3YXJlLCBub3csIGlmIG5lZWRlZCAmIHdh bnRlZC4gKi8KIAlpZiAoc3dfY3N1bSAmIENTVU1fREVMQVlfREFUQSkgewogCQlpbl9kZWxheWVk X2Nrc3VtKG0pOwogCQlzd19jc3VtICY9IH5DU1VNX0RFTEFZX0RBVEE7CiAJfQorCisJLyogQ2xl YXIgYWxsIHRoZSBwYWNrZXQncyBuZWVkcyB0aGF0J2xsIGJlIGRvbmUgYnkgc29mdHdhcmUuCisJ ICogQXQgdGhpcyBwb2ludCB0aGUgcGFja2V0J3MgbmVlZHMgYXJlIChtX3BrdGhkci5jc3VtX2Zs YWdzIHwgc3dfY3N1bSksCisJICogYW5kIHNvZnR3YXJlIHNob3VsZCBkbyB0aGUgc3R1ZmYgaW4g c3dfY3N1bS4KKwkgKgorCSAqIEZJWE1FOiBUaGlzIGlzIGEgYnVnLCBzdHVmZiBpbiB0aGUgY29k ZSBwYXRocyBhZnRlciB0aGlzCisJICogKGZvciBleGFtcGxlIGlwX2ZyYWdtZW50KSBleHBlY3Qg bV9wa3RoZHItPmNzdW1fZmxhZ3MgdG8gYmUgdGhlCisJICogbGlzdCBvZiBzdHVmZiB0aGUgcGFj a2V0IG5lZWRzLiAgaW5fZGVsYXllZF9ja3N1bSgpIGFib3ZlIGFsc28KKwkgKiBoYXMgdGhpcyBl eHBlY3RhdGlvbiwgd2hpY2ggaXMgd2h5IHRoaXMgY29kZSBpcyBjb252b2x1dGVkIHRvCisJICog Y2FsbCBpdCBiZWZvcmUgY2xlYXJpbmcgbSdzIGNzdW1fZmxhZ3MuCisJICovCiAJbS0+bV9wa3Ro ZHIuY3N1bV9mbGFncyAmPSBpZnAtPmlmX2h3YXNzaXN0OwogCiAJLyoKQEAgLTUyNiw2ICs1NDQs MTAgQEAgcGFzc291dDoKIAkJaXAtPmlwX3N1bSA9IDA7CiAJCWlmIChzd19jc3VtICYgQ1NVTV9E RUxBWV9JUCkKIAkJCWlwLT5pcF9zdW0gPSBpbl9ja3N1bShtLCBobGVuKTsKKwkJCS8qIE5vcm1h bGx5IHdlJ2QgY2xlYXIgQ1NVTV9ERUxBWV9JUCBvdXQgb2Ygc3dfY3N1bQorCQkJICogaGVyZSwg YnV0IHRoYXQgdmFyaWFibGUgaXMgbm90IHVzZWQgYWdhaW4gYmVmb3JlCisJCQkgKiBpdCBwYXNz ZXMgb3V0IG9mIHNjb3BlLgorCQkJICovCiAKIAkJLyoKIAkJICogUmVjb3JkIHN0YXRpc3RpY3Mg Zm9yIHRoaXMgaW50ZXJmYWNlIGFkZHJlc3MuCkBAIC03NDMsOCArNzY1LDEwIEBAIHNtYXJ0X2Zy YWdfZmFpbHVyZToKIAkJbS0+bV9wa3RoZHIuY3N1bV9mbGFncyA9IG0wLT5tX3BrdGhkci5jc3Vt X2ZsYWdzOwogCQltaGlwLT5pcF9vZmYgPSBodG9ucyhtaGlwLT5pcF9vZmYpOwogCQltaGlwLT5p cF9zdW0gPSAwOwotCQlpZiAoc3dfY3N1bSAmIENTVU1fREVMQVlfSVApCisJCWlmIChzd19jc3Vt ICYgQ1NVTV9ERUxBWV9JUCkgewogCQkJbWhpcC0+aXBfc3VtID0gaW5fY2tzdW0obSwgbWhsZW4p OworCQkJbS0+bV9wa3RoZHIuY3N1bV9mbGFncyAmPSB+Q1NVTV9ERUxBWV9JUDsKKwkJfQogCQkq bW5leHQgPSBtOwogCQltbmV4dCA9ICZtLT5tX25leHRwa3Q7CiAJfQpAQCAtNzY0LDggKzc4OCwx MCBAQCBzbWFydF9mcmFnX2ZhaWx1cmU6CiAJaXAtPmlwX29mZiB8PSBJUF9NRjsKIAlpcC0+aXBf b2ZmID0gaHRvbnMoaXAtPmlwX29mZik7CiAJaXAtPmlwX3N1bSA9IDA7Ci0JaWYgKHN3X2NzdW0g JiBDU1VNX0RFTEFZX0lQKQorCWlmIChzd19jc3VtICYgQ1NVTV9ERUxBWV9JUCkgewogCQlpcC0+ aXBfc3VtID0gaW5fY2tzdW0obTAsIGhsZW4pOworCQltMC0+bV9wa3RoZHIuY3N1bV9mbGFncyAm PSB+Q1NVTV9ERUxBWV9JUDsKKwl9CiAKIGRvbmU6CiAJKm1fZnJhZyA9IG0wOwotLSAKMS43Ljgu MwoK --047d7b1605050ef51d04ccbe1a2c Content-Type: application/octet-stream; name="0002-Simplify-the-tracking-of-mbuf-checksumming-needs.patch" Content-Disposition: attachment; filename="0002-Simplify-the-tracking-of-mbuf-checksumming-needs.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h8nbm4ss1 RnJvbSBlYmJiZDdhZDY0YTFjYWZkOWE0YjExODJlZGUxODJmYmMzNzNiNTI5IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBTZWJhc3RpYW4gS3V6bWluc2t5IDxzZWJAbGluZXJhdGVzeXN0 ZW1zLmNvbT4KRGF0ZTogVHVlLCAyMyBPY3QgMjAxMiAxMDo1OToyMCAtMDYwMApTdWJqZWN0OiBb UEFUQ0ggMi8yXSBTaW1wbGlmeSB0aGUgdHJhY2tpbmcgb2YgbWJ1ZiBjaGVja3N1bW1pbmcgbmVl ZHMKClRoZSBJUCBjb2RlIHRyYWNrcyBvdXRnb2luZyBwYWNrZXRzJyBjaGVja3N1bW1pbmcgbmVl ZHMgaW5jb25zaXN0ZW50bHkuClRoZSBzd19jc3VtIHZhcmlhYmxlIGNvbXBsaWNhdGVzIGJ1dCBk b2VzIG5vdCBhZGQgdmFsdWUuCgpUaGUgc3dfY3N1bSB2YXJpYWJsZSBpcyBub3QgbmVlZGVkLiAg VGhpcyBjb21taXQgcmVtb3ZlcyBpdC4gIFRoZQptYnVmJ3MgbV9wa3RoZHItPmNzdW1fZmxhZ3Mg YXJlIG5vdyB0aGUgb25lIHJlY29yZCBvZiB3aGF0IHRoZQpwYWNrZXQgbmVlZHMuCi0tLQogc3lz L2NvbnRyaWIvcGYvbmV0L3BmLmMgIHwgICAxNCArKysrKy0tLS0tLS0tLQogc3lzL25ldC9pZl9i cmlkZ2UuYyAgICAgIHwgICAgOCArKysrKystLQogc3lzL25ldGluZXQvaXBfZmFzdGZ3ZC5jIHwg ICAgMyArLS0KIHN5cy9uZXRpbmV0L2lwX21yb3V0ZS5jICB8ICAgIDMgKystCiBzeXMvbmV0aW5l dC9pcF9vdXRwdXQuYyAgfCAgIDQwICsrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0KIHN5cy9uZXRpbmV0L2lwX3Zhci5oICAgICB8ICAgIDIgKy0KIDYgZmlsZXMgY2hhbmdl ZCwgMjUgaW5zZXJ0aW9ucygrKSwgNDUgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvc3lzL2Nv bnRyaWIvcGYvbmV0L3BmLmMgYi9zeXMvY29udHJpYi9wZi9uZXQvcGYuYwppbmRleCAyMGU5MjVi Li4wY2RkMjE3IDEwMDY0NAotLS0gYS9zeXMvY29udHJpYi9wZi9uZXQvcGYuYworKysgYi9zeXMv Y29udHJpYi9wZi9uZXQvcGYuYwpAQCAtNjI1Myw5ICs2MjUzLDYgQEAgcGZfcm91dGUoc3RydWN0 IG1idWYgKiptLCBzdHJ1Y3QgcGZfcnVsZSAqciwgaW50IGRpciwgc3RydWN0IGlmbmV0ICpvaWZw LAogCXN0cnVjdCBwZl9hZGRyCQkgbmFkZHI7CiAJc3RydWN0IHBmX3NyY19ub2RlCSpzbiA9IE5V TEw7CiAJaW50CQkJIGVycm9yID0gMDsKLSNpZmRlZiBfX0ZyZWVCU0RfXwotCWludCBzd19jc3Vt OwotI2VuZGlmCiAjaWZkZWYgSVBTRUMKIAlzdHJ1Y3QgbV90YWcJCSptdGFnOwogI2VuZGlmIC8q IElQU0VDICovCkBAIC02MzYxLDggKzYzNTgsNyBAQCBwZl9yb3V0ZShzdHJ1Y3QgbWJ1ZiAqKm0s IHN0cnVjdCBwZl9ydWxlICpyLCBpbnQgZGlyLCBzdHJ1Y3QgaWZuZXQgKm9pZnAsCiAjaWZkZWYg X19GcmVlQlNEX18KIAkvKiBDb3BpZWQgZnJvbSBGcmVlQlNEIDUuMS1DVVJSRU5UIGlwX291dHB1 dC4gKi8KIAltMC0+bV9wa3RoZHIuY3N1bV9mbGFncyB8PSBDU1VNX0lQOwotCXN3X2NzdW0gPSBt MC0+bV9wa3RoZHIuY3N1bV9mbGFncyAmIH5pZnAtPmlmX2h3YXNzaXN0OwotCWlmIChzd19jc3Vt ICYgQ1NVTV9ERUxBWV9EQVRBKSB7CisJaWYgKG0wLT5tX3BrdGhkci5jc3VtX2ZsYWdzICYgQ1NV TV9ERUxBWV9EQVRBICYgfmlmcC0+aWZfaHdhc3Npc3QpIHsKIAkJLyoKIAkJICogWFhYOiBpbl9k ZWxheWVkX2Nrc3VtIGFzc3VtZXMgSEJPIGZvciBpcC0+aXBfbGVuIChhdCBsZWFzdCkKIAkJICov CkBAIC02MzcxLDkgKzYzNjcsOCBAQCBwZl9yb3V0ZShzdHJ1Y3QgbWJ1ZiAqKm0sIHN0cnVjdCBw Zl9ydWxlICpyLCBpbnQgZGlyLCBzdHJ1Y3QgaWZuZXQgKm9pZnAsCiAJCWluX2RlbGF5ZWRfY2tz dW0obTApOwogCQlIVE9OUyhpcC0+aXBfbGVuKTsKIAkJSFRPTlMoaXAtPmlwX29mZik7Ci0JCXN3 X2NzdW0gJj0gfkNTVU1fREVMQVlfREFUQTsKKwkJbTAtPm1fcGt0aGRyLmNzdW1fZmxhZ3MgJj0g fkNTVU1fREVMQVlfREFUQTsKIAl9Ci0JbTAtPm1fcGt0aGRyLmNzdW1fZmxhZ3MgJj0gaWZwLT5p Zl9od2Fzc2lzdDsKIAogCWlmIChudG9ocyhpcC0+aXBfbGVuKSA8PSBpZnAtPmlmX210dSB8fAog CSAgICAobTAtPm1fcGt0aGRyLmNzdW1fZmxhZ3MgJiBpZnAtPmlmX2h3YXNzaXN0ICYgQ1NVTV9U U08pICE9IDAgfHwKQEAgLTYzODQsNyArNjM3OSw3IEBAIHBmX3JvdXRlKHN0cnVjdCBtYnVmICoq bSwgc3RydWN0IHBmX3J1bGUgKnIsIGludCBkaXIsIHN0cnVjdCBpZm5ldCAqb2lmcCwKIAkJICog aXAtPmlwX29mZiA9IGh0b25zKGlwLT5pcF9vZmYpOwogCQkgKi8KIAkJaXAtPmlwX3N1bSA9IDA7 Ci0JCWlmIChzd19jc3VtICYgQ1NVTV9ERUxBWV9JUCkgeworCQlpZiAobTAtPm1fcGt0aGRyLmNz dW1fZmxhZ3MgJiBDU1VNX0RFTEFZX0lQICYgfmlmcC0+aWZfaHdhc3Npc3QpIHsKIAkJCS8qIEZy b20gS0FNRSAqLwogCQkJaWYgKGlwLT5pcF92ID09IElQVkVSU0lPTiAmJgogCQkJICAgIChpcC0+ aXBfaGwgPDwgMikgPT0gc2l6ZW9mKCppcCkpIHsKQEAgLTYzOTIsNiArNjM4Nyw3IEBAIHBmX3Jv dXRlKHN0cnVjdCBtYnVmICoqbSwgc3RydWN0IHBmX3J1bGUgKnIsIGludCBkaXIsIHN0cnVjdCBp Zm5ldCAqb2lmcCwKIAkJCX0gZWxzZSB7CiAJCQkJaXAtPmlwX3N1bSA9IGluX2Nrc3VtKG0wLCBp cC0+aXBfaGwgPDwgMik7CiAJCQl9CisJCQltMC0+bV9wa3RoZHIuY3N1bV9mbGFncyAmPSB+Q1NV TV9ERUxBWV9JUDsKIAkJfQogCQlQRl9VTkxPQ0soKTsKIAkJZXJyb3IgPSAoKmlmcC0+aWZfb3V0 cHV0KShpZnAsIG0wLCBzaW50b3NhKGRzdCksIHJvLT5yb19ydCk7CkBAIC02NDc4LDcgKzY0NzQs NyBAQCBwZl9yb3V0ZShzdHJ1Y3QgbWJ1ZiAqKm0sIHN0cnVjdCBwZl9ydWxlICpyLCBpbnQgZGly LCBzdHJ1Y3QgaWZuZXQgKm9pZnAsCiAJICovCiAJTlRPSFMoaXAtPmlwX2xlbik7CiAJTlRPSFMo aXAtPmlwX29mZik7Ci0JZXJyb3IgPSBpcF9mcmFnbWVudChpcCwgJm0wLCBpZnAtPmlmX210dSwg aWZwLT5pZl9od2Fzc2lzdCwgc3dfY3N1bSk7CisJZXJyb3IgPSBpcF9mcmFnbWVudChpcCwgJm0w LCBpZnAtPmlmX210dSwgaWZwLT5pZl9od2Fzc2lzdCk7CiAjZWxzZQogCWVycm9yID0gaXBfZnJh Z21lbnQobTAsIGlmcCwgaWZwLT5pZl9tdHUpOwogI2VuZGlmCmRpZmYgLS1naXQgYS9zeXMvbmV0 L2lmX2JyaWRnZS5jIGIvc3lzL25ldC9pZl9icmlkZ2UuYwppbmRleCA0ZDFiOWRhLi5hMmEyYjBk IDEwMDY0NAotLS0gYS9zeXMvbmV0L2lmX2JyaWRnZS5jCisrKyBiL3N5cy9uZXQvaWZfYnJpZGdl LmMKQEAgLTMzNDcsOCArMzM0NywxMiBAQCBicmlkZ2VfZnJhZ21lbnQoc3RydWN0IGlmbmV0ICpp ZnAsIHN0cnVjdCBtYnVmICptLCBzdHJ1Y3QgZXRoZXJfaGVhZGVyICplaCwKIAkJZ290byBvdXQ7 CiAJaXAgPSBtdG9kKG0sIHN0cnVjdCBpcCAqKTsKIAotCWVycm9yID0gaXBfZnJhZ21lbnQoaXAs ICZtLCBpZnAtPmlmX210dSwgaWZwLT5pZl9od2Fzc2lzdCwKLQkJICAgIENTVU1fREVMQVlfSVAp OworCS8qIFdlJ3JlIGdvaW5nIHRvIGZyYWdtZW50IHRoZSBJUCBwYWNrZXQsIHRoZSBmcmFnbWVu dHMgd2lsbCBuZWVkCisJICogbmV3IElQIGNoZWNrc3Vtcy4KKwkgKi8KKwltLT5tX3BrdGhkci5j c3VtX2ZsYWdzIHw9IENTVU1fREVMQVlfSVA7CisKKwllcnJvciA9IGlwX2ZyYWdtZW50KGlwLCAm bSwgaWZwLT5pZl9tdHUsIGlmcC0+aWZfaHdhc3Npc3QpOwogCWlmIChlcnJvcikKIAkJZ290byBv dXQ7CiAKZGlmZiAtLWdpdCBhL3N5cy9uZXRpbmV0L2lwX2Zhc3Rmd2QuYyBiL3N5cy9uZXRpbmV0 L2lwX2Zhc3Rmd2QuYwppbmRleCBhZTY1YmZlLi44NTJlYThlIDEwMDY0NAotLS0gYS9zeXMvbmV0 aW5ldC9pcF9mYXN0ZndkLmMKKysrIGIvc3lzL25ldGluZXQvaXBfZmFzdGZ3ZC5jCkBAIC01NzIs OCArNTcyLDcgQEAgcGFzc291dDoKIAkJCSAqIG9mZmxvYWRpbmcsIGFzayBpcF9mcmFnbWVudCB0 byBkbyBpdCBmb3IgdXMgaW4KIAkJCSAqIHNvZnR3YXJlIG5vdy4KIAkJCSAqLwotCQkJaWYgKGlw X2ZyYWdtZW50KGlwLCAmbSwgbXR1LCBpZnAtPmlmX2h3YXNzaXN0LAotCQkJCQkofmlmcC0+aWZf aHdhc3Npc3QgJiBDU1VNX0RFTEFZX0lQKSkpIHsKKwkJCWlmIChpcF9mcmFnbWVudChpcCwgJm0s IG10dSwgaWZwLT5pZl9od2Fzc2lzdCkpIHsKIAkJCQlnb3RvIGRyb3A7CiAJCQl9CiAJCQlLQVNT RVJUKG0gIT0gTlVMTCwgKCJudWxsIG1idWYgYW5kIG5vIGVycm9yIikpOwpkaWZmIC0tZ2l0IGEv c3lzL25ldGluZXQvaXBfbXJvdXRlLmMgYi9zeXMvbmV0aW5ldC9pcF9tcm91dGUuYwppbmRleCBk NjBlOGJkLi5kYzViMGFmIDEwMDY0NAotLS0gYS9zeXMvbmV0aW5ldC9pcF9tcm91dGUuYworKysg Yi9zeXMvbmV0aW5ldC9pcF9tcm91dGUuYwpAQCAtMjYzMCw3ICsyNjMwLDggQEAgcGltX3JlZ2lz dGVyX3ByZXBhcmUoc3RydWN0IGlwICppcCwgc3RydWN0IG1idWYgKm0pCiAJaXAtPmlwX3N1bSA9 IGluX2Nrc3VtKG1iX2NvcHksIGlwLT5pcF9obCA8PCAyKTsKICAgICB9IGVsc2UgewogCS8qIEZy YWdtZW50IHRoZSBwYWNrZXQgKi8KLQlpZiAoaXBfZnJhZ21lbnQoaXAsICZtYl9jb3B5LCBtdHUs IDAsIENTVU1fREVMQVlfSVApICE9IDApIHsKKwltYl9jb3B5LT5tX3BrdGhkci5jc3VtX2ZsYWdz IHw9IENTVU1fREVMQVlfSVA7CisJaWYgKGlwX2ZyYWdtZW50KGlwLCAmbWJfY29weSwgbXR1LCAw KSAhPSAwKSB7CiAJICAgIG1fZnJlZW0obWJfY29weSk7CiAJICAgIHJldHVybiBOVUxMOwogCX0K ZGlmZiAtLWdpdCBhL3N5cy9uZXRpbmV0L2lwX291dHB1dC5jIGIvc3lzL25ldGluZXQvaXBfb3V0 cHV0LmMKaW5kZXggMDhjNDE4NS4uYzZmMmQyZCAxMDA2NDQKLS0tIGEvc3lzL25ldGluZXQvaXBf b3V0cHV0LmMKKysrIGIvc3lzL25ldGluZXQvaXBfb3V0cHV0LmMKQEAgLTExMiw3ICsxMTIsNyBA QCBpcF9vdXRwdXQoc3RydWN0IG1idWYgKm0sIHN0cnVjdCBtYnVmICpvcHQsIHN0cnVjdCByb3V0 ZSAqcm8sIGludCBmbGFncywKIAlpbnQgbGVuLCBlcnJvciA9IDA7CiAJc3RydWN0IHNvY2thZGRy X2luICpkc3QgPSBOVUxMOwkvKiBrZWVwIGNvbXBpbGVyIGhhcHB5ICovCiAJc3RydWN0IGluX2lm YWRkciAqaWEgPSBOVUxMOwotCWludCBpc2Jyb2FkY2FzdCwgc3dfY3N1bTsKKwlpbnQgaXNicm9h ZGNhc3Q7CiAJc3RydWN0IHJvdXRlIGlwcm91dGU7CiAJc3RydWN0IGluX2FkZHIgb2RzdDsKICNp ZmRlZiBJUEZJUkVXQUxMX0ZPUldBUkQKQEAgLTUwOSwyOSArNTA5LDEyIEBAIHBhc3NvdXQ6CiAJ LyogQW5ub3RhdGUgdGhlIG91dGdvaW5nIHBhY2tldDogaXQgbmVlZHMgaXRzIElQIGhlYWRlciBj aGVja3N1bW1lZC4gKi8KIAltLT5tX3BrdGhkci5jc3VtX2ZsYWdzIHw9IENTVU1fSVA7CiAKLQkv KiBzd19jc3VtIGlzIGV2ZXJ5dGhpbmcgdGhlIHBhY2tldCBuZWVkcyB0aGF0ICp3b24ndCogYmUg ZG9uZSBpbgotCSAqIGhhcmR3YXJlLgotCSAqLwotCXN3X2NzdW0gPSBtLT5tX3BrdGhkci5jc3Vt X2ZsYWdzICYgfmlmcC0+aWZfaHdhc3Npc3Q7Ci0KIAkvKiBEbyBwYXlsb2FkIGNoZWNrc3VtbWlu ZyBpbiBzb2Z0d2FyZSwgbm93LCBpZiBuZWVkZWQgJiB3YW50ZWQuICovCi0JaWYgKHN3X2NzdW0g JiBDU1VNX0RFTEFZX0RBVEEpIHsKKwlpZiAobS0+bV9wa3RoZHIuY3N1bV9mbGFncyAmIENTVU1f REVMQVlfREFUQSAmIH5pZnAtPmlmX2h3YXNzaXN0KSB7CiAJCWluX2RlbGF5ZWRfY2tzdW0obSk7 Ci0JCXN3X2NzdW0gJj0gfkNTVU1fREVMQVlfREFUQTsKKwkJbS0+bV9wa3RoZHIuY3N1bV9mbGFn cyAmPSB+Q1NVTV9ERUxBWV9EQVRBOwogCX0KIAotCS8qIENsZWFyIGFsbCB0aGUgcGFja2V0J3Mg bmVlZHMgdGhhdCdsbCBiZSBkb25lIGJ5IHNvZnR3YXJlLgotCSAqIEF0IHRoaXMgcG9pbnQgdGhl IHBhY2tldCdzIG5lZWRzIGFyZSAobV9wa3RoZHIuY3N1bV9mbGFncyB8IHN3X2NzdW0pLAotCSAq IGFuZCBzb2Z0d2FyZSBzaG91bGQgZG8gdGhlIHN0dWZmIGluIHN3X2NzdW0uCi0JICoKLQkgKiBG SVhNRTogVGhpcyBpcyBhIGJ1Zywgc3R1ZmYgaW4gdGhlIGNvZGUgcGF0aHMgYWZ0ZXIgdGhpcwot CSAqIChmb3IgZXhhbXBsZSBpcF9mcmFnbWVudCkgZXhwZWN0IG1fcGt0aGRyLT5jc3VtX2ZsYWdz IHRvIGJlIHRoZQotCSAqIGxpc3Qgb2Ygc3R1ZmYgdGhlIHBhY2tldCBuZWVkcy4gIGluX2RlbGF5 ZWRfY2tzdW0oKSBhYm92ZSBhbHNvCi0JICogaGFzIHRoaXMgZXhwZWN0YXRpb24sIHdoaWNoIGlz IHdoeSB0aGlzIGNvZGUgaXMgY29udm9sdXRlZCB0bwotCSAqIGNhbGwgaXQgYmVmb3JlIGNsZWFy aW5nIG0ncyBjc3VtX2ZsYWdzLgotCSAqLwotCW0tPm1fcGt0aGRyLmNzdW1fZmxhZ3MgJj0gaWZw LT5pZl9od2Fzc2lzdDsKLQogCS8qCiAJICogSWYgc21hbGwgZW5vdWdoIGZvciBpbnRlcmZhY2Us IG9yIHRoZSBpbnRlcmZhY2Ugd2lsbCB0YWtlCiAJICogY2FyZSBvZiB0aGUgZnJhZ21lbnRhdGlv biBmb3IgdXMsIHdlIGNhbiBqdXN0IHNlbmQgZGlyZWN0bHkuCkBAIC01NDIsMTIgKzUyNSwxMCBA QCBwYXNzb3V0OgogCQlpcC0+aXBfbGVuID0gaHRvbnMoaXAtPmlwX2xlbik7CiAJCWlwLT5pcF9v ZmYgPSBodG9ucyhpcC0+aXBfb2ZmKTsKIAkJaXAtPmlwX3N1bSA9IDA7Ci0JCWlmIChzd19jc3Vt ICYgQ1NVTV9ERUxBWV9JUCkKKwkJaWYgKChtLT5tX3BrdGhkci5jc3VtX2ZsYWdzICYgQ1NVTV9E RUxBWV9JUCkgJiB+aWZwLT5pZl9od2Fzc2lzdCkgewogCQkJaXAtPmlwX3N1bSA9IGluX2Nrc3Vt KG0sIGhsZW4pOwotCQkJLyogTm9ybWFsbHkgd2UnZCBjbGVhciBDU1VNX0RFTEFZX0lQIG91dCBv ZiBzd19jc3VtCi0JCQkgKiBoZXJlLCBidXQgdGhhdCB2YXJpYWJsZSBpcyBub3QgdXNlZCBhZ2Fp biBiZWZvcmUKLQkJCSAqIGl0IHBhc3NlcyBvdXQgb2Ygc2NvcGUuCi0JCQkgKi8KKwkJCW0tPm1f cGt0aGRyLmNzdW1fZmxhZ3MgJj0gfkNTVU1fREVMQVlfSVA7CisJCX0KIAogCQkvKgogCQkgKiBS ZWNvcmQgc3RhdGlzdGljcyBmb3IgdGhpcyBpbnRlcmZhY2UgYWRkcmVzcy4KQEAgLTU4OSw3ICs1 NzAsNyBAQCBwYXNzb3V0OgogCSAqIFRvbyBsYXJnZSBmb3IgaW50ZXJmYWNlOyBmcmFnbWVudCBp ZiBwb3NzaWJsZS4gSWYgc3VjY2Vzc2Z1bCwKIAkgKiBvbiByZXR1cm4sIG0gd2lsbCBwb2ludCB0 byBhIGxpc3Qgb2YgcGFja2V0cyB0byBiZSBzZW50LgogCSAqLwotCWVycm9yID0gaXBfZnJhZ21l bnQoaXAsICZtLCBtdHUsIGlmcC0+aWZfaHdhc3Npc3QsIHN3X2NzdW0pOworCWVycm9yID0gaXBf ZnJhZ21lbnQoaXAsICZtLCBtdHUsIGlmcC0+aWZfaHdhc3Npc3QpOwogCWlmIChlcnJvcikKIAkJ Z290byBiYWQ7CiAJZm9yICg7IG07IG0gPSBtMCkgewpAQCAtNjMzLDExICs2MTQsMTAgQEAgYmFk OgogICogY2hhaW4gb2YgZnJhZ21lbnRzIHRoYXQgc2hvdWxkIGJlIGZyZWVkIGJ5IHRoZSBjYWxs ZXIuCiAgKgogICogaWZfaHdhc3Npc3RfZmxhZ3MgaXMgdGhlIGh3IG9mZmxvYWQgY2FwYWJpbGl0 aWVzIChzZWUgaWZfZGF0YS5pZmlfaHdhc3Npc3QpCi0gKiBzd19jc3VtIGNvbnRhaW5zIHRoZSBk ZWxheWVkIGNoZWNrc3VtcyBmbGFncyAoZS5nLiwgQ1NVTV9ERUxBWV9JUCkuCiAgKi8KIGludAog aXBfZnJhZ21lbnQoc3RydWN0IGlwICppcCwgc3RydWN0IG1idWYgKiptX2ZyYWcsIGludCBtdHUs Ci0gICAgdV9sb25nIGlmX2h3YXNzaXN0X2ZsYWdzLCBpbnQgc3dfY3N1bSkKKyAgICB1X2xvbmcg aWZfaHdhc3Npc3RfZmxhZ3MpCiB7CiAJaW50IGVycm9yID0gMDsKIAlpbnQgaGxlbiA9IGlwLT5p cF9obCA8PCAyOwpAQCAtNzY1LDcgKzc0NSw3IEBAIHNtYXJ0X2ZyYWdfZmFpbHVyZToKIAkJbS0+ bV9wa3RoZHIuY3N1bV9mbGFncyA9IG0wLT5tX3BrdGhkci5jc3VtX2ZsYWdzOwogCQltaGlwLT5p cF9vZmYgPSBodG9ucyhtaGlwLT5pcF9vZmYpOwogCQltaGlwLT5pcF9zdW0gPSAwOwotCQlpZiAo c3dfY3N1bSAmIENTVU1fREVMQVlfSVApIHsKKwkJaWYgKG0tPm1fcGt0aGRyLmNzdW1fZmxhZ3Mg JiBDU1VNX0RFTEFZX0lQICYgfmlmX2h3YXNzaXN0X2ZsYWdzKSB7CiAJCQltaGlwLT5pcF9zdW0g PSBpbl9ja3N1bShtLCBtaGxlbik7CiAJCQltLT5tX3BrdGhkci5jc3VtX2ZsYWdzICY9IH5DU1VN X0RFTEFZX0lQOwogCQl9CkBAIC03ODgsNyArNzY4LDcgQEAgc21hcnRfZnJhZ19mYWlsdXJlOgog CWlwLT5pcF9vZmYgfD0gSVBfTUY7CiAJaXAtPmlwX29mZiA9IGh0b25zKGlwLT5pcF9vZmYpOwog CWlwLT5pcF9zdW0gPSAwOwotCWlmIChzd19jc3VtICYgQ1NVTV9ERUxBWV9JUCkgeworCWlmICht MC0+bV9wa3RoZHIuY3N1bV9mbGFncyAmIENTVU1fREVMQVlfSVAgJiB+aWZfaHdhc3Npc3RfZmxh Z3MpIHsKIAkJaXAtPmlwX3N1bSA9IGluX2Nrc3VtKG0wLCBobGVuKTsKIAkJbTAtPm1fcGt0aGRy LmNzdW1fZmxhZ3MgJj0gfkNTVU1fREVMQVlfSVA7CiAJfQpkaWZmIC0tZ2l0IGEvc3lzL25ldGlu ZXQvaXBfdmFyLmggYi9zeXMvbmV0aW5ldC9pcF92YXIuaAppbmRleCAxOWU5YjdlLi44Y2JjNzRk IDEwMDY0NAotLS0gYS9zeXMvbmV0aW5ldC9pcF92YXIuaAorKysgYi9zeXMvbmV0aW5ldC9pcF92 YXIuaApAQCAtMTk1LDcgKzE5NSw3IEBAIGludAlpcF9jdGxvdXRwdXQoc3RydWN0IHNvY2tldCAq LCBzdHJ1Y3Qgc29ja29wdCAqc29wdCk7CiB2b2lkCWlwX2RyYWluKHZvaWQpOwogdm9pZAlpcF9m aW5pKHZvaWQgKnh0cCk7CiBpbnQJaXBfZnJhZ21lbnQoc3RydWN0IGlwICppcCwgc3RydWN0IG1i dWYgKiptX2ZyYWcsIGludCBtdHUsCi0JICAgIHVfbG9uZyBpZl9od2Fzc2lzdF9mbGFncywgaW50 IHN3X2NzdW0pOworCSAgICB1X2xvbmcgaWZfaHdhc3Npc3RfZmxhZ3MpOwogdm9pZAlpcF9mb3J3 YXJkKHN0cnVjdCBtYnVmICptLCBpbnQgc3JjcnQpOwogdm9pZAlpcF9pbml0KHZvaWQpOwogZXh0 ZXJuIGludAotLSAKMS43LjguMwoK --047d7b1605050ef51d04ccbe1a2c-- From owner-freebsd-net@FreeBSD.ORG Tue Oct 23 20:16:48 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5EBBFD54; Tue, 23 Oct 2012 20:16:48 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0C44D8FC16; Tue, 23 Oct 2012 20:16:47 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so5309689oag.13 for ; Tue, 23 Oct 2012 13:16:47 -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=ZLp8+tdDfRPD1wMfPGkJjGljxdOW6Ad2mrEUHiYyPBs=; b=rZV4ivzKr4zIccWkb5Ae5drjQUdp06m8iCP8C5aj08uTFkhpkMhkLanj4BRBAThU1F B/b+fKAr8/NKXLsMuZ2Gl5MEbak53+UMqPPVNZO1HG+UuU1p2UjgMxRygX4HL+cUjmwU 3lXq4l91A50vOCDVkYFOBI80U9IF2nVV/2t+uTDI22QCzpdlcE5JOm7+nj29zdxLaEZZ SAX1jTR/OqSbLZ4AYkHfG/4d22AER51t5bWhJ7L3BUgjc66eNOxAsP9wXfFUC6uK+nNE 8QiGj/tGrQxZIuT65pxkfFA1532vUKmzGAonm2s2v2GLDAksVybWhS3Uk47W1T5Pc/Re iWZw== MIME-Version: 1.0 Received: by 10.182.95.205 with SMTP id dm13mr11183973obb.9.1351023407275; Tue, 23 Oct 2012 13:16:47 -0700 (PDT) Received: by 10.76.143.33 with HTTP; Tue, 23 Oct 2012 13:16:47 -0700 (PDT) In-Reply-To: References: <201210230840.q9N8e038066538@freefall.freebsd.org> Date: Tue, 23 Oct 2012 13:16:47 -0700 Message-ID: Subject: Re: kern/92880: [libc] [patch] almost rewritten inet_network(3) function From: Garrett Cooper To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Andrey Simonenko , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 20:16:48 -0000 On Tue, Oct 23, 2012 at 10:37 AM, Adrian Chadd wrote: > ... don't suppose you want to throw this into a test case somewhere in the tree? > > The new ATF import would be ideal for this. :) Indeed. The only problem is that bsd.test.mk is missing so you can't really integrate testcases into the build *quite* yet, but I can work with you to write up/review the testcase; I have the missing ATF/test infrastructure pieces committed to perforce (but I broke things working on adding fixtures) and will be migrating everything over to github soon (so that way my hacking is more isolated and more collaboration can occur). Thanks! -Garrett From owner-freebsd-net@FreeBSD.ORG Tue Oct 23 22:57:03 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5133D9D7; Tue, 23 Oct 2012 22:57:03 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 97B438FC0C; Tue, 23 Oct 2012 22:57:02 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so3445409lag.13 for ; Tue, 23 Oct 2012 15:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=dBVxftSDWviWS7AWvyiCnHX9kNivgUSTmwH7+yztROM=; b=OPQBs+1nIvyZ0xlQ7+oLheaK+iNzDll+/zS64USGpml4L/HzWREN35yZgCeZnWw88m W4fRnEE7GsEUdHwg0TCxTGmznHxyctGCFkaCimYmONtFbzoU/JbrhJibVdIUNAo1Sirb iitnbxV4R1QwLRLUbcdCvGX9C3AUZ9ZjDksHLYV6YJ58TG5FkaVTIMdXgcPhe+mb10Ro Z6Jq7pr+oJA8zFzjAiX0w/vC2CBuRIsEqz5AvZh/dImXoLapfsio7Yq7gCFcIyFFMlxz ZtNHAxaTKis91Rm23pHLw2+5dTXrHfNwXNHp+YfZSap7i4is1HMCLgJCZcInlkdToX3L z/xg== MIME-Version: 1.0 Received: by 10.152.124.83 with SMTP id mg19mr12685574lab.6.1351033021343; Tue, 23 Oct 2012 15:57:01 -0700 (PDT) Received: by 10.112.43.232 with HTTP; Tue, 23 Oct 2012 15:57:01 -0700 (PDT) Date: Tue, 23 Oct 2012 15:57:01 -0700 Message-ID: Subject: ixgb TSO performance degrades by ~30% between 7.4 and 8.2/9.0/9.1 From: Garrett Cooper To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Jack F Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 22:57:03 -0000 Hi, Doing some poking around at the ixgb driver with a card I have at $work using netperf and two machines hooked up over crossover, I discovered that while ixgb's throughput performance was fantastic on 7.3/7.4, thoughput performance of the card is degraded on 8.2/9.0/9.1 by ~30% (9400Mbps on 7.4 -> 6294Mbps on 9.0 for example). LRO performance on the other hand is fantastic and doesn't degrade with the card across FreeBSD versions. Performance remains constant with ixgb across 8.2/9.0/9.1. I didn't observe the CPU usage. More details: The machines are hooked up in the following configuration: ----------------------- -------------------- | Machine 1 | cxgb | <- 10Gbit fibre -> | ix1 | Machine 2 | ----------------------- --------------------- Machine Configuration: The card in Machine 2 is an 82599EB card according to pciconf -lv. /boot/loader.conf tunables (most of these are set according to 9.x defaults in order to establish a sane baseline): kern.ipc.nmbjumbo9=262144 kern.ipc.nmbjumbo16=262144 kern.ipc.nmbclusters=262144 kern.ipc.nmbjumbop=262144 kern.ipc.maxsockbuf=2097152 /etc/sysctl.conf tunables: net.inet.tcp.recvspace=65536 net.inet.tcp.recvspace_inc=16384 net.inet.tcp.recvspace_max=2097152 net.inet.tcp.sendspace=32768 net.inet.tcp.sendbuf_max=2097152 net.inet.tcp.sendbuf_inc=8192 Kernel Config: Machine 1 is running a custom version of FreeBSD. The version has been constant over the course of my testing. Can give vague details on the config, but can't give some specific details. Machine 2 is running 7.4/8.2/9.0/9.1 with a GENERIC kernel. Networking configuration: - Machine 1 has an IPv4 address of 10.10.10.1; IPv6 is not configured. The interface mtu is 1500. - Machine 2 has an IPv4 address of 10.10.10.2; IPv6 is not configured. The interface mtu is 1500. Netperf configuration: - netserver is run on both machines; I don't add any additional arguments to the netserver invocation so it just goes off and forks. - netperf is run like: netperf -cCjt TCP_STREAM -H I was wondering if this was a known issue and/or others had seen similar problems with this card. I haven't gone into profiling the kernel yet with DTrace, but if no one gets back to me before sometime later on this week/next week that will be my next course of action for tracking down the source of the performance problem. Thanks! -Garrett From owner-freebsd-net@FreeBSD.ORG Tue Oct 23 23:13:50 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B1E02EA1; Tue, 23 Oct 2012 23:13:50 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id ED3FE8FC12; Tue, 23 Oct 2012 23:13:49 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so3453687lag.13 for ; Tue, 23 Oct 2012 16:13:48 -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=P3w0/p7VEdDyVZMVeYuVaZnrI6twgMimhOFiwsjoNPE=; b=0dUb9aqH2uN4Ug8R/VlWmB0VxMXIyh1FOtnOlYfgGD+KY0s5I56s/zyq53jIB+5FK4 avfO4iT5QFI0B8wHJ4TuJNHf2o1slghOeasC6cLY2lwSkvV25o/BgE1PH8AaGKVpmjWN HFDDM8ZYmzEuTJ/Kq7lJ/+GF6gYAehrDIoIzJNTXmRcipe3EFWssw5aba2ZtpVAcGKiW +UvhaBBO8ywr8h6g150D5TVsD40pXG4MYUfyWjmG0FYFjr0azrFzywg7fjyQ6FMRWECx 4LawsQ5yLzVZi987owZ7Sfdrf4dcAaIRxQjqlH2D0wLpmJZxnsM0oCqpP5u0kfGVXi/c JHMA== MIME-Version: 1.0 Received: by 10.112.47.129 with SMTP id d1mr5523367lbn.115.1351034028824; Tue, 23 Oct 2012 16:13:48 -0700 (PDT) Received: by 10.112.43.232 with HTTP; Tue, 23 Oct 2012 16:13:48 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Oct 2012 16:13:48 -0700 Message-ID: Subject: Re: ixgb TSO performance degrades by ~30% between 7.4 and 8.2/9.0/9.1 From: Garrett Cooper To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Jack F Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 23:13:50 -0000 On Tue, Oct 23, 2012 at 3:57 PM, Garrett Cooper wrote: > Hi, > > Doing some poking around at the ixgb driver with a card I have at > $work using netperf and two machines hooked up over crossover, I > discovered that while ixgb's throughput performance was fantastic on > 7.3/7.4, thoughput performance of the card is degraded on 8.2/9.0/9.1 > by ~30% (9400Mbps on 7.4 -> 6294Mbps on 9.0 for example). LRO > performance on the other hand is fantastic and doesn't degrade with > the card across FreeBSD versions. Performance remains constant with > ixgb across 8.2/9.0/9.1. I didn't observe the CPU usage. > > More details: > > The machines are hooked up in the following configuration: > > ----------------------- -------------------- > | Machine 1 | cxgb | <- 10Gbit fibre -> | ix1 | Machine 2 | > ----------------------- --------------------- > > Machine Configuration: > > The card in Machine 2 is an 82599EB card according to pciconf -lv. > > /boot/loader.conf tunables (most of these are set according to 9.x > defaults in order to establish a sane baseline): > > kern.ipc.nmbjumbo9=262144 > kern.ipc.nmbjumbo16=262144 > kern.ipc.nmbclusters=262144 > kern.ipc.nmbjumbop=262144 > kern.ipc.maxsockbuf=2097152 > > /etc/sysctl.conf tunables: > > net.inet.tcp.recvspace=65536 > net.inet.tcp.recvspace_inc=16384 > net.inet.tcp.recvspace_max=2097152 > net.inet.tcp.sendspace=32768 > net.inet.tcp.sendbuf_max=2097152 > net.inet.tcp.sendbuf_inc=8192 > > Kernel Config: > > Machine 1 is running a custom version of FreeBSD. The version has been > constant over the course of my testing. Can give vague details on the > config, but can't give some specific details. > Machine 2 is running 7.4/8.2/9.0/9.1 with a GENERIC kernel. > > Networking configuration: > > - Machine 1 has an IPv4 address of 10.10.10.1; IPv6 is not configured. > The interface mtu is 1500. > - Machine 2 has an IPv4 address of 10.10.10.2; IPv6 is not configured. > The interface mtu is 1500. > > Netperf configuration: > > - netserver is run on both machines; I don't add any additional > arguments to the netserver invocation so it just goes off and forks. > - netperf is run like: netperf -cCjt TCP_STREAM -H > > I was wondering if this was a known issue and/or others had seen > similar problems with this card. I haven't gone into profiling the > kernel yet with DTrace, but if no one gets back to me before sometime > later on this week/next week that will be my next course of action for > tracking down the source of the performance problem. A couple more notes: 1. We're not using Intel SFP modules -- they're Finisar based (shouldn't matter, but I know that some Intel NICs are incredibly picky when it comes to SFP modules). 2. The performance on 8.2 is actually worse than on 9.x: ~5700Mbps. Thanks! -Garrett From owner-freebsd-net@FreeBSD.ORG Tue Oct 23 23:32:54 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 15F745B7 for ; Tue, 23 Oct 2012 23:32:54 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6F48B8FC14 for ; Tue, 23 Oct 2012 23:32:53 +0000 (UTC) Received: (qmail 90046 invoked from network); 24 Oct 2012 01:10:48 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 24 Oct 2012 01:10:48 -0000 Message-ID: <50872919.90701@networx.ch> Date: Wed, 24 Oct 2012 01:32:41 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Garrett Cooper Subject: Re: ixgb TSO performance degrades by ~30% between 7.4 and 8.2/9.0/9.1 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jack F Vogel , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 23:32:54 -0000 On 24.10.2012 01:13, Garrett Cooper wrote: > On Tue, Oct 23, 2012 at 3:57 PM, Garrett Cooper wrote: >> Hi, >> >> Doing some poking around at the ixgb driver with a card I have at >> $work using netperf and two machines hooked up over crossover, I >> discovered that while ixgb's throughput performance was fantastic on >> 7.3/7.4, thoughput performance of the card is degraded on 8.2/9.0/9.1 >> by ~30% (9400Mbps on 7.4 -> 6294Mbps on 9.0 for example). LRO >> performance on the other hand is fantastic and doesn't degrade with >> the card across FreeBSD versions. Performance remains constant with >> ixgb across 8.2/9.0/9.1. I didn't observe the CPU usage. >> >> More details: >> >> The machines are hooked up in the following configuration: >> >> ----------------------- -------------------- >> | Machine 1 | cxgb | <- 10Gbit fibre -> | ix1 | Machine 2 | >> ----------------------- --------------------- >> >> Machine Configuration: >> >> The card in Machine 2 is an 82599EB card according to pciconf -lv. >> >> /boot/loader.conf tunables (most of these are set according to 9.x >> defaults in order to establish a sane baseline): >> >> kern.ipc.nmbjumbo9=262144 >> kern.ipc.nmbjumbo16=262144 >> kern.ipc.nmbclusters=262144 >> kern.ipc.nmbjumbop=262144 >> kern.ipc.maxsockbuf=2097152 >> >> /etc/sysctl.conf tunables: >> >> net.inet.tcp.recvspace=65536 >> net.inet.tcp.recvspace_inc=16384 >> net.inet.tcp.recvspace_max=2097152 >> net.inet.tcp.sendspace=32768 >> net.inet.tcp.sendbuf_max=2097152 >> net.inet.tcp.sendbuf_inc=8192 >> >> Kernel Config: >> >> Machine 1 is running a custom version of FreeBSD. The version has been >> constant over the course of my testing. Can give vague details on the >> config, but can't give some specific details. >> Machine 2 is running 7.4/8.2/9.0/9.1 with a GENERIC kernel. >> >> Networking configuration: >> >> - Machine 1 has an IPv4 address of 10.10.10.1; IPv6 is not configured. >> The interface mtu is 1500. >> - Machine 2 has an IPv4 address of 10.10.10.2; IPv6 is not configured. >> The interface mtu is 1500. >> >> Netperf configuration: >> >> - netserver is run on both machines; I don't add any additional >> arguments to the netserver invocation so it just goes off and forks. >> - netperf is run like: netperf -cCjt TCP_STREAM -H >> >> I was wondering if this was a known issue and/or others had seen >> similar problems with this card. I haven't gone into profiling the >> kernel yet with DTrace, but if no one gets back to me before sometime >> later on this week/next week that will be my next course of action for >> tracking down the source of the performance problem. > > A couple more notes: > > 1. We're not using Intel SFP modules -- they're Finisar based > (shouldn't matter, but I know that some Intel NICs are incredibly > picky when it comes to SFP modules). > 2. The performance on 8.2 is actually worse than on 9.x: ~5700Mbps. There have been a very large number of changes to our network stack between 7.4 and today. That makes it very difficult to pinpoint a specific change. First of all please test 10-current as well but make sure that you turn off WITNESS and INVARIANTS in your kernel config. Second there may be an issue with TSO and ixgb where TSO can cause packets that are a bit larger than 64K by the ethernet header size. ixgb DMA is set up for 64K all inclusive. While TSO did generate a IP valid packet it is arguably not very well digestable for the driver considering that 64K is a very magic number. TSO should reduce its largest packet size by max_linkhdr. A fix for that is in the works and will be available shortly. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Oct 23 23:45:36 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A953EB04; Tue, 23 Oct 2012 23:45:36 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id E7F0A8FC14; Tue, 23 Oct 2012 23:45:35 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id b5so929892lbd.13 for ; Tue, 23 Oct 2012 16:45:34 -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=ZmYJpjCi/HIcH13ORgtZbxl7BwDqXDOc3rlQXCXtwho=; b=eL9Y6wZKJ6wG4CL0NsFZVWSK1eQ+RTa834FWj2Ms9TeCpSXHi+VWLgmZTOJwhVya/k yRTswmmORBOQm4UtA/8cqOYLpBZrcIUNTWVySG7FtZkJqj+aYntwlGgikFNLBZI6I6pD CGIV5l+FEA+vRoTqhx767loWoP2zJeCWAbwobcVCn/9+W4nhLafz/u/J4dZmP0KIuOyP etENN0XRLV8LH1lsGxfagfn0RklMXXy9X+pCPfgMt2hxPF7RkAlgrzz5ysJxD3Rk98mD k5AAJUd9/MgY+sqcp65pMwr0Df3Syn8kjhBmkqC32hooTarDwpvEcvrFUZnzfeqc3uX/ sq+Q== MIME-Version: 1.0 Received: by 10.152.133.140 with SMTP id pc12mr12658596lab.53.1351035934573; Tue, 23 Oct 2012 16:45:34 -0700 (PDT) Received: by 10.112.43.232 with HTTP; Tue, 23 Oct 2012 16:45:34 -0700 (PDT) In-Reply-To: <50872919.90701@networx.ch> References: <50872919.90701@networx.ch> Date: Tue, 23 Oct 2012 16:45:34 -0700 Message-ID: Subject: Re: ixgb TSO performance degrades by ~30% between 7.4 and 8.2/9.0/9.1 From: Garrett Cooper To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 Cc: Jack F Vogel , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 23:45:36 -0000 On Tue, Oct 23, 2012 at 4:32 PM, Andre Oppermann wrote: ... >>> Doing some poking around at the ixgb driver with a card I have at >>> $work using netperf and two machines hooked up over crossover, I >>> discovered that while ixgb's throughput performance was fantastic on >>> 7.3/7.4, thoughput performance of the card is degraded on 8.2/9.0/9.1 >>> by ~30% (9400Mbps on 7.4 -> 6294Mbps on 9.0 for example). LRO >>> performance on the other hand is fantastic and doesn't degrade with >>> the card across FreeBSD versions. Performance remains constant with >>> ixgb across 8.2/9.0/9.1. I didn't observe the CPU usage. >>> >>> More details: >>> >>> The machines are hooked up in the following configuration: >>> >>> ----------------------- >>> -------------------- >>> | Machine 1 | cxgb | <- 10Gbit fibre -> | ix1 | Machine 2 | >>> ----------------------- >>> --------------------- >>> >>> Machine Configuration: >>> >>> The card in Machine 2 is an 82599EB card according to pciconf -lv. >>> >>> /boot/loader.conf tunables (most of these are set according to 9.x >>> defaults in order to establish a sane baseline): >>> >>> kern.ipc.nmbjumbo9=262144 >>> kern.ipc.nmbjumbo16=262144 >>> kern.ipc.nmbclusters=262144 >>> kern.ipc.nmbjumbop=262144 >>> kern.ipc.maxsockbuf=2097152 >>> >>> /etc/sysctl.conf tunables: >>> >>> net.inet.tcp.recvspace=65536 >>> net.inet.tcp.recvspace_inc=16384 >>> net.inet.tcp.recvspace_max=2097152 >>> net.inet.tcp.sendspace=32768 >>> net.inet.tcp.sendbuf_max=2097152 >>> net.inet.tcp.sendbuf_inc=8192 >>> >>> Kernel Config: >>> >>> Machine 1 is running a custom version of FreeBSD. The version has been >>> constant over the course of my testing. Can give vague details on the >>> config, but can't give some specific details. >>> Machine 2 is running 7.4/8.2/9.0/9.1 with a GENERIC kernel. >>> >>> Networking configuration: >>> >>> - Machine 1 has an IPv4 address of 10.10.10.1; IPv6 is not configured. >>> The interface mtu is 1500. >>> - Machine 2 has an IPv4 address of 10.10.10.2; IPv6 is not configured. >>> The interface mtu is 1500. >>> >>> Netperf configuration: >>> >>> - netserver is run on both machines; I don't add any additional >>> arguments to the netserver invocation so it just goes off and forks. >>> - netperf is run like: netperf -cCjt TCP_STREAM -H >>> >>> I was wondering if this was a known issue and/or others had seen >>> similar problems with this card. I haven't gone into profiling the >>> kernel yet with DTrace, but if no one gets back to me before sometime >>> later on this week/next week that will be my next course of action for >>> tracking down the source of the performance problem. >> >> >> A couple more notes: >> >> 1. We're not using Intel SFP modules -- they're Finisar based >> (shouldn't matter, but I know that some Intel NICs are incredibly >> picky when it comes to SFP modules). >> 2. The performance on 8.2 is actually worse than on 9.x: ~5700Mbps. > > There have been a very large number of changes to our network > stack between 7.4 and today. That makes it very difficult to > pinpoint a specific change. > > First of all please test 10-current as well but make sure that > you turn off WITNESS and INVARIANTS in your kernel config. > > Second there may be an issue with TSO and ixgb where TSO can > cause packets that are a bit larger than 64K by the ethernet > header size. ixgb DMA is set up for 64K all inclusive. While > TSO did generate a IP valid packet it is arguably not very well > digestable for the driver considering that 64K is a very magic > number. TSO should reduce its largest packet size by max_linkhdr. > A fix for that is in the works and will be available shortly. Ok. I'll give it a shot sometime this upcoming week to see if things improve (of course without INVARIANTS and WITNESS ;)..); I saw there were some changes in the works on CURRENT -- just haven't gotten around to testing that yet (melifaro and a few other folks have been working on performance and removing unnecessary locking too it seems). Thanks for the feedback! -Garrett From owner-freebsd-net@FreeBSD.ORG Tue Oct 23 23:58:20 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6C64BDD2; Tue, 23 Oct 2012 23:58:20 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id EB87F8FC16; Tue, 23 Oct 2012 23:58:19 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fw7so6215802vcb.13 for ; Tue, 23 Oct 2012 16:58:19 -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=rV5ATEA3Jkt1tvRgD73XFJnreTyXJaaDQRguXBmXaYY=; b=UG3N69mdtJHYWORbj91BrkSggRW+8n5alolGY7W7cncMl5SSCoRsrE4Fnn4VMfh0eQ WvsBv2RrBt3AULlju47fiCybfOcVr+M+u8M82BrC3vlQaX8g+dzXluNsrjmg2aN3qr75 Wn8jGY3MoDdHns4LVZNndpOQxVGFBjXZfUKtr6HaYQk9ZDBTeCGxRkksdD4G/0xSnGG2 wdNDGAWfjwU4X2vOAQ6ogjcH+51PumzX+DEGFu6d68nVOPBUvQnkZCtQk+KxpKhnvdoj FsrF8ZMrx+WvXK+LiZZHzEgJfPFwDVb1acTYLewIo4pA4ZgIqAz+YbkvXhLS5GfFdR3D dn5A== MIME-Version: 1.0 Received: by 10.220.226.67 with SMTP id iv3mr5181967vcb.57.1351036698910; Tue, 23 Oct 2012 16:58:18 -0700 (PDT) Received: by 10.58.68.8 with HTTP; Tue, 23 Oct 2012 16:58:18 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Oct 2012 16:58:18 -0700 Message-ID: Subject: Re: ixgb TSO performance degrades by ~30% between 7.4 and 8.2/9.0/9.1 From: Jack Vogel To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Jack F Vogel , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 23:58:20 -0000 It you mean the ixgbe driver please call it that, the IS an ixgb driver which is for VERY old PCI cards, from the context I assume you mean the newer hardware :) Jack On Tue, Oct 23, 2012 at 3:57 PM, Garrett Cooper wrote: > Hi, > > Doing some poking around at the ixgb driver with a card I have at > $work using netperf and two machines hooked up over crossover, I > discovered that while ixgb's throughput performance was fantastic on > 7.3/7.4, thoughput performance of the card is degraded on 8.2/9.0/9.1 > by ~30% (9400Mbps on 7.4 -> 6294Mbps on 9.0 for example). LRO > performance on the other hand is fantastic and doesn't degrade with > the card across FreeBSD versions. Performance remains constant with > ixgb across 8.2/9.0/9.1. I didn't observe the CPU usage. > > More details: > > The machines are hooked up in the following configuration: > > ----------------------- > -------------------- > | Machine 1 | cxgb | <- 10Gbit fibre -> | ix1 | Machine 2 | > ----------------------- > --------------------- > > Machine Configuration: > > The card in Machine 2 is an 82599EB card according to pciconf -lv. > > /boot/loader.conf tunables (most of these are set according to 9.x > defaults in order to establish a sane baseline): > > kern.ipc.nmbjumbo9=262144 > kern.ipc.nmbjumbo16=262144 > kern.ipc.nmbclusters=262144 > kern.ipc.nmbjumbop=262144 > kern.ipc.maxsockbuf=2097152 > > /etc/sysctl.conf tunables: > > net.inet.tcp.recvspace=65536 > net.inet.tcp.recvspace_inc=16384 > net.inet.tcp.recvspace_max=2097152 > net.inet.tcp.sendspace=32768 > net.inet.tcp.sendbuf_max=2097152 > net.inet.tcp.sendbuf_inc=8192 > > Kernel Config: > > Machine 1 is running a custom version of FreeBSD. The version has been > constant over the course of my testing. Can give vague details on the > config, but can't give some specific details. > Machine 2 is running 7.4/8.2/9.0/9.1 with a GENERIC kernel. > > Networking configuration: > > - Machine 1 has an IPv4 address of 10.10.10.1; IPv6 is not configured. > The interface mtu is 1500. > - Machine 2 has an IPv4 address of 10.10.10.2; IPv6 is not configured. > The interface mtu is 1500. > > Netperf configuration: > > - netserver is run on both machines; I don't add any additional > arguments to the netserver invocation so it just goes off and forks. > - netperf is run like: netperf -cCjt TCP_STREAM -H > > I was wondering if this was a known issue and/or others had seen > similar problems with this card. I haven't gone into profiling the > kernel yet with DTrace, but if no one gets back to me before sometime > later on this week/next week that will be my next course of action for > tracking down the source of the performance problem. > > Thanks! > -Garrett > From owner-freebsd-net@FreeBSD.ORG Wed Oct 24 00:01:22 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0EAE9EB1; Wed, 24 Oct 2012 00:01:22 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5828A8FC1B; Wed, 24 Oct 2012 00:01:21 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so3474907lag.13 for ; Tue, 23 Oct 2012 17:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=lapaKTo9ILgAtkfty+y6rCSWegvYV6STYr85tSmsAe4=; b=BQOsef7Xv2zpgIYT9mpi30O6DdHy95ot/O6Z613SMaNRNpyDiP+P2TGslmV3FDd/9H PXui5cywYA//XKPw6KjkFRux6rMVDQDPK0iEKAkHxFpMXpE0QpR0nJPuntFwAIMD4+5n DjMMF+GZg+x+PJXNT+XI8HjcPJyU37md1aaLYK/6dpht14uJwq0cIcaKJJR+PwKJL+3H t6Y3kHD7icpEzavb+LSOytsqWSIaYp3BllY8VsRcH+XUZhqwEi0nRX8TpgMMM1EEwfxg klexH3lSIe0x99LT3ywpjXQcDvn/ej7xgDj65+WVPiS9m6bp1HFGAZzNqApS3lI5Y3+F 343w== MIME-Version: 1.0 Received: by 10.112.42.201 with SMTP id q9mr5576255lbl.28.1351036880303; Tue, 23 Oct 2012 17:01:20 -0700 (PDT) Received: by 10.112.43.232 with HTTP; Tue, 23 Oct 2012 17:01:20 -0700 (PDT) Date: Tue, 23 Oct 2012 17:01:20 -0700 Message-ID: Subject: Re: ixgbe TSO performance degrades by ~30% between 7.4 and 8.2/9.0/9.1 From: Garrett Cooper To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: Jack F Vogel , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 00:01:22 -0000 On Tue, Oct 23, 2012 at 4:58 PM, Jack Vogel wrote: > It you mean the ixgbe driver please call it that, the IS an ixgb driver > which is for > VERY old PCI cards, from the context I assume you mean the newer hardware :) Yeah... I meant ixgbe. Subject line fixed :). Thanks! -Garrett > On Tue, Oct 23, 2012 at 3:57 PM, Garrett Cooper wrote: >> >> Hi, >> >> Doing some poking around at the ixgb driver with a card I have at >> $work using netperf and two machines hooked up over crossover, I >> discovered that while ixgb's throughput performance was fantastic on >> 7.3/7.4, thoughput performance of the card is degraded on 8.2/9.0/9.1 >> by ~30% (9400Mbps on 7.4 -> 6294Mbps on 9.0 for example). LRO >> performance on the other hand is fantastic and doesn't degrade with >> the card across FreeBSD versions. Performance remains constant with >> ixgb across 8.2/9.0/9.1. I didn't observe the CPU usage. >> >> More details: >> >> The machines are hooked up in the following configuration: >> >> ----------------------- >> -------------------- >> | Machine 1 | cxgb | <- 10Gbit fibre -> | ix1 | Machine 2 | >> ----------------------- >> --------------------- >> >> Machine Configuration: >> >> The card in Machine 2 is an 82599EB card according to pciconf -lv. >> >> /boot/loader.conf tunables (most of these are set according to 9.x >> defaults in order to establish a sane baseline): >> >> kern.ipc.nmbjumbo9=262144 >> kern.ipc.nmbjumbo16=262144 >> kern.ipc.nmbclusters=262144 >> kern.ipc.nmbjumbop=262144 >> kern.ipc.maxsockbuf=2097152 >> >> /etc/sysctl.conf tunables: >> >> net.inet.tcp.recvspace=65536 >> net.inet.tcp.recvspace_inc=16384 >> net.inet.tcp.recvspace_max=2097152 >> net.inet.tcp.sendspace=32768 >> net.inet.tcp.sendbuf_max=2097152 >> net.inet.tcp.sendbuf_inc=8192 >> >> Kernel Config: >> >> Machine 1 is running a custom version of FreeBSD. The version has been >> constant over the course of my testing. Can give vague details on the >> config, but can't give some specific details. >> Machine 2 is running 7.4/8.2/9.0/9.1 with a GENERIC kernel. >> >> Networking configuration: >> >> - Machine 1 has an IPv4 address of 10.10.10.1; IPv6 is not configured. >> The interface mtu is 1500. >> - Machine 2 has an IPv4 address of 10.10.10.2; IPv6 is not configured. >> The interface mtu is 1500. >> >> Netperf configuration: >> >> - netserver is run on both machines; I don't add any additional >> arguments to the netserver invocation so it just goes off and forks. >> - netperf is run like: netperf -cCjt TCP_STREAM -H >> >> I was wondering if this was a known issue and/or others had seen >> similar problems with this card. I haven't gone into profiling the >> kernel yet with DTrace, but if no one gets back to me before sometime >> later on this week/next week that will be my next course of action for >> tracking down the source of the performance problem. From owner-freebsd-net@FreeBSD.ORG Wed Oct 24 09:16:32 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD241BCE; Wed, 24 Oct 2012 09:16:32 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.kpi.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 66D6A8FC18; Wed, 24 Oct 2012 09:16:32 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.kpi.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1TQwlT-0001Ww-Gn; Wed, 24 Oct 2012 11:56:39 +0300 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id 6213C1CC1E; Wed, 24 Oct 2012 11:56:37 +0300 (EEST) Date: Wed, 24 Oct 2012 11:56:37 +0300 From: Andrey Simonenko To: Adrian Chadd Subject: Re: kern/92880: [libc] [patch] almost rewritten inet_network(3) function Message-ID: <20121024085637.GA57899@pm513-1.comsys.ntu-kpi.kiev.ua> References: <201210230840.q9N8e038066538@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 28-Apr-2011 07:11:12) X-Date: 2012-10-24 11:56:39 X-Connected-IP: 10.18.52.101:51438 X-Message-Linecount: 200 X-Body-Linecount: 183 X-Message-Size: 8404 X-Body-Size: 7626 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 09:16:32 -0000 On Tue, Oct 23, 2012 at 10:37:56AM -0700, Adrian Chadd wrote: > ... don't suppose you want to throw this into a test case somewhere in the tree? > This was the bug-followup to my PR [1], that was created because I needed own version of inet_network() for another my PR [2] and found out that the current version of inet_network() has mistakes and is not optimal. This bug-followup has inet_network_new() that is a rewritten implementation of inet_network(). This message was sent to the net@ mailing list, since this PR was assigned to freebsd-net. > The new ATF import would be ideal for this. :) I have not checked how ATF works yet, but I wrote socket/unix_cmsg that verifies correctness of AF_LOCAL control messages implementation. It cannot be used on recent versions, because changes from PR [3] were not committed yet. What do you think about lines pointed by "<---" where inet_network() and my implementation gives different results? [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92880 [2] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/136865 [3] http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/131567 > > > > Adrian > > On 23 October 2012 01:40, Andrey Simonenko wrote: > > The following reply was made to PR kern/92880; it has been noted by GNATS. > > > > From: Andrey Simonenko > > To: bug-followup@FreeBSD.org > > Cc: > > Subject: kern/92880: [libc] [patch] almost rewritten inet_network(3) function > > Date: Tue, 23 Oct 2012 11:36:04 +0300 > > > > I optimized inet_network() again. > > > > Difference between implementation of inet_network(3) from 9.1-PRERELEASE > > and my implementation. > > > > STRING INET_NETWORK INET_NETWORK_NEW > > "0x12" 0x00000012 0x00000012 > > "127.1" 0x00007f01 0x00007f01 > > "127.1.2.3" 0x7f010203 0x7f010203 > > "0x123456" INADDR_NONE INADDR_NONE > > "0x12.0x34" 0x00001234 0x00001234 > > "0x12.0x345" INADDR_NONE INADDR_NONE > > "1.2.3.4.5" INADDR_NONE INADDR_NONE > > "1..3.4" INADDR_NONE INADDR_NONE > > "." INADDR_NONE INADDR_NONE > > "1." INADDR_NONE INADDR_NONE > > ".1" INADDR_NONE INADDR_NONE > > "0x" 0x00000000 INADDR_NONE <--- > > "0" 0x00000000 0x00000000 > > "01.02.07.077" 0x0102073f 0x0102073f > > "0x1.23.045.0" 0x01172500 0x01172500 > > "" INADDR_NONE INADDR_NONE > > " " INADDR_NONE INADDR_NONE > > " f" INADDR_NONE INADDR_NONE > > "bar" INADDR_NONE INADDR_NONE > > "1.2bar" INADDR_NONE INADDR_NONE > > "1." INADDR_NONE INADDR_NONE > > "=CA=C3=D5=CB=C5=CE" INADDR_NONE INADDR_NONE > > "255.255.255.255" INADDR_NONE INADDR_NONE > > "x" INADDR_NONE INADDR_NONE > > "0X12" 0x00000012 0x00000012 > > "078" INADDR_NONE INADDR_NONE > > "1 bar" 0x00000001 INADDR_NONE <--- > > "127.0xabcd" INADDR_NONE INADDR_NONE > > "128" 0x00000080 0x00000080 > > "0.1.2" 0x00000102 0x00000102 > > "0xff.010.23.0xa0" 0xff0817a0 0xff0817a0 > > "x10" 0x00000010 INADDR_NONE <--- > > "X20" 0x00000020 INADDR_NONE <--- > > "x10.x20" 0x00001020 INADDR_NONE <--- > > "4294967297" 0x00000001 INADDR_NONE <--- > > "0x10000000f" 0x0000000f INADDR_NONE <--- > > "040000000003" 0x00000003 INADDR_NONE <--- > > > > #include > > #include > > > > #include > > #include > > > > #include > > #include > > #include > > #include > > #include > > #include > > > > static in_addr_t > > inet_network_new(const char *s) > > { > > u_int d, base, dots; > > in_addr_t addr, byte; > > u_char c; > > bool flag; > > > > addr =3D 0; > > dots =3D 0; > > for (;; ++s) { > > byte =3D 0; > > flag =3D false; > > if (*s =3D=3D '0') { > > ++s; > > if (*s =3D=3D 'x' || *s =3D=3D 'X') { > > ++s; > > base =3D 16; > > } else { > > base =3D 8; > > flag =3D true; > > } > > } else > > base =3D 10; > > for (; (c =3D *s) !=3D '\0'; ++s) { > > d =3D digittoint(c); > > if (c !=3D '0' && (d =3D=3D 0 || d >=3D base)) > > break; > > byte =3D byte * base + d; > > if (byte > UINT8_MAX) > > return (INADDR_NONE); > > flag =3D true; > > } > > if (!flag) > > return (INADDR_NONE); > > addr =3D (addr << 8) | byte; > > if (c !=3D '.') > > break; > > if (++dots =3D=3D 4) > > return (INADDR_NONE); > > } > > return (c =3D=3D '\0' ? addr : INADDR_NONE); > > } > > > > int > > main(void) > > { > > const char *const addr_str_tbl[] =3D { > > "0x12", "127.1", "127.1.2.3", "0x123456", "0x12.0x34", > > "0x12.0x345", "1.2.3.4.5", "1..3.4", ".", "1.", ".1", "0x", > > "0", "01.02.07.077", "0x1.23.045.0", "", " ", " f", "bar", > > "1.2bar", "1.", "=CA=C3=D5=CB=C5=CE", "255.255.255.255", "x", "0X12"= > > , "078", > > "1 bar", "127.0xabcd", "128", "0.1.2", "0xff.010.23.0xa0", > > "x10", "X20", "x10.x20", "4294967297", "0x10000000f", > > "040000000003", NULL }; > > const char *const *addr_str; > > size_t len; > > in_addr_t addr1, addr2; > > > > printf("STRING\t\t\tINET_NETWORK\tINET_NETWORK_NEW\n"); > > for (addr_str =3D addr_str_tbl; *addr_str !=3D NULL; ++addr_str) { > > printf("\"%s\"", *addr_str); > > len =3D strlen(*addr_str) + 2; > > if (len < 8) > > printf("\t\t\t"); > > else if (len < 16) > > printf("\t\t"); > > else > > printf("\t"); > > addr1 =3D inet_network(*addr_str); > > if (addr1 =3D=3D INADDR_NONE) > > printf("INADDR_NONE\t"); > > else > > printf("0x%08x\t", addr1); > > addr2 =3D inet_network_new(*addr_str); > > if (addr2 =3D=3D INADDR_NONE) > > printf("INADDR_NONE"); > > else > > printf("0x%08x", addr2); > > if (addr1 !=3D addr2) > > printf("\t<---"); > > printf("\n"); > > } > > return (0); > > } From owner-freebsd-net@FreeBSD.ORG Wed Oct 24 10:50:01 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E917BBCB for ; Wed, 24 Oct 2012 10:50:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.FreeBSD.org [8.8.178.135]) by mx1.freebsd.org (Postfix) with ESMTP id B729A8FC0C for ; Wed, 24 Oct 2012 10:50:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q9OAo1n1018984 for ; Wed, 24 Oct 2012 10:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q9OAo1Km018983; Wed, 24 Oct 2012 10:50:01 GMT (envelope-from gnats) Date: Wed, 24 Oct 2012 10:50:01 GMT Message-Id: <201210241050.q9OAo1Km018983@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Andrew Filonov Subject: Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Andrew Filonov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 10:50:02 -0000 The following reply was made to PR kern/172113; it has been noted by GNATS. From: Andrew Filonov To: bug-followup@FreeBSD.org, egrosbein@rdtc.ru Cc: jvf@freebsd.org Subject: Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type Date: Wed, 24 Oct 2012 14:49:41 +0400 --000e0ce03f94006e2c04cccbd81d Content-Type: multipart/alternative; boundary=000e0ce03f94006e2504cccbd81b --000e0ce03f94006e2504cccbd81b Content-Type: text/plain; charset=ISO-8859-1 We have same problem with HP DL160g6 servers with RELENG8. Simpliest workaround for me is if_igb_load="YES" in /boot/loader.conf Patch, corrected for 8.3 included --000e0ce03f94006e2504cccbd81b Content-Type: text/html; charset=ISO-8859-1 We have same problem with HP DL160g6 servers with RELENG8.

Simpliest workaround for me is
if_igb_load="YES" in /boot/loader.conf

Patch, corrected for 8.3 included


--000e0ce03f94006e2504cccbd81b-- --000e0ce03f94006e2c04cccbd81d Content-Type: text/plain; charset=US-ASCII; name="igb-path-8.txt" Content-Disposition: attachment; filename="igb-path-8.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h8obei320 LS0tIHN5cy9kZXYvZTEwMDAvaWZfaWdiLmMub3JpZwkyMDEyLTEwLTA5IDIyOjAyOjA1LjAwMDAw MDAwMCArMDQwMAorKysgc3lzL2Rldi9lMTAwMC9pZl9pZ2IuYwkyMDEyLTEwLTI0IDE0OjMzOjEz LjAwMDAwMDAwMCArMDQwMApAQCAtMTMwNSw5ICsxMzA1LDYgQEAKIAkvKiBEb24ndCBsb3NlIHBy b21pc2N1b3VzIHNldHRpbmdzICovCiAJaWdiX3NldF9wcm9taXNjKGFkYXB0ZXIpOwogCi0JaWZw LT5pZl9kcnZfZmxhZ3MgfD0gSUZGX0RSVl9SVU5OSU5HOwotCWlmcC0+aWZfZHJ2X2ZsYWdzICY9 IH5JRkZfRFJWX09BQ1RJVkU7Ci0KIAljYWxsb3V0X3Jlc2V0KCZhZGFwdGVyLT50aW1lciwgaHos IGlnYl9sb2NhbF90aW1lciwgYWRhcHRlcik7CiAJZTEwMDBfY2xlYXJfaHdfY250cnNfYmFzZV9n ZW5lcmljKCZhZGFwdGVyLT5odyk7CiAKQEAgLTEzMzMsNiArMTMzMCw5IEBACiAJLyogU2V0IEVu ZXJneSBFZmZpY2llbnQgRXRoZXJuZXQgKi8KIAogCWUxMDAwX3NldF9lZWVfaTM1MCgmYWRhcHRl ci0+aHcpOworCisJaWZwLT5pZl9kcnZfZmxhZ3MgfD0gSUZGX0RSVl9SVU5OSU5HOworCWlmcC0+ aWZfZHJ2X2ZsYWdzICY9IH5JRkZfRFJWX09BQ1RJVkU7CiB9CiAKIHN0YXRpYyB2b2lkCkBAIC0x NTQ3LDYgKzE1NDcsMTEgQEAKIAlFMTAwMF9XUklURV9SRUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9F SU1DLCBxdWUtPmVpbXMpOwogCSsrcXVlLT5pcnFzOwogCisJaWYgKCEoYWRhcHRlci0+aWZwLT5p Zl9kcnZfZmxhZ3MgJiBJRkZfRFJWX1JVTk5JTkcpKSB7CisJCXJldHVybjsKKwl9CisJbW9yZV9y eCA9IGlnYl9yeGVvZihxdWUsIGFkYXB0ZXItPnJ4X3Byb2Nlc3NfbGltaXQsIE5VTEwpOworCiAJ SUdCX1RYX0xPQ0sodHhyKTsKIAlpZ2JfdHhlb2YodHhyKTsKICNpZiBfX0ZyZWVCU0RfdmVyc2lv biA+PSA4MDAwMDAKQEAgLTE1NjAsOCArMTU2NSw2IEBACiAjZW5kaWYKIAlJR0JfVFhfVU5MT0NL KHR4cik7CiAKLQltb3JlX3J4ID0gaWdiX3J4ZW9mKHF1ZSwgYWRhcHRlci0+cnhfcHJvY2Vzc19s aW1pdCwgTlVMTCk7Ci0KIAlpZiAoYWRhcHRlci0+ZW5hYmxlX2FpbSA9PSBGQUxTRSkKIAkJZ290 byBub19jYWxjOwogCS8qCg== --000e0ce03f94006e2c04cccbd81d-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 24 15:07:27 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 980B2B45; Wed, 24 Oct 2012 15:07:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6AD028FC0C; Wed, 24 Oct 2012 15:07:27 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A3FE5B95E; Wed, 24 Oct 2012 11:07:26 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: ixgb TSO performance degrades by ~30% between 7.4 and 8.2/9.0/9.1 Date: Wed, 24 Oct 2012 11:07:10 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201210241107.10775.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 24 Oct 2012 11:07:26 -0400 (EDT) Cc: Garrett Cooper , Jack F Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 15:07:27 -0000 On Tuesday, October 23, 2012 6:57:01 pm Garrett Cooper wrote: > Hi, > > Doing some poking around at the ixgb driver with a card I have at > $work using netperf and two machines hooked up over crossover, I > discovered that while ixgb's throughput performance was fantastic on > 7.3/7.4, thoughput performance of the card is degraded on 8.2/9.0/9.1 > by ~30% (9400Mbps on 7.4 -> 6294Mbps on 9.0 for example). LRO > performance on the other hand is fantastic and doesn't degrade with > the card across FreeBSD versions. Performance remains constant with > ixgb across 8.2/9.0/9.1. I didn't observe the CPU usage. Interesting, maybe as an experiment try hacking the #ifdef's to use if_start() instead of if_transmit(). -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Oct 24 15:38:03 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 24D3CA31; Wed, 24 Oct 2012 15:38:03 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 84F748FC17; Wed, 24 Oct 2012 15:38:02 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id v11so854856vbm.13 for ; Wed, 24 Oct 2012 08:38: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=839wrh4XoHBVv5sYcuOXLEZFxQ28yDREvDkRNaRtICc=; b=iTYRGqQZlOcct4EimPZonbXWbQAXPa8Fi+7M3Q7U3FhvTxBScNs0aCnfNBybnyvrWb 5Fd70PUhTTcw4bMHw2N2fTbIt405szNwpM+qqbXHH6UhBkYruCv/tN/WM0jnr3dSmz8r RwVb59jhSaZnXWQJOdBlUhUFE+yMvramxo7HcRDF8mOArrQvOrxof1c76WO98zz3EM8V xhooVvWb19kRVxsv8BX/g3jKcTZ8VsvHMoS3JdgEX29aX5feKSDaRuzk0nxBtqNFJPjY ZEqiRD8jgM5xWBDjLZ9WUyLSTB0ZYAZJ7nqPcIf3UjVTGtgDrMkUqVlSGG03FzhIhjTZ bO+w== MIME-Version: 1.0 Received: by 10.52.65.147 with SMTP id x19mr21953510vds.113.1351093081623; Wed, 24 Oct 2012 08:38:01 -0700 (PDT) Received: by 10.58.68.8 with HTTP; Wed, 24 Oct 2012 08:38:01 -0700 (PDT) In-Reply-To: <201210241107.10775.jhb@freebsd.org> References: <201210241107.10775.jhb@freebsd.org> Date: Wed, 24 Oct 2012 08:38:01 -0700 Message-ID: Subject: Re: ixgb TSO performance degrades by ~30% between 7.4 and 8.2/9.0/9.1 From: Jack Vogel To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Garrett Cooper , freebsd-net@freebsd.org, Jack F Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 15:38:03 -0000 On Wed, Oct 24, 2012 at 8:07 AM, John Baldwin wrote: > On Tuesday, October 23, 2012 6:57:01 pm Garrett Cooper wrote: > > Hi, > > > > Doing some poking around at the ixgb driver with a card I have at > > $work using netperf and two machines hooked up over crossover, I > > discovered that while ixgb's throughput performance was fantastic on > > 7.3/7.4, thoughput performance of the card is degraded on 8.2/9.0/9.1 > > by ~30% (9400Mbps on 7.4 -> 6294Mbps on 9.0 for example). LRO > > performance on the other hand is fantastic and doesn't degrade with > > the card across FreeBSD versions. Performance remains constant with > > ixgb across 8.2/9.0/9.1. I didn't observe the CPU usage. > > Interesting, maybe as an experiment try hacking the #ifdef's to use > if_start() instead of if_transmit(). > > That's not a bad idea, I have had cases, for instance some UDP intensive loads, where I found better performance with the old interface. This was one reason why I had wanted to change the ifdef's to not just be an OS version level, making either more easily selectable. Jack From owner-freebsd-net@FreeBSD.ORG Wed Oct 24 15:51:41 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 21F89856 for ; Wed, 24 Oct 2012 15:51:41 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7226F8FC1D for ; Wed, 24 Oct 2012 15:51:40 +0000 (UTC) Received: (qmail 33676 invoked from network); 24 Oct 2012 17:29:28 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 24 Oct 2012 17:29:28 -0000 Message-ID: <50880EE4.2090502@freebsd.org> Date: Wed, 24 Oct 2012 17:53:08 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: vadim_nuclight@mail.ru Subject: Re: maxusers (thus mbuf etc.) autotuning capped at 384 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 15:51:41 -0000 On 24.10.2012 16:26, Vadim Goncharov wrote: > Hi, > > We have 'maxusers' tunable which affects many other tunables, e.g. number of > network mbuf/clusters which is often too low on current machines. The mbuf/cluster limit can be rethought as well. Since it all comes out of UMA and is not pre-allocated we could simply set it to "physpages / 2" or "physpages / 4 * 3". Relating it to maxusers isn't meaningful anymore. In the same area the kern.maxfiles, kern.maxfilesperproc and kern.ipc.maxsockets need rethinking as well. For modern systems and busy servers it should be at least in the 100k area, if not more. It should have some magic value per GB physical memory as well. You have to make sure that this is true though: kern.maxfiles > kern.ipc.maxsockets > kern.maxfilesperproc > There is code in sys/kern/subr_param.c: > > if (maxusers == 0) { > maxusers = physpages / (2 * 1024 * 1024 / PAGE_SIZE); > if (maxusers < 32) > maxusers = 32; > if (maxusers > 384) > maxusers = 384; > } > > It was capped to 384 for i386 KVM size limits in r89769, so that amd64, not > constrained to 1Gb KVA, suffers from this. I suspect that 384 may be wrong even > for i386 today, but let's be conservative and limit maxusers to 384 per 1 Gb of > KVM, like this: > > #define _MAX_MAXUSERS (((VM_MAX_KERNEL_ADDRESS - \ > KERNBASE) / (8 * 1024 * 1024)) * 3) > > if (maxusers == 0) { > maxusers = physpages / (2 * 1024 * 1024 / PAGE_SIZE); > if (maxusers < 32) > maxusers = 32; > if (maxusers > _MAX_MAXUSERS) > maxusers = _MAX_MAXUSERS; > } > #undef _MAX_MAXUSERS This is very round-about. Why don't you simply write 384 per GB in there directly? Thinking of it these "magic" whatever-per-GB value definitions should be next to each other in param.h or some other suitable place. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Oct 24 18:16:17 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 30B11364; Wed, 24 Oct 2012 18:16:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id F21B38FC08; Wed, 24 Oct 2012 18:16:16 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5FDA2B95E; Wed, 24 Oct 2012 14:16:16 -0400 (EDT) From: John Baldwin To: Jack Vogel Subject: Re: ixgb TSO performance degrades by ~30% between 7.4 and 8.2/9.0/9.1 Date: Wed, 24 Oct 2012 14:11:49 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <201210241107.10775.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201210241411.49656.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 24 Oct 2012 14:16:16 -0400 (EDT) Cc: Garrett Cooper , freebsd-net@freebsd.org, Jack F Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 18:16:17 -0000 On Wednesday, October 24, 2012 11:38:01 am Jack Vogel wrote: > On Wed, Oct 24, 2012 at 8:07 AM, John Baldwin wrote: > > > On Tuesday, October 23, 2012 6:57:01 pm Garrett Cooper wrote: > > > Hi, > > > > > > Doing some poking around at the ixgb driver with a card I have at > > > $work using netperf and two machines hooked up over crossover, I > > > discovered that while ixgb's throughput performance was fantastic on > > > 7.3/7.4, thoughput performance of the card is degraded on 8.2/9.0/9.1 > > > by ~30% (9400Mbps on 7.4 -> 6294Mbps on 9.0 for example). LRO > > > performance on the other hand is fantastic and doesn't degrade with > > > the card across FreeBSD versions. Performance remains constant with > > > ixgb across 8.2/9.0/9.1. I didn't observe the CPU usage. > > > > Interesting, maybe as an experiment try hacking the #ifdef's to use > > if_start() instead of if_transmit(). > > > > > That's not a bad idea, I have had cases, for instance some UDP intensive > loads, where I found better performance with the old interface. This was one > reason why I had wanted to change the ifdef's to not just be an OS version > level, making either more easily selectable. In this case, if using if_start() helps, then I'd like Garrett to try my current ixgbe patch from the other thread as well to reduce concurrent RX processing. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Oct 24 18:33:40 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ABEF2EFD; Wed, 24 Oct 2012 18:33:40 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 49DEF8FC0A; Wed, 24 Oct 2012 18:33:40 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so995317oag.13 for ; Wed, 24 Oct 2012 11:33:38 -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=LmLIy2tCo9d7Uczg4G6t6d7Y+NzL3q1DqxD8yyBJPXk=; b=lrzn+JB7Mh2kxCIzveN5lp+bhxsLXUbHN/fs5w3B/+zg62PhmO/Ev55ng3HecWX3n6 EEJ221BD4850TgSNJA54mPybBYoxK3lZ/oTB8Ze7xtRDsFvYVg/bacsO+X37U7efe33m wjoOuVNfsJbnHUb+W33K8SZaNb9qjiCXIfsGW2Q+iL6ip03l/TeZVSrDVIzuVWLmbOa4 bxV4jU4DkPY0D3jBA8fo7d/IcsKR7urvJPBsXCx5wcvYZEweKL0v/1NQ6xRc803dwHAk erZ8dhj8Ai0eGTIjWbFlqQJPi3A/Ch8GI+2/kN6fY9T2iyffMKQNc+HoDHINsf1flONu 3V2A== MIME-Version: 1.0 Received: by 10.182.150.34 with SMTP id uf2mr13749739obb.66.1351103618904; Wed, 24 Oct 2012 11:33:38 -0700 (PDT) Received: by 10.76.143.33 with HTTP; Wed, 24 Oct 2012 11:33:38 -0700 (PDT) In-Reply-To: <201210241411.49656.jhb@freebsd.org> References: <201210241107.10775.jhb@freebsd.org> <201210241411.49656.jhb@freebsd.org> Date: Wed, 24 Oct 2012 11:33:38 -0700 Message-ID: Subject: Re: ixgb TSO performance degrades by ~30% between 7.4 and 8.2/9.0/9.1 From: Garrett Cooper To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: Jack F Vogel , freebsd-net@freebsd.org, Jack Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 18:33:41 -0000 On Wed, Oct 24, 2012 at 11:11 AM, John Baldwin wrote: ... > In this case, if using if_start() helps, then I'd like Garrett to try > my current ixgbe patch from the other thread as well to reduce concurrent > RX processing. Sounds good. I'll let you guys know when I have everything setup again. Thanks! -Garrett From owner-freebsd-net@FreeBSD.ORG Wed Oct 24 22:32:33 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A642E791; Wed, 24 Oct 2012 22:32:33 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.FreeBSD.org [8.8.178.135]) by mx1.freebsd.org (Postfix) with ESMTP id 768DC8FC0C; Wed, 24 Oct 2012 22:32:33 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q9OMWXQn078481; Wed, 24 Oct 2012 22:32:33 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q9OMWXev078477; Wed, 24 Oct 2012 22:32:33 GMT (envelope-from linimon) Date: Wed, 24 Oct 2012 22:32:33 GMT Message-Id: <201210242232.q9OMWXev078477@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/172985: [patch] [ip6] lltable leak when adding and removing IPv6 addresses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 22:32:33 -0000 Synopsis: [patch] [ip6] lltable leak when adding and removing IPv6 addresses Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Oct 24 22:32:26 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=172985 From owner-freebsd-net@FreeBSD.ORG Thu Oct 25 08:06:43 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 920FD6DB for ; Thu, 25 Oct 2012 08:06:43 +0000 (UTC) (envelope-from remi.pauchet@netasq.com) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id D81A58FC1C for ; Thu, 25 Oct 2012 08:06:42 +0000 (UTC) Received: from [10.2.9.2] (unknown [91.212.116.2]) by work.netasq.com (Postfix) with ESMTPSA id E572227054D6 for ; Thu, 25 Oct 2012 10:06:40 +0200 (CEST) From: =?iso-8859-1?Q?R=E9mi_Pauchet?= Content-Type: multipart/signed; boundary="Apple-Mail=_2CDDC20C-82C3-41DC-9607-42B13FA6F0F1"; protocol="application/pkcs7-signature"; micalg=sha1 Subject: panic ixgbevf / SMP under high network load Date: Thu, 25 Oct 2012 10:06:40 +0200 Message-Id: To: freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 08:06:43 -0000 --Apple-Mail=_2CDDC20C-82C3-41DC-9607-42B13FA6F0F1 Content-Type: multipart/mixed; boundary="Apple-Mail=_E43D5A19-1FB8-4DA3-AD2B-AF15B1B08D3C" --Apple-Mail=_E43D5A19-1FB8-4DA3-AD2B-AF15B1B08D3C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi I'm testing network performance of FreeBSD using vmware esxi 5.1 with = SR-IOV I'm using FreeBSD 8.3 kernel GENERIC, 4 cpus, ixgbevf driver with an = Intel 82599EB dual 10 Gbps network interface After a few seconds of udp ipv4 load (5Gbps x2, frame size 700), I have = the following panic : (kgdb) bt #0 doadump () at pcpu.h:224 #1 0xffffffff8060ab90 in boot (howto=3D260) at = /usr/src/sys/kern/kern_shutdown.c:441 #2 0xffffffff8060b031 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:614 #3 0xffffffff80900b80 in trap_fatal (frame=3D0xc, eva=3DVariable "eva" = is not available. ) at /usr/src/sys/amd64/amd64/trap.c:825 #4 0xffffffff80900ed1 in trap_pfault (frame=3D0xffffff800016a620, = usermode=3D0) at /usr/src/sys/amd64/amd64/trap.c:741 #5 0xffffffff8090138f in trap (frame=3D0xffffff800016a620) at = /usr/src/sys/amd64/amd64/trap.c:478 #6 0xffffffff808e88e4 in calltrap () at = /usr/src/sys/amd64/amd64/exception.S:228 #7 0xffffffff80667ef7 in m_copym (m=3D0x0, off0=3D1500, len=3D1480, = wait=3D1) at /usr/src/sys/kern/uipc_mbuf.c:542 #8 0xffffffff8071c8c2 in ip_fragment (ip=3D0xffffff0001a3700e, = m_frag=3D0xffffff800016a838, mtu=3DVariable "mtu" is not available. ) at /usr/src/sys/netinet/ip_output.c:819 #9 0xffffffff8071d93a in ip_output (m=3D0xffffff00019fd900, = opt=3DVariable "opt" is not available. ) at /usr/src/sys/netinet/ip_output.c:650 #10 0xffffffff8071a13a in ip_forward (m=3D0xffffff00019fd900, = srcrt=3DVariable "srcrt" is not available. ) at /usr/src/sys/netinet/ip_input.c:1521 #11 0xffffffff8071b77c in ip_input (m=3D0xffffff00019fd900) at = /usr/src/sys/netinet/ip_input.c:729 #12 0xffffffff806c652e in netisr_dispatch_src (proto=3D1, = source=3DVariable "source" is not available. ) at /usr/src/sys/net/netisr.c:859 #13 0xffffffff806bc5cd in ether_demux (ifp=3D0xffffff000168e800, = m=3D0xffffff00019fd900) at /usr/src/sys/net/if_ethersubr.c:896 #14 0xffffffff806bc9d7 in ether_input (ifp=3D0xffffff000168e800, = m=3D0xffffff00019fd900) at /usr/src/sys/net/if_ethersubr.c:755 #15 0xffffffff803ee03e in ixv_rxeof (que=3D0xffffff0001643880, = count=3D117) at /usr/src/sys/dev/ixgbe/ixv.c:3256 #16 0xffffffff803ef50b in ixv_handle_que (context=3DVariable "context" = is not available. ) at /usr/src/sys/dev/ixgbe/ixv.c:983 #17 0xffffffff806496d5 in taskqueue_run_locked = (queue=3D0xffffff0001698200) at /usr/src/sys/kern/subr_taskqueue.c:250 #18 0xffffffff8064986e in taskqueue_thread_loop (arg=3DVariable "arg" is = not available. ) at /usr/src/sys/kern/subr_taskqueue.c:387 #19 0xffffffff805dfc9f in fork_exit (callout=3D0xffffffff80649820 = , arg=3D0xffffff00016438d8, = frame=3D0xffffff800016ac50) at /usr/src/sys/kern/kern_fork.c:876 #20 0xffffffff808e8e2e in fork_trampoline () at = /usr/src/sys/amd64/amd64/exception.S:602 I have no issue with only one cpu (but low network performance) Please find the dmesg in attachment Regards, R=E9mi Pauchet --Apple-Mail=_E43D5A19-1FB8-4DA3-AD2B-AF15B1B08D3C Content-Disposition: attachment; filename=dmesg.txt Content-Type: text/plain; x-unix-mode=0644; name="dmesg.txt" Content-Transfer-Encoding: quoted-printable Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.3-RELEASE #0: Fri Oct 5 11:38:23 CEST 2012 root@bsd:/usr/obj/usr/src/sys/GENERIC amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU W3680 @ 3.33GHz (3324.21-MHz = K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0x206c2 Family =3D 6 Model =3D 2c = Stepping =3D 2 = Features=3D0xfa3fbff = Features2=3D0x82982203 AMD Features=3D0x28100800 AMD Features2=3D0x1 TSC: P-state invariant real memory =3D 1073741824 (1024 MB) avail memory =3D 1016238080 (969 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 4 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi_hpet0: iomem 0xfed00000-0xfed003ff on = acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 ixgbe_probe: begin ixgbe_probe: begin pcib1: at device 1.0 on pci0 pci1: on pcib1 ixgbe_probe: begin isab0: at device 7.0 on pci0 isa0: on isab0 ixgbe_probe: begin atapci0: port = 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x10c0-0x10cf at device 7.1 on pci0 ata0: at channel 0 on atapci0 ata0: [ITHREAD] ata1: at channel 1 on atapci0 ata1: [ITHREAD] ixgbe_probe: begin pci0: at device 7.3 (no driver attached) ixgbe_probe: begin pci0: at device 7.7 (no driver attached) ixgbe_probe: begin vgapci0: port 0x10d0-0x10df mem = 0xd8000000-0xdbffffff,0xd0800000-0xd0ffffff irq 16 at device 15.0 on = pci0 ixgbe_probe: begin mpt0: port 0x1400-0x14ff mem = 0xd0040000-0xd005ffff,0xd0020000-0xd003ffff irq 17 at device 16.0 on = pci0 mpt0: [ITHREAD] mpt0: MPI Version=3D1.2.0.0 ixgbe_probe: begin pcib2: at device 17.0 on pci0 pci2: on pcib2 ixgbe_probe: begin em0: port = 0x2000-0x203f mem 0xd1020000-0xd103ffff,0xd1000000-0xd100ffff irq 18 at = device 0.0 on pci2 em0: Memory Access and/or Bus Master bits were not set! em0: [FILTER] em0: Ethernet address: 00:0c:29:5b:2a:ab ixgbe_probe: begin pcib3: at device 21.0 on pci0 pci3: on pcib3 ixgbe_probe: begin ix0: mem 0xd2404000-0xd2407fff,0xd2400000-0xd2403fff at device 0.0 on = pci3 ix0: Using MSIX interrupts with 2 vectors ix0: [ITHREAD] ix0: [ITHREAD] ix0: Ethernet address: 00:0c:29:5b:2a:10 ixgbe_probe: begin pcib4: at device 21.1 on pci0 pci4: on pcib4 ixgbe_probe: begin pcib5: at device 21.2 on pci0 pci5: on pcib5 ixgbe_probe: begin pcib6: at device 21.3 on pci0 pci6: on pcib6 ixgbe_probe: begin pcib7: at device 21.4 on pci0 pci7: on pcib7 ixgbe_probe: begin pcib8: at device 21.5 on pci0 pci8: on pcib8 ixgbe_probe: begin pcib9: at device 21.6 on pci0 pci9: on pcib9 ixgbe_probe: begin pcib10: at device 21.7 on pci0 pci10: on pcib10 ixgbe_probe: begin pcib11: at device 22.0 on pci0 pci11: on pcib11 ixgbe_probe: begin ix1: mem 0xd2504000-0xd2507fff,0xd2500000-0xd2503fff at device 0.0 on = pci11 ix1: Using MSIX interrupts with 2 vectors ix1: [ITHREAD] ix1: [ITHREAD] ix1: Ethernet address: 00:0c:29:5b:2a:11 ixgbe_probe: begin pcib12: at device 22.1 on pci0 pci12: on pcib12 ixgbe_probe: begin pcib13: at device 22.2 on pci0 pci13: on pcib13 ixgbe_probe: begin pcib14: at device 22.3 on pci0 pci14: on pcib14 ixgbe_probe: begin pcib15: at device 22.4 on pci0 pci15: on pcib15 ixgbe_probe: begin pcib16: at device 22.5 on pci0 pci16: on pcib16 ixgbe_probe: begin pcib17: at device 22.6 on pci0 pci17: on pcib17 ixgbe_probe: begin pcib18: at device 22.7 on pci0 pci18: on pcib18 ixgbe_probe: begin pcib19: at device 23.0 on pci0 pci19: on pcib19 ixgbe_probe: begin pcib20: at device 23.1 on pci0 pci20: on pcib20 ixgbe_probe: begin pcib21: at device 23.2 on pci0 pci21: on pcib21 ixgbe_probe: begin pcib22: at device 23.3 on pci0 pci22: on pcib22 ixgbe_probe: begin pcib23: at device 23.4 on pci0 pci23: on pcib23 ixgbe_probe: begin pcib24: at device 23.5 on pci0 pci24: on pcib24 ixgbe_probe: begin pcib25: at device 23.6 on pci0 pci25: on pcib25 ixgbe_probe: begin pcib26: at device 23.7 on pci0 pci26: on pcib26 ixgbe_probe: begin pcib27: at device 24.0 on pci0 pci27: on pcib27 ixgbe_probe: begin pcib28: at device 24.1 on pci0 pci28: on pcib28 ixgbe_probe: begin pcib29: at device 24.2 on pci0 pci29: on pcib29 ixgbe_probe: begin pcib30: at device 24.3 on pci0 pci30: on pcib30 ixgbe_probe: begin pcib31: at device 24.4 on pci0 pci31: on pcib31 ixgbe_probe: begin pcib32: at device 24.5 on pci0 pci32: on pcib32 ixgbe_probe: begin pcib33: at device 24.6 on pci0 pci33: on pcib33 ixgbe_probe: begin pcib34: at device 24.7 on pci0 pci34: on pcib34 acpi_acad0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on = acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 qpi0: on motherboard orm0: at iomem = 0xc0000-0xc7fff,0xca000-0xcafff,0xdc000-0xdffff,0xe0000-0xe7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 acpi_throttle0: on cpu0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 acpi_throttle2: on cpu2 acpi_throttle2: failed to attach P_CNT device_attach: acpi_throttle2 attach returned 6 acpi_throttle3: on cpu3 acpi_throttle3: failed to attach P_CNT device_attach: acpi_throttle3 attach returned 6 Timecounters tick every 10.000 msec acd0: DVDR at ata1-master = UDMA33=20 da0 at mpt0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device=20 da0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) da0: Command Queueing enabled da0: 8192MB (16777216 512 byte sectors: 255H 63S/T 1044C) SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/da0s1a WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted VMware memory control driver initialized Fatal trap 12: page fault while in kernel mode cpuid =3D 2; apic id =3D 02 fault virtual address =3D 0x18 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff80667ef7 stack pointer =3D 0x28:0xffffff800016a6d0 frame pointer =3D 0x28:0xffffff800016a730 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 0 (ix0 que) trap number =3D 12 panic: page fault cpuid =3D 2 KDB: stack backtrace: #0 0xffffffff8063de2e at kdb_backtrace+0x5e #1 0xffffffff8060b047 at panic+0x187 #2 0xffffffff80900b80 at trap_fatal+0x290 #3 0xffffffff80900ed1 at trap_pfault+0x201 #4 0xffffffff8090138f at trap+0x3df #5 0xffffffff808e88e4 at calltrap+0x8 #6 0xffffffff8071c8c2 at ip_fragment+0x132 #7 0xffffffff8071d93a at ip_output+0xd7a #8 0xffffffff8071a13a at ip_forward+0x2ea #9 0xffffffff8071b77c at ip_input+0x52c #10 0xffffffff806c652e at netisr_dispatch_src+0x7e #11 0xffffffff806bc5cd at ether_demux+0x14d #12 0xffffffff806bc9d7 at ether_input+0x197 #13 0xffffffff803ee03e at ixv_rxeof+0x19e #14 0xffffffff803ef50b at ixv_handle_que+0x9b #15 0xffffffff806496d5 at taskqueue_run_locked+0x85 #16 0xffffffff8064986e at taskqueue_thread_loop+0x4e #17 0xffffffff805dfc9f at fork_exit+0x11f Uptime: 1m10s Dumping 89 out of 1008 MB: Fatal trap 12: page fault while in kernel mode cpuid =3D 2; apic id =3D 02 fault virtual address =3D 0x18 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff80667ef7 stack pointer =3D 0x28:0xffffff80001866d0 frame pointer =3D 0x28:0xffffff8000186730 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 0 (ix1 que) trap number =3D 12 panic: page fault cpuid =3D 2 Fatal trap 12: page fault while in kernel mode cpuid =3D 3; apic id =3D 03 fault virtual address =3D 0x18 fault code =3D supervisor write data, page not present instruction pointer =3D 0x20:0xffffffff803edf6a stack pointer =3D 0x28:0xffffff8000165a40 frame pointer =3D 0x28:0xffffff8000165af0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 12 (irq256: ix0:que 0) trap number =3D 12 interrupt storm detected on "irq258:"; throttling interrupt source interrupt storm detected on "irq258:"; throttling interrupt source panic: bufwrite: buffer is not busy??? cpuid =3D 2 ..18%interrupt storm detected on "irq258:"; throttling interrupt source interrupt storm detected on "irq258:"; throttling interrupt source ..36%interrupt storm detected on "irq258:"; throttling interrupt source interrupt storm detected on "irq258:"; throttling interrupt source ..54%interrupt storm detected on "irq258:"; throttling interrupt source interrupt storm detected on "irq258:"; throttling interrupt source ..72%interrupt storm detected on "irq258:"; throttling interrupt source interrupt storm detected on "irq258:"; throttling interrupt source ..90%interrupt storm detected on "irq258:"; throttling interrupt source Dump complete Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.3-RELEASE #0: Fri Oct 5 11:38:23 CEST 2012 root@bsd:/usr/obj/usr/src/sys/GENERIC amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU W3680 @ 3.33GHz (3324.21-MHz = K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0x206c2 Family =3D 6 Model =3D 2c = Stepping =3D 2 = Features=3D0xfa3fbff = Features2=3D0x82982203 AMD Features=3D0x28100800 AMD Features2=3D0x1 TSC: P-state invariant real memory =3D 1073741824 (1024 MB) avail memory =3D 1016238080 (969 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 4 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi_hpet0: iomem 0xfed00000-0xfed003ff on = acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 ixgbe_probe: begin ixgbe_probe: begin pcib1: at device 1.0 on pci0 pci1: on pcib1 ixgbe_probe: begin isab0: at device 7.0 on pci0 isa0: on isab0 ixgbe_probe: begin atapci0: port = 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x10c0-0x10cf at device 7.1 on pci0 ata0: at channel 0 on atapci0 ata0: [ITHREAD] ata1: at channel 1 on atapci0 ata1: [ITHREAD] ixgbe_probe: begin pci0: at device 7.3 (no driver attached) ixgbe_probe: begin pci0: at device 7.7 (no driver attached) ixgbe_probe: begin vgapci0: port 0x10d0-0x10df mem = 0xd8000000-0xdbffffff,0xd0800000-0xd0ffffff irq 16 at device 15.0 on = pci0 ixgbe_probe: begin mpt0: port 0x1400-0x14ff mem = 0xd0040000-0xd005ffff,0xd0020000-0xd003ffff irq 17 at device 16.0 on = pci0 mpt0: [ITHREAD] mpt0: MPI Version=3D1.2.0.0 ixgbe_probe: begin pcib2: at device 17.0 on pci0 pci2: on pcib2 ixgbe_probe: begin em0: port = 0x2000-0x203f mem 0xd1020000-0xd103ffff,0xd1000000-0xd100ffff irq 18 at = device 0.0 on pci2 em0: Memory Access and/or Bus Master bits were not set! em0: [FILTER] em0: Ethernet address: 00:0c:29:5b:2a:ab ixgbe_probe: begin pcib3: at device 21.0 on pci0 pci3: on pcib3 ixgbe_probe: begin ix0: mem 0xd2404000-0xd2407fff,0xd2400000-0xd2403fff at device 0.0 on = pci3 ix0: Using MSIX interrupts with 2 vectors ix0: [ITHREAD] ix0: [ITHREAD] ix0: Ethernet address: 00:0c:29:5b:2a:10 ixgbe_probe: begin pcib4: at device 21.1 on pci0 pci4: on pcib4 ixgbe_probe: begin pcib5: at device 21.2 on pci0 pci5: on pcib5 ixgbe_probe: begin pcib6: at device 21.3 on pci0 pci6: on pcib6 ixgbe_probe: begin pcib7: at device 21.4 on pci0 pci7: on pcib7 ixgbe_probe: begin pcib8: at device 21.5 on pci0 pci8: on pcib8 ixgbe_probe: begin pcib9: at device 21.6 on pci0 pci9: on pcib9 ixgbe_probe: begin pcib10: at device 21.7 on pci0 pci10: on pcib10 ixgbe_probe: begin pcib11: at device 22.0 on pci0 pci11: on pcib11 ixgbe_probe: begin ix1: mem 0xd2504000-0xd2507fff,0xd2500000-0xd2503fff at device 0.0 on = pci11 ix1: Using MSIX interrupts with 2 vectors ix1: [ITHREAD] ix1: [ITHREAD] ix1: Ethernet address: 00:0c:29:5b:2a:11 ixgbe_probe: begin pcib12: at device 22.1 on pci0 pci12: on pcib12 ixgbe_probe: begin pcib13: at device 22.2 on pci0 pci13: on pcib13 ixgbe_probe: begin pcib14: at device 22.3 on pci0 pci14: on pcib14 ixgbe_probe: begin pcib15: at device 22.4 on pci0 pci15: on pcib15 ixgbe_probe: begin pcib16: at device 22.5 on pci0 pci16: on pcib16 ixgbe_probe: begin pcib17: at device 22.6 on pci0 pci17: on pcib17 ixgbe_probe: begin pcib18: at device 22.7 on pci0 pci18: on pcib18 ixgbe_probe: begin pcib19: at device 23.0 on pci0 pci19: on pcib19 ixgbe_probe: begin pcib20: at device 23.1 on pci0 pci20: on pcib20 ixgbe_probe: begin pcib21: at device 23.2 on pci0 pci21: on pcib21 ixgbe_probe: begin pcib22: at device 23.3 on pci0 pci22: on pcib22 ixgbe_probe: begin pcib23: at device 23.4 on pci0 pci23: on pcib23 ixgbe_probe: begin pcib24: at device 23.5 on pci0 pci24: on pcib24 ixgbe_probe: begin pcib25: at device 23.6 on pci0 pci25: on pcib25 ixgbe_probe: begin pcib26: at device 23.7 on pci0 pci26: on pcib26 ixgbe_probe: begin pcib27: at device 24.0 on pci0 pci27: on pcib27 ixgbe_probe: begin pcib28: at device 24.1 on pci0 pci28: on pcib28 ixgbe_probe: begin pcib29: at device 24.2 on pci0 pci29: on pcib29 ixgbe_probe: begin pcib30: at device 24.3 on pci0 pci30: on pcib30 ixgbe_probe: begin pcib31: at device 24.4 on pci0 pci31: on pcib31 ixgbe_probe: begin pcib32: at device 24.5 on pci0 pci32: on pcib32 ixgbe_probe: begin pcib33: at device 24.6 on pci0 pci33: on pcib33 ixgbe_probe: begin pcib34: at device 24.7 on pci0 pci34: on pcib34 acpi_acad0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on = acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 qpi0: on motherboard orm0: at iomem = 0xc0000-0xc7fff,0xca000-0xcafff,0xdc000-0xdffff,0xe0000-0xe7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 acpi_throttle0: on cpu0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 acpi_throttle2: on cpu2 acpi_throttle2: failed to attach P_CNT device_attach: acpi_throttle2 attach returned 6 acpi_throttle3: on cpu3 acpi_throttle3: failed to attach P_CNT device_attach: acpi_throttle3 attach returned 6 Timecounters tick every 10.000 msec acd0: DVDR at ata1-master = UDMA33=20 da0 at mpt0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device=20 da0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) da0: Command Queueing enabled da0: 8192MB (16777216 512 byte sectors: 255H 63S/T 1044C) SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/da0s1a WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /tmp: mount pending error: blocks 16 files 4 WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted VMware memory control driver initialized em0: promiscuous mode enabled em0: promiscuous mode disabled em0: promiscuous mode enabled em0: promiscuous mode disabled em0: promiscuous mode enabled em0: promiscuous mode disabled --Apple-Mail=_E43D5A19-1FB8-4DA3-AD2B-AF15B1B08D3C-- --Apple-Mail=_2CDDC20C-82C3-41DC-9607-42B13FA6F0F1-- From owner-freebsd-net@FreeBSD.ORG Thu Oct 25 14:29:58 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A562C48 for ; Thu, 25 Oct 2012 14:29:58 +0000 (UTC) (envelope-from remi.pauchet@netasq.com) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id AB8638FC14 for ; Thu, 25 Oct 2012 14:29:57 +0000 (UTC) Received: from [10.2.9.2] (unknown [91.212.116.2]) by work.netasq.com (Postfix) with ESMTPSA id 52B1A27057AF; Thu, 25 Oct 2012 16:29:55 +0200 (CEST) Subject: Re: ixgbe and ixgbevf drivers are not working in virtualization environment Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_1E577B5D-420A-42CA-B1BA-931D84D734FB"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?R=E9mi_Pauchet?= In-Reply-To: Date: Thu, 25 Oct 2012 16:29:53 +0200 Message-Id: <70DCE61F-E1B9-445F-A3F6-BC90646FA2AE@netasq.com> References: <792D5931-19E7-4239-A3E8-5D2BC90F03FD@netasq.com> To: Jack Vogel X-Mailer: Apple Mail (2.1283) X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 14:29:58 -0000 --Apple-Mail=_1E577B5D-420A-42CA-B1BA-931D84D734FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 more informations about the SR-IOV issue. The problem is that the link is not updated in the virtual machine (VF = driver). ie: I start the VM with my fiber unplugged, the vf link is "no carrier". I plug the fiber, the link stays in state "no carrier". If I reboot the vm, I get the active link.=20 I reproduce the issue with esxi 5.1 and xenserver 6=20 On other hand, I still haven't managed to get an active link with VMWare = DirectPath. Regards, R=E9mi Le 17 oct. 2012 =E0 09:42, R=E9mi Pauchet a =E9crit : > Hi >=20 > My interface is configured, UP and running and I still can't get a = link >=20 > Can you help me with this issue ? >=20 > Regards, > R=E9mi >=20 >=20 > Le 12 oct. 2012 =E0 09:38, R=E9mi Pauchet a =E9crit : >=20 >> Hi, >>=20 >> Unfortunately not: >>=20 >> ix0: flags=3D8843 metric 0 = mtu 1500 >> = options=3D401bb >> ether 00:e0:ed:1c:99:4e >> inet 172.16.255.254 netmask 0xffff0000 broadcast 172.16.255.255 >> inet6 fe80::2e0:edff:fe1c:994e%ix0 prefixlen 64 scopeid 0x2=20 >> nd6 options=3D29 >> media: Ethernet autoselect >> status: no carrier >> ix1: flags=3D8843 metric 0 = mtu 1500 >> = options=3D401bb >> ether 00:e0:ed:1c:99:4f >> inet 172.17.255.254 netmask 0xffff0000 broadcast 172.17.255.255 >> inet6 fe80::2e0:edff:fe1c:994f%ix1 prefixlen 64 scopeid 0x3=20 >> nd6 options=3D29 >> media: Ethernet autoselect >> status: no carrier >>=20 >> Regards, >> R=E9mi >>=20 >> Le 11 oct. 2012 =E0 18:25, Jack Vogel a =E9crit : >>=20 >>> The ixgbe device will not get link until you have run init, so = assign it an address or just do an ifconfig up. >>>=20 >>> I have never used the driver using a passthru type setup but I = believe its been done successfully if >>> memory serves. >>>=20 >>> Jack >>>=20 >>>=20 >>> On Thu, Oct 11, 2012 at 8:39 AM, R=E9mi Pauchet = wrote: >>> Hi, >>>=20 >>> I'm trying to use the ixgbe (10Gb) driver in a FreeBSD virtual = machine on an esxi 5 using DirectPath (PCI Passthrough) and the card is = detected, but I can't get a link (status: no carrier) >>>=20 >>> ix0: mem 0xd2420000-0xd243ffff,0xd2400000-0xd2403fff irq 18 at device = 0.0 on pci3 >>>=20 >>> ix0: flags=3D8802 metric 0 mtu 1500 >>> = options=3D401bb >>> ether 00:e0:ed:1c:99:4e >>> nd6 options=3D29 >>> media: Ethernet autoselect >>> status: no carrier >>>=20 >>> I have also tested with XenServer 6, using SR-IOV (ixgbevf driver) = with the same result: the driver is loading, but no link detected. >>>=20 >>> In both case (VMWare DirectPath and XenServer SR-IOV), I tested = Linux with success. >>>=20 >>>=20 >>> The card is an Intel 82599EB, the motherboard is an Intel X58 = (supermicro X8ST3) with a Xeon W3680 and I've tested FreeBSD 8.3 and 9.0 >>>=20 >>> I've found a forum thread with the same issue: = http://forums.freebsd.org/showthread.php?t=3D29855 and no answer :) >>>=20 >>>=20 >>> Please find in attachment the dmesg (boot -v) with the ix driver = compiled with DEBUG flags using vmware. >>>=20 >>>=20 >>> Can anyone provide feedback about this issue ? >>>=20 >>> Regards, >>> R=E9mi Pauchet >>>=20 >>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_1E577B5D-420A-42CA-B1BA-931D84D734FB-- From owner-freebsd-net@FreeBSD.ORG Thu Oct 25 14:50:05 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BAF7E5F3 for ; Thu, 25 Oct 2012 14:50:05 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from aussmtpmrkpc120.us.dell.com (aussmtpmrkpc120.us.dell.com [143.166.82.159]) by mx1.freebsd.org (Postfix) with ESMTP id 8BF738FC08 for ; Thu, 25 Oct 2012 14:50:05 +0000 (UTC) X-Loopcount0: from 64.238.244.148 X-IronPort-AV: E=Sophos;i="4.80,648,1344229200"; d="scan'208";a="8199081" Message-ID: <5089519B.9060801@vangyzen.net> Date: Thu, 25 Oct 2012 09:50:03 -0500 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120822 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: [patch] Review: Fix Tahi "Redirected On-link" Test Case References: <50857210.3090200@vangyzen.net> In-Reply-To: <50857210.3090200@vangyzen.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 14:50:05 -0000 On 10/22/2012 11:19, Eric van Gyzen wrote: > Bjoern and net@: > > I would appreciate your review and comments on the following patches. > > http://vangyzen.net/FreeBSD/patches/redir_onlink_8_rev1.diff > http://vangyzen.net/FreeBSD/patches/redir_onlink_9_rev1.diff > http://vangyzen.net/FreeBSD/patches/redir_onlink_10_rev1.diff > > Thanks in advance, > > Eric > > ==== > > Fix the Redirected On-Link test cases in the Tahi IPv6 Ready Logo > Phase 2 test suite. > > On receipt of a redirect message, install an interface route for the > redirected destination. On removal of the corresponding Neighbor > Cache entry, remove the interface route. > > This requires changes in rtredirect_fib() to cope with an AF_LINK > address for the gateway and with the absence of RTF_GATEWAY. > > Unrelated to the above, fix a recursion on the radix node head lock > triggered by the Redirected to Alternate Router test cases. > > All Section 2 (Neighbor Discovery) test cases pass on 10-CURRENT and > 9-STABLE. (8-STABLE pending) All Section 2 (Neighbor Discovery) test cases pass on 8-STABLE, too. To clarify, the following test cases all passed. > Other test cases: > > * the RTF_MODIFIED case, with IPv4 and IPv6 (using a > RTF_HOST|RTF_GATEWAY route for the destination) > > * the redirected-to-self case, with IPv4 and IPv6 > > * a valid IPv4 redirect > > All testing was done with WITNESS and INVARIANTS. > > Submitted by: Eric van Gyzen , > Mark Kelley , > Terence Telkamp com> > Sponsored by: Dell, Inc. > PR: kern/152791 From owner-freebsd-net@FreeBSD.ORG Thu Oct 25 16:40:35 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 18AE659F for ; Thu, 25 Oct 2012 16:40:35 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 6A94B8FC17 for ; Thu, 25 Oct 2012 16:40:34 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q9PGeVTk005524; Thu, 25 Oct 2012 20:40:31 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q9PGeV2h005522; Thu, 25 Oct 2012 20:40:31 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 25 Oct 2012 20:40:31 +0400 From: Gleb Smirnoff To: R?mi Pauchet Subject: Re: panic ixgbevf / SMP under high network load Message-ID: <20121025164031.GA70741@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 16:40:35 -0000 On Thu, Oct 25, 2012 at 10:06:40AM +0200, R?mi Pauchet wrote: R> I'm testing network performance of FreeBSD using vmware esxi 5.1 with SR-IOV R> R> I'm using FreeBSD 8.3 kernel GENERIC, 4 cpus, ixgbevf driver with an Intel 82599EB dual 10 Gbps network interface R> R> After a few seconds of udp ipv4 load (5Gbps x2, frame size 700), I have the following panic : R> R> (kgdb) bt R> #0 doadump () at pcpu.h:224 R> #1 0xffffffff8060ab90 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:441 R> #2 0xffffffff8060b031 in panic (fmt=Variable "fmt" is not available. R> ) at /usr/src/sys/kern/kern_shutdown.c:614 R> #3 0xffffffff80900b80 in trap_fatal (frame=0xc, eva=Variable "eva" is not available. R> ) at /usr/src/sys/amd64/amd64/trap.c:825 R> #4 0xffffffff80900ed1 in trap_pfault (frame=0xffffff800016a620, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:741 R> #5 0xffffffff8090138f in trap (frame=0xffffff800016a620) at /usr/src/sys/amd64/amd64/trap.c:478 R> #6 0xffffffff808e88e4 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 R> #7 0xffffffff80667ef7 in m_copym (m=0x0, off0=1500, len=1480, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:542 R> #8 0xffffffff8071c8c2 in ip_fragment (ip=0xffffff0001a3700e, m_frag=0xffffff800016a838, mtu=Variable "mtu" is not available. R> ) at /usr/src/sys/netinet/ip_output.c:819 R> #9 0xffffffff8071d93a in ip_output (m=0xffffff00019fd900, opt=Variable "opt" is not available. R> ) at /usr/src/sys/netinet/ip_output.c:650 R> #10 0xffffffff8071a13a in ip_forward (m=0xffffff00019fd900, srcrt=Variable "srcrt" is not available. R> ) at /usr/src/sys/netinet/ip_input.c:1521 R> #11 0xffffffff8071b77c in ip_input (m=0xffffff00019fd900) at /usr/src/sys/netinet/ip_input.c:729 R> #12 0xffffffff806c652e in netisr_dispatch_src (proto=1, source=Variable "source" is not available. R> ) at /usr/src/sys/net/netisr.c:859 R> #13 0xffffffff806bc5cd in ether_demux (ifp=0xffffff000168e800, m=0xffffff00019fd900) at /usr/src/sys/net/if_ethersubr.c:896 R> #14 0xffffffff806bc9d7 in ether_input (ifp=0xffffff000168e800, m=0xffffff00019fd900) at /usr/src/sys/net/if_ethersubr.c:755 R> #15 0xffffffff803ee03e in ixv_rxeof (que=0xffffff0001643880, count=117) at /usr/src/sys/dev/ixgbe/ixv.c:3256 R> #16 0xffffffff803ef50b in ixv_handle_que (context=Variable "context" is not available. I have looked at several panics like this, and it appears that ip_fragment() is entered with incorrect byte order here. I failed to understand how this happens, and eventually had made the network stack in head to run consistently in network byte order, never modifying a forwarded packet. If you can run recent 10-CURRENT under same tests, I'd like to know the results. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Thu Oct 25 17:30:40 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE11D4C5 for ; Thu, 25 Oct 2012 17:30:40 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by mx1.freebsd.org (Postfix) with ESMTP id 7D6498FC14 for ; Thu, 25 Oct 2012 17:30:40 +0000 (UTC) Received: from [10.9.208.27] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Thu, 25 Oct 2012 10:26:35 -0700 X-Server-Uuid: 06151B78-6688-425E-9DE2-57CB27892261 Received: from IRVEXCHSMTP1.corp.ad.broadcom.com (10.9.207.51) by irvexchmb05.corp.ad.broadcom.com (10.9.208.27) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 25 Oct 2012 10:27:42 -0700 Received: from IRVEXCHMB11.corp.ad.broadcom.com ( [fe80::9cdd:3a57:8694:f610]) by Irvexchsmtp1.corp.ad.broadcom.com ( [fe80::f003:4754:d9bd:c345%12]) with mapi id 14.01.0355.002; Thu, 25 Oct 2012 10:27:42 -0700 From: "David Christensen" To: "Eugene Mitrofanov" , "freebsd-net@freebsd.org" Subject: RE: dev.bce.3.mbuf_alloc_failed_count increases permanently Thread-Topic: dev.bce.3.mbuf_alloc_failed_count increases permanently Thread-Index: AQHNqIcx9qHWzixm9UeSl2IG5LrxgpfKWXzw Date: Thu, 25 Oct 2012 17:27:41 +0000 Message-ID: <3A5015FE9E557D448AF7238AF0ACE20A24B0F4@IRVEXCHMB11.corp.ad.broadcom.com> References: <201210121812.37557.eugene@imedia.ru> In-Reply-To: <201210121812.37557.eugene@imedia.ru> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.9.208.64] MIME-Version: 1.0 X-WSS-ID: 7C97A9C141411624745-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 17:30:40 -0000 > sysctl -a | g bce.3|g -vE '(%|stat)'; echo; sleep 10; sysctl -a | g bce.= 3| > g -vE '(%|stat)'; echo; netstat -m >=20 > dev.bce.3.l2fhdr_error_count: 0 > dev.bce.3.mbuf_alloc_failed_count: 2098854 > dev.bce.3.mbuf_frag_count: 2655285 > dev.bce.3.dma_map_addr_rx_failed_count: 0 > dev.bce.3.dma_map_addr_tx_failed_count: 57 > dev.bce.3.unexpected_attention_count: 0 > dev.bce.3.com_no_buffers: 0 >=20 > dev.bce.3.l2fhdr_error_count: 0 > dev.bce.3.mbuf_alloc_failed_count: 2098856 > dev.bce.3.mbuf_frag_count: 2655288 > dev.bce.3.dma_map_addr_rx_failed_count: 0 > dev.bce.3.dma_map_addr_tx_failed_count: 57 > dev.bce.3.unexpected_attention_count: 0 > dev.bce.3.com_no_buffers: 0 >=20 >=20 > Any suggestions? What is the reason of this? It's normal in a system under load, the kernel can't always allocate memory when requested by the driver. The result is that RX frames will be dropped as the driver reuses an existing mbuf, a response taken by many other drivers. If you notice rapid increases during certain system operations then you should consider increasing the amount of system memory. Dave From owner-freebsd-net@FreeBSD.ORG Fri Oct 26 08:34:45 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7C56AC for ; Fri, 26 Oct 2012 08:34:45 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.kpi.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 848A28FC0A for ; Fri, 26 Oct 2012 08:34:45 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.kpi.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1TRfNL-0001KA-Ex for freebsd-net@freebsd.org; Fri, 26 Oct 2012 11:34:43 +0300 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id 01C141CC1E; Fri, 26 Oct 2012 11:34:42 +0300 (EEST) Date: Fri, 26 Oct 2012 11:34:42 +0300 From: Andrey Simonenko To: freebsd-net@freebsd.org Subject: getnetent(3) return values for incorrect IPv4 network addresses Message-ID: <20121026083442.GA20882@pm513-1.comsys.ntu-kpi.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 28-Apr-2011 07:11:12) X-Date: 2012-10-26 11:34:43 X-Connected-IP: 10.18.52.101:48047 X-Message-Linecount: 29 X-Body-Linecount: 17 X-Message-Size: 1127 X-Body-Size: 612 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 08:34:45 -0000 There is one feature of getnetent(3) that is not documented and is not checked by applications that use getnetent(3) or similar functions. If an IPv4 network address is specified incorrectly in the networks(5) database, then the n_net field from the struct netent{} is set to INADDR_NONE. This is done by the inet_network(3) function that is used for network address translation. Should this property of getnetent(3) be documented in its manual page to make such behaviour of getnetent(3) official? Example: % grep abc /etc/networks abc 1. % getent networks abc abc 255.255.255.255 From owner-freebsd-net@FreeBSD.ORG Fri Oct 26 08:38:11 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6C6B42A6 for ; Fri, 26 Oct 2012 08:38:11 +0000 (UTC) (envelope-from eugene@imedia.ru) Received: from mx2.imedia.ru (mx2.imedia.ru [91.230.26.134]) by mx1.freebsd.org (Postfix) with ESMTP id B1C368FC0A for ; Fri, 26 Oct 2012 08:38:10 +0000 (UTC) X-All-Recipients: X-DKIM: OpenDKIM Filter v2.5.2 mx2.imedia.ru q9Q8RGEr028934 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=imedia.ru; s=common; t=1351240037; bh=Tj0wRs+Tc2cjOgoK8ba/eLi0NAEmmLvw8/xTJH9VqS8=; h=From:Reply-To:To:Subject:Date:Cc:References:In-Reply-To; b=gp/kbKuqdyq7Lxj8LSMYVHJz2RX04T0Hh7oAOK3nJAvTyPYO9trJcP8psJ9Jg1ybw A655Jq5akgnRX9bEocZIGR9x4fPJAoH1baN3doapdEcLx6Pr6adePJr6ETZzk4K9Fc S+B2xOMmMyQo/b3rMldt4y2MQ3KfkYSChltVul3Y= Received: from badger.imedia.ru (root@badger.imedia.ru [10.167.1.243]) by mx2.imedia.ru (8.14.3/8.14.3/TWINS7_LDAP) with ESMTP id q9Q8RGEr028934; Fri, 26 Oct 2012 12:27:16 +0400 (MSK) (envelope-from eugene@imedia.ru) Received: from badger.imedia.ru (eugene@localhost [127.0.0.1]) by badger.imedia.ru (8.14.5/8.14.4) with ESMTP id q9Q8RGaq022152; Fri, 26 Oct 2012 12:27:16 +0400 (MSK) (envelope-from eugene@imedia.ru) Received: from localhost (localhost [[UNIX: localhost]]) by badger.imedia.ru (8.14.5/8.14.4/Submit) id q9Q8RFlJ022151; Fri, 26 Oct 2012 12:27:15 +0400 (MSK) (envelope-from eugene@imedia.ru) X-Authentication-Warning: badger.imedia.ru: eugene set sender to eugene@imedia.ru using -f From: Eugene Mitrofanov Organization: Sanoma Independent Media To: "David Christensen" Subject: Re: dev.bce.3.mbuf_alloc_failed_count increases permanently Date: Fri, 26 Oct 2012 12:27:15 +0400 User-Agent: KMail/1.9.10 References: <201210121812.37557.eugene@imedia.ru> <3A5015FE9E557D448AF7238AF0ACE20A24B0F4@IRVEXCHMB11.corp.ad.broadcom.com> In-Reply-To: <3A5015FE9E557D448AF7238AF0ACE20A24B0F4@IRVEXCHMB11.corp.ad.broadcom.com> X-Origin: badger.imedia.ru MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201210261227.15689.eugene@imedia.ru> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mx2.imedia.ru [10.167.0.252]); Fri, 26 Oct 2012 12:27:17 +0400 (MSK) X-Virus-Scanned: clamav-milter 0.97.6-exp at lynx.imedia.ru X-Virus-Status: Clean Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Eugene Mitrofanov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 08:38:11 -0000 On Thursday 25 October 2012, David Christensen wrote: > > sysctl -a | g bce.3|g -vE '(%|stat)'; echo; sleep 10; sysctl -a | g bce.3| > > g -vE '(%|stat)'; echo; netstat -m > > > > dev.bce.3.l2fhdr_error_count: 0 > > dev.bce.3.mbuf_alloc_failed_count: 2098854 > > dev.bce.3.mbuf_frag_count: 2655285 > > dev.bce.3.dma_map_addr_rx_failed_count: 0 > > dev.bce.3.dma_map_addr_tx_failed_count: 57 > > dev.bce.3.unexpected_attention_count: 0 > > dev.bce.3.com_no_buffers: 0 > > > > dev.bce.3.l2fhdr_error_count: 0 > > dev.bce.3.mbuf_alloc_failed_count: 2098856 > > dev.bce.3.mbuf_frag_count: 2655288 > > dev.bce.3.dma_map_addr_rx_failed_count: 0 > > dev.bce.3.dma_map_addr_tx_failed_count: 57 > > dev.bce.3.unexpected_attention_count: 0 > > dev.bce.3.com_no_buffers: 0 > > > > > > Any suggestions? What is the reason of this? > > It's normal in a system under load, the kernel can't always > allocate memory when requested by the driver. The result > is that RX frames will be dropped as the driver reuses an > existing mbuf, a response taken by many other drivers. > > If you notice rapid increases during certain system operations > then you should consider increasing the amount of system > memory. > Thanks for you answer, Dave. What do you mean under "systems memory"? Is it the physical memory or the virtual one? -- EVM7-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Oct 26 09:09:26 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D33631A; Fri, 26 Oct 2012 09:09:26 +0000 (UTC) (envelope-from remi.pauchet@netasq.com) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id DAE5B8FC08; Fri, 26 Oct 2012 09:09:24 +0000 (UTC) Received: from [10.2.9.2] (unknown [91.212.116.2]) by work.netasq.com (Postfix) with ESMTPSA id 1250027056EE; Fri, 26 Oct 2012 11:09:23 +0200 (CEST) Subject: Re: panic ixgbevf / SMP under high network load Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_9A3C1F97-28A1-4218-B71B-E277637F857D"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?R=E9mi_Pauchet?= In-Reply-To: <20121025164031.GA70741@FreeBSD.org> Date: Fri, 26 Oct 2012 11:09:20 +0200 Message-Id: References: <20121025164031.GA70741@FreeBSD.org> To: Gleb Smirnoff X-Mailer: Apple Mail (2.1283) X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 09:09:26 -0000 --Apple-Mail=_9A3C1F97-28A1-4218-B71B-E277637F857D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi I have the same crash with FreeBSD 10-current FreeBSD freebsd10 10.0-CURRENT FreeBSD 10.0-CURRENT #4 r241761: Sat Oct = 20 07:40:33 UTC 2012 = root@kaos.glenbarber.us:/usr/obj/usr/src/sys/GENERIC amd64 Sorry for the screenshots: panic doesn't dump the memory to the swap, I = can't figure out why I use udp frames (size 700) so this load is not supposed to produce ip = fragmentation. And again, the panic happens with 4 vcpus, no issue with 1 vcpu. Regards, R=E9mi Le 25 oct. 2012 =E0 18:40, Gleb Smirnoff a =E9crit : > On Thu, Oct 25, 2012 at 10:06:40AM +0200, R?mi Pauchet wrote: > R> I'm testing network performance of FreeBSD using vmware esxi 5.1 = with SR-IOV > R>=20 > R> I'm using FreeBSD 8.3 kernel GENERIC, 4 cpus, ixgbevf driver with = an Intel 82599EB dual 10 Gbps network interface > R>=20 > R> After a few seconds of udp ipv4 load (5Gbps x2, frame size 700), I = have the following panic : > R>=20 > R> (kgdb) bt > R> #0 doadump () at pcpu.h:224 > R> #1 0xffffffff8060ab90 in boot (howto=3D260) at = /usr/src/sys/kern/kern_shutdown.c:441 > R> #2 0xffffffff8060b031 in panic (fmt=3DVariable "fmt" is not = available. > R> ) at /usr/src/sys/kern/kern_shutdown.c:614 > R> #3 0xffffffff80900b80 in trap_fatal (frame=3D0xc, eva=3DVariable = "eva" is not available. > R> ) at /usr/src/sys/amd64/amd64/trap.c:825 > R> #4 0xffffffff80900ed1 in trap_pfault (frame=3D0xffffff800016a620, = usermode=3D0) at /usr/src/sys/amd64/amd64/trap.c:741 > R> #5 0xffffffff8090138f in trap (frame=3D0xffffff800016a620) at = /usr/src/sys/amd64/amd64/trap.c:478 > R> #6 0xffffffff808e88e4 in calltrap () at = /usr/src/sys/amd64/amd64/exception.S:228 > R> #7 0xffffffff80667ef7 in m_copym (m=3D0x0, off0=3D1500, len=3D1480, = wait=3D1) at /usr/src/sys/kern/uipc_mbuf.c:542 > R> #8 0xffffffff8071c8c2 in ip_fragment (ip=3D0xffffff0001a3700e, = m_frag=3D0xffffff800016a838, mtu=3DVariable "mtu" is not available. > R> ) at /usr/src/sys/netinet/ip_output.c:819 > R> #9 0xffffffff8071d93a in ip_output (m=3D0xffffff00019fd900, = opt=3DVariable "opt" is not available. > R> ) at /usr/src/sys/netinet/ip_output.c:650 > R> #10 0xffffffff8071a13a in ip_forward (m=3D0xffffff00019fd900, = srcrt=3DVariable "srcrt" is not available. > R> ) at /usr/src/sys/netinet/ip_input.c:1521 > R> #11 0xffffffff8071b77c in ip_input (m=3D0xffffff00019fd900) at = /usr/src/sys/netinet/ip_input.c:729 > R> #12 0xffffffff806c652e in netisr_dispatch_src (proto=3D1, = source=3DVariable "source" is not available. > R> ) at /usr/src/sys/net/netisr.c:859 > R> #13 0xffffffff806bc5cd in ether_demux (ifp=3D0xffffff000168e800, = m=3D0xffffff00019fd900) at /usr/src/sys/net/if_ethersubr.c:896 > R> #14 0xffffffff806bc9d7 in ether_input (ifp=3D0xffffff000168e800, = m=3D0xffffff00019fd900) at /usr/src/sys/net/if_ethersubr.c:755 > R> #15 0xffffffff803ee03e in ixv_rxeof (que=3D0xffffff0001643880, = count=3D117) at /usr/src/sys/dev/ixgbe/ixv.c:3256 > R> #16 0xffffffff803ef50b in ixv_handle_que (context=3DVariable = "context" is not available. >=20 > I have looked at several panics like this, and it appears that = ip_fragment() > is entered with incorrect byte order here. I failed to understand how = this happens, > and eventually had made the network stack in head to run consistently = in network > byte order, never modifying a forwarded packet. >=20 > If you can run recent 10-CURRENT under same tests, I'd like to know = the results. >=20 > --=20 > Totus tuus, Glebius. --Apple-Mail=_9A3C1F97-28A1-4218-B71B-E277637F857D-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 26 10:30:15 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2E0767F8 for ; Fri, 26 Oct 2012 10:30:15 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 9BC0F8FC14 for ; Fri, 26 Oct 2012 10:30:14 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q9QAU7Kt011118; Fri, 26 Oct 2012 14:30:07 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q9QAU6np011117; Fri, 26 Oct 2012 14:30:06 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 26 Oct 2012 14:30:06 +0400 From: Gleb Smirnoff To: R?mi Pauchet Subject: Re: panic ixgbevf / SMP under high network load Message-ID: <20121026103006.GB70741@glebius.int.ru> References: <20121025164031.GA70741@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 10:30:15 -0000 On Fri, Oct 26, 2012 at 11:09:20AM +0200, R?mi Pauchet wrote: R> Hi R> R> I have the same crash with FreeBSD 10-current R> R> FreeBSD freebsd10 10.0-CURRENT FreeBSD 10.0-CURRENT #4 r241761: Sat Oct 20 07:40:33 UTC 2012 root@kaos.glenbarber.us:/usr/obj/usr/src/sys/GENERIC amd64 R> R> Sorry for the screenshots: panic doesn't dump the memory to the swap, I can't figure out why R> R> I use udp frames (size 700) so this load is not supposed to produce ip fragmentation. R> R> And again, the panic happens with 4 vcpus, no issue with 1 vcpu. r241761 predates conversion of the IPv4 stack to net byte order, which happened in r241913. Can you please try out your test on head r242077 or later? -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Oct 26 13:53:57 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2EB2239 for ; Fri, 26 Oct 2012 13:53:57 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id E2A798FC16 for ; Fri, 26 Oct 2012 13:53:56 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q9QDrtsD012468; Fri, 26 Oct 2012 17:53:55 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q9QDrtEJ012467; Fri, 26 Oct 2012 17:53:55 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 26 Oct 2012 17:53:54 +0400 From: Gleb Smirnoff To: Sebastian Kuzminsky Subject: Re: fragmentation problem in FreeBSD 7 Message-ID: <20121026135354.GD70741@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="jCrbxBqMcLqd4mOl" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 13:53:57 -0000 --jCrbxBqMcLqd4mOl Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Sebastian, On Tue, Oct 23, 2012 at 12:25:59PM -0600, Sebastian Kuzminsky wrote: S> The root of the problem is two-fold: S> S> 1. ip_output.c:ip_fragment() does not clear the CSUM_IP flag in the mbuf S> when it does software IP checksum computation, so the mbuf still looks like S> it needs IP checksumming. S> S> 2. The em driver does not advertise IP checksum offloading, but still S> checks the CSUM_IP flag in the mbuf and modifies the packet when that flag S> is set (this is in em_transmit_checksum_setup(), called by em_xmit()). S> Unfortunately the em driver gets the checksum wrong in this case, i guess S> that's why it doesn't advertise this capability in its if_hwassist! S> S> So the fragments that ip_fastfwd.c:ip_fastforward() gets from S> ip_output.c:ip_fragment() have ip->ip_sum set correctly, but the S> mbuf->m_pkthdr.csum_flags incorrectly has CSUM_IP still set, and this S> causes the em driver to emit incorrect packets. S> S> There are some other callers of ip_fragment(), notably ip_output(). S> ip_output() clears CSUM_IP in the mbuf csum_flags itself if it's not in S> if_hwassist, so avoids this problem. S> S> So, the fix is simple: clear the mbuf's CSUM_IP when computing ip->ip_sum S> in ip_fragment(). The first attached patch (against S> gitorious/svn_stable_7) does this. S> S> In looking at this issue, I noticed that ip_output()'s use of sw_csum is S> inconsistent. ip_output() splits the mbuf's csum_flags into two parts: the S> stuff that hardware will assist with (these flags get left in the mbuf) and S> the stuff that software needs to do (these get moved to sw_csum). But S> later ip_output() calls functions that don't get sw_csum, or that don't S> know to look in it and look in the mbuf instead. My second patch fixes S> these kinds of issues and (IMO) simplifies the code by leaving all the S> packet's checksumming needs in the mbuf, getting rid of sw_csum entirely. Thanks for submission! I'm about to commit the attached patch to head. Can you please review it? Haven't I missed anything important? I have tested it in a 3-box setup similar to yours, except the middle box doesn't have em(4) NIC, it has igb(4). I've tested it with rxcsum/txcsum on and off on both NICs. I have also moved from CSUM_DELAY_IP to CSUM_IP. AFAIU, the alias CSUM_DELAY_IP was made to match CSUM_DELAY_DATA. But to my point of view it makes it more difficult to understand code, because a person reading code sees different constants in the stack and in drivers. Since your change touches every line in the stack, that utilizes CSUM_DELAY_IP, I decided to consistently use CSUM_IP constant. -- Totus tuus, Glebius. --jCrbxBqMcLqd4mOl Content-Type: text/x-diff; charset=koi8-r Content-Disposition: attachment; filename="csum.diff" Index: netinet/ip_output.c =================================================================== --- netinet/ip_output.c (revision 242127) +++ netinet/ip_output.c (working copy) @@ -125,7 +125,7 @@ struct sockaddr_in *dst; struct in_ifaddr *ia; int isbroadcast; - uint16_t ip_len, ip_off, sw_csum; + uint16_t ip_len, ip_off; struct route iproute; struct rtentry *rte; /* cache for ro->ro_rt */ struct in_addr odst; @@ -583,18 +583,16 @@ } m->m_pkthdr.csum_flags |= CSUM_IP; - sw_csum = m->m_pkthdr.csum_flags & ~ifp->if_hwassist; - if (sw_csum & CSUM_DELAY_DATA) { + if (m->m_pkthdr.csum_flags & CSUM_DELAY_DATA & ~ifp->if_hwassist) { in_delayed_cksum(m); - sw_csum &= ~CSUM_DELAY_DATA; + m->m_pkthdr.csum_flags &= ~CSUM_DELAY_DATA; } #ifdef SCTP - if (sw_csum & CSUM_SCTP) { + if (m->m_pkthdr.csum_flags & CSUM_SCTP & ~ifp->if_hwassist) { sctp_delayed_cksum(m, (uint32_t)(ip->ip_hl << 2)); - sw_csum &= ~CSUM_SCTP; + m->m_pkthdr.csum_flags &= ~CSUM_SCTP; } #endif - m->m_pkthdr.csum_flags &= ifp->if_hwassist; /* * If small enough for interface, or the interface will take @@ -604,8 +602,10 @@ (m->m_pkthdr.csum_flags & ifp->if_hwassist & CSUM_TSO) != 0 || ((ip_off & IP_DF) == 0 && (ifp->if_hwassist & CSUM_FRAGMENT))) { ip->ip_sum = 0; - if (sw_csum & CSUM_DELAY_IP) + if (m->m_pkthdr.csum_flags & CSUM_IP & ~ifp->if_hwassist) { ip->ip_sum = in_cksum(m, hlen); + m->m_pkthdr.csum_flags &= ~CSUM_IP; + } /* * Record statistics for this interface address. @@ -646,7 +646,7 @@ * Too large for interface; fragment if possible. If successful, * on return, m will point to a list of packets to be sent. */ - error = ip_fragment(ip, &m, mtu, ifp->if_hwassist, sw_csum); + error = ip_fragment(ip, &m, mtu, ifp->if_hwassist); if (error) goto bad; for (; m; m = m0) { @@ -691,11 +691,10 @@ * chain of fragments that should be freed by the caller. * * if_hwassist_flags is the hw offload capabilities (see if_data.ifi_hwassist) - * sw_csum contains the delayed checksums flags (e.g., CSUM_DELAY_IP). */ int ip_fragment(struct ip *ip, struct mbuf **m_frag, int mtu, - u_long if_hwassist_flags, int sw_csum) + u_long if_hwassist_flags) { int error = 0; int hlen = ip->ip_hl << 2; @@ -833,8 +832,10 @@ m->m_pkthdr.csum_flags = m0->m_pkthdr.csum_flags; mhip->ip_off = htons(mhip->ip_off); mhip->ip_sum = 0; - if (sw_csum & CSUM_DELAY_IP) + if (m->m_pkthdr.csum_flags & CSUM_IP & ~if_hwassist_flags) { mhip->ip_sum = in_cksum(m, mhlen); + m->m_pkthdr.csum_flags &= ~CSUM_IP; + } *mnext = m; mnext = &m->m_nextpkt; } @@ -853,8 +854,10 @@ ip->ip_len = htons((u_short)m0->m_pkthdr.len); ip->ip_off = htons(ip_off | IP_MF); ip->ip_sum = 0; - if (sw_csum & CSUM_DELAY_IP) + if (m0->m_pkthdr.csum_flags & CSUM_IP & ~if_hwassist_flags) { ip->ip_sum = in_cksum(m0, hlen); + m0->m_pkthdr.csum_flags &= ~CSUM_IP; + } done: *m_frag = m0; Index: netinet/ip_mroute.c =================================================================== --- netinet/ip_mroute.c (revision 242127) +++ netinet/ip_mroute.c (working copy) @@ -2404,7 +2404,8 @@ ip->ip_sum = in_cksum(mb_copy, ip->ip_hl << 2); } else { /* Fragment the packet */ - if (ip_fragment(ip, &mb_copy, mtu, 0, CSUM_DELAY_IP) != 0) { + mb_copy->m_pkthdr.csum_flags |= CSUM_IP; + if (ip_fragment(ip, &mb_copy, mtu, 0) != 0) { m_freem(mb_copy); return NULL; } Index: netinet/ip_var.h =================================================================== --- netinet/ip_var.h (revision 242127) +++ netinet/ip_var.h (working copy) @@ -210,7 +210,7 @@ int ip_ctloutput(struct socket *, struct sockopt *sopt); void ip_drain(void); int ip_fragment(struct ip *ip, struct mbuf **m_frag, int mtu, - u_long if_hwassist_flags, int sw_csum); + u_long if_hwassist_flags); void ip_forward(struct mbuf *m, int srcrt); void ip_init(void); #ifdef VIMAGE Index: netinet/ip_fastfwd.c =================================================================== --- netinet/ip_fastfwd.c (revision 242127) +++ netinet/ip_fastfwd.c (working copy) @@ -542,10 +542,8 @@ * We have to fragment the packet */ m->m_pkthdr.csum_flags |= CSUM_IP; - if (ip_fragment(ip, &m, mtu, ifp->if_hwassist, - (~ifp->if_hwassist & CSUM_DELAY_IP))) { + if (ip_fragment(ip, &m, mtu, ifp->if_hwassist)) goto drop; - } KASSERT(m != NULL, ("null mbuf and no error")); /* * Send off the fragments via outgoing interface Index: netpfil/pf/pf.c =================================================================== --- netpfil/pf/pf.c (revision 242127) +++ netpfil/pf/pf.c (working copy) @@ -5140,7 +5140,7 @@ struct pf_addr naddr; struct pf_src_node *sn = NULL; int error = 0; - uint16_t ip_len, ip_off, sw_csum; + uint16_t ip_len, ip_off; KASSERT(m && *m && r && oifp, ("%s: invalid parameters", __func__)); KASSERT(dir == PF_IN || dir == PF_OUT, ("%s: invalid direction", @@ -5240,18 +5240,16 @@ /* Copied from FreeBSD 10.0-CURRENT ip_output. */ m0->m_pkthdr.csum_flags |= CSUM_IP; - sw_csum = m0->m_pkthdr.csum_flags & ~ifp->if_hwassist; - if (sw_csum & CSUM_DELAY_DATA) { + if (m0->m_pkthdr.csum_flags & CSUM_DELAY_DATA & ~ifp->if_hwassist) { in_delayed_cksum(m0); - sw_csum &= ~CSUM_DELAY_DATA; + m0->m_pkthdr.csum_flags &= ~CSUM_DELAY_DATA; } #ifdef SCTP - if (sw_csum & CSUM_SCTP) { + if (m0->m_pkthdr.csum_flags & CSUM_SCTP & ~ifp->if_hwassist) { sctp_delayed_cksum(m, (uint32_t)(ip->ip_hl << 2)); - sw_csum &= ~CSUM_SCTP; + m0->m_pkthdr.csum_flags &= ~CSUM_SCTP; } #endif - m0->m_pkthdr.csum_flags &= ifp->if_hwassist; /* * If small enough for interface, or the interface will take @@ -5261,8 +5259,10 @@ (m0->m_pkthdr.csum_flags & ifp->if_hwassist & CSUM_TSO) != 0 || ((ip_off & IP_DF) == 0 && (ifp->if_hwassist & CSUM_FRAGMENT))) { ip->ip_sum = 0; - if (sw_csum & CSUM_DELAY_IP) + if (m0->m_pkthdr.csum_flags & CSUM_IP & ~ifp->if_hwassist) { ip->ip_sum = in_cksum(m0, ip->ip_hl << 2); + m0->m_pkthdr.csum_flags &= ~CSUM_IP; + } m0->m_flags &= ~(M_PROTOFLAGS); error = (*ifp->if_output)(ifp, m0, sintosa(&dst), NULL); goto done; @@ -5280,7 +5280,7 @@ goto bad; } - error = ip_fragment(ip, &m0, ifp->if_mtu, ifp->if_hwassist, sw_csum); + error = ip_fragment(ip, &m0, ifp->if_mtu, ifp->if_hwassist); if (error) goto bad; Index: net/if_bridge.c =================================================================== --- net/if_bridge.c (revision 242127) +++ net/if_bridge.c (working copy) @@ -3379,8 +3379,8 @@ goto out; ip = mtod(m, struct ip *); - error = ip_fragment(ip, &m, ifp->if_mtu, ifp->if_hwassist, - CSUM_DELAY_IP); + m->m_pkthdr.csum_flags |= CSUM_IP; + error = ip_fragment(ip, &m, ifp->if_mtu, ifp->if_hwassist); if (error) goto out; --jCrbxBqMcLqd4mOl-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 26 16:11:19 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78C65602 for ; Fri, 26 Oct 2012 16:11:19 +0000 (UTC) (envelope-from 3JbaKUAoGC0Yp62v-6w2voyy.kwunzmmj0l-vm1nzmmj0l.wzo@photos-server.bounces.google.com) Received: from mail-vb0-f74.google.com (mail-vb0-f74.google.com [209.85.212.74]) by mx1.freebsd.org (Postfix) with ESMTP id 11E638FC14 for ; Fri, 26 Oct 2012 16:11:18 +0000 (UTC) Received: by mail-vb0-f74.google.com with SMTP id s24so377247vbi.1 for ; Fri, 26 Oct 2012 09:11:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.193.72 with SMTP id dt8mt20333540qab.7.1351267877973; Fri, 26 Oct 2012 09:11:17 -0700 (PDT) Message-ID: <20cf30050c2cdcf13004ccf89133@google.com> Date: Fri, 26 Oct 2012 16:11:17 +0000 Subject: freight forwarder & logistics provider shared photos with you From: "freight forwarder & logistics provider" To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary=20cf30050c2cdd35dd04ccf89175 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: freight forwarder & logistics provider List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 16:11:19 -0000 --20cf30050c2cdd35dd04ccf89175 Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes Content-Transfer-Encoding: base64 RGVhciBNeSBGcmllbmQNCg0KICAgICAgICAgTmljZSBkYXksIEh5dW4gWW91bmcgaXMgYSBsZWFk aW5nIHByb2Zlc3Npb25hbCBmcmVpZ2h0IGZvcndhcmRlciAgDQphbmQgbG9naXN0aWNzIHByb3Zp ZGVyIHdobyBmb2N1cyBvbiB0aGUgc2hpcG1lbnQgZnJvbSBTb3V0aCBDaGluYSB0byBhbGwgIA0K dGhlIHdvcmxkLiBIeXVuIFlvdW5nIHN0YXJ0ZWQgZnJlaWdodCBmb3J3YXJkaW5nIG9wZXJhdGlv biBhdCBTaGVuemhlbiBpbiAgDQoyMDA0LiBCYXNlZCBhdCBTaGVuemhlbiwgb3VyIGFtYml0aW9u IGhhdmUgcHVzaGVkIHVzIGZvcndhcmQgdG8gZXhwYW5kIHRvICANCm90aGVyIGNpdGllcyBpbiBz b3V0aCBvZiBDaGluYS4gTm93IHdlIGhhdmUgY2FwYWNpdHkgb2YgaGFuZGluZyBzaGlwbWVudCB0 byAgDQpvciBmcm9tIGFsbCB0aGUgcG9ydHMgaW4gc291dGggb2YgQ2hpbmEuDQogICAgICAgICAg IEhvbGRzIHdoaWxlIHdob2xlIC0gaGVhcnRlZGx5IGFjaGlldmVzIHRoZSBiZXN0IGVudGVycHJp c2UgIA0Kb2JqZWN0aXZlLCBXaXRoIHRoZSBncmVhdCBzdXBwb3J0IG9mIG91ciBnbG9iYWwgYWdl bmN5LCB3ZSBwcm92aWRlIHNlcnZpY2VzICANCnRvIG91ciBjdXN0b21lcnMgdGhyb3VnaCBwcm9j ZXNzLWRyaXZlbiBvcGVyYXRpb24gdGVhbSwgYWR2YW5jZWQgIA0KaW5mb3JtYXRpb24gc3lzdGVt LCBhbmQgc3Ryb25nIG1hbmFnZW1lbnQgdGVhbS4NCg0KR2xhbmNlIHRvIG91ciBjb21wYW55Og0K MS4JU2VhIEZyZWlnaHQsIGluY2x1ZGVkIEZDTCZMQ0w7DQoyLglBaXIgRnJlaWdodDsNCjMuCUV4 cHJlc3MsIGluY2x1ZGVkIERITCxVUFMsRkVERVgsU0FHQVdBIGFuZCBTQ09SRUpQOw0KNC4JSW1w b3J0ICYgRXhwb3J0Ow0KNS4JTGFuZCBUcmFuc3BvcnRhdGlvbi4NCg0KICAgICAgICAgICBXZSBz ZWVrIG5vIHN0cm9uZ2VzdCBvbmx5IG1vcmUgc3BlY2lhbGl6ZWQsIHNlbmlvci4gWW91ciAgDQpz YXRpc2ZpZWQgd2lsbCBiZSBvdXIgbWF4aW1hbCBwcmlkZS4NCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KU2hlbnpoZW4gSHl1biBZb3VuZyBJbnRlcm5hdGlvbmFsIFRyYW5zcG9ydGF0aW9uIENPLixM VEQNCkphY2t5IFlhbmcNCg0KQWRkOiBGbG9vciA3JjgsIFNvdXRoIEJhb5JhbiBSb2FkLCBMdW9o dSBEaXN0cmljdCwgU2hlbnpoZW4sIEd1YW5nZG9uZywgIA0KQ2hpbmEuDQo= --20cf30050c2cdd35dd04ccf89175-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 26 16:28:11 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0FA8B990 for ; Fri, 26 Oct 2012 16:28:11 +0000 (UTC) (envelope-from seb@lineratesystems.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id B72218FC12 for ; Fri, 26 Oct 2012 16:28:10 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so2177787pad.13 for ; Fri, 26 Oct 2012 09:28:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=offb/mY6mDOHyxYFUZQScJgbO1DpoqpxZHSi7BASCuY=; b=B6/X0N77uxv9nB96SLs6nx+EpfvGtqnMNKxQjajB8CeH3gmqncPfSdX0gYxrGPPcaz umd8tG7INgP+sWHnDh3IgIQ0J6ogNBwTNzqVfelgusMFXbddsWLINxyNjRJ7vGNF9XET YDay2kn0vsIzwIGQ4F6S5N6zLuQ0Xk/xve7o5wO/KrDpe/mrGr8fbnFgLwECFzUONw5p 3jQ1m9yePoRAAoMCU/FyQQ0BEO+nIVF6QViZUmGLJjwAYoQuzAWj5ve7knNaTAQEoD9Y loPcNYD+4jaQYJAAwCIA3mqqxEahRU+Cu7ATNjcJmxdA+Dhpq/ZLa9GeQhv/zJudAYPo 5vCA== MIME-Version: 1.0 Received: by 10.69.0.10 with SMTP id au10mr71620882pbd.18.1351268890131; Fri, 26 Oct 2012 09:28:10 -0700 (PDT) Received: by 10.68.85.137 with HTTP; Fri, 26 Oct 2012 09:28:10 -0700 (PDT) In-Reply-To: <20121026135354.GD70741@FreeBSD.org> References: <20121026135354.GD70741@FreeBSD.org> Date: Fri, 26 Oct 2012 10:28:10 -0600 Message-ID: Subject: Re: fragmentation problem in FreeBSD 7 From: Sebastian Kuzminsky To: Gleb Smirnoff X-Gm-Message-State: ALoCoQmsWfRW/Xgc8MNutl6gLbSx6pWEoNOr8zDHytiQ7L+Is566H+sLO6+x6xqbLOu8PoyxbAln Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 16:28:11 -0000 On Fri, Oct 26, 2012 at 7:53 AM, Gleb Smirnoff wrote: > Thanks for submission! > > I'm about to commit the attached patch to head. Can you please review it? > Haven't I missed anything important? > Looks good to me. Thanks for also including the sw_csum cleanup, that code had me scratching my head for a whole morning. :-) I have also moved from CSUM_DELAY_IP to CSUM_IP. AFAIU, the alias > CSUM_DELAY_IP > was made to match CSUM_DELAY_DATA. But to my point of view it makes it more > difficult to understand code, because a person reading code sees different > constants in the stack and in drivers. Since your change touches every line > in the stack, that utilizes CSUM_DELAY_IP, I decided to consistently use > CSUM_IP constant. > I agree with this. I did not understand why the original code use CSUM_DELAY_IP instead of the more obvious CSUM_IP, but i felt too timid to change it ;-) > Totus tuus, Glebius. > Et tuus, thanks for taking the time to review and clean up my patch! -- Sebastian Kuzminsky Linerate Systems From owner-freebsd-net@FreeBSD.ORG Fri Oct 26 17:57:02 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E0C85A9 for ; Fri, 26 Oct 2012 17:57:02 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by mx1.freebsd.org (Postfix) with ESMTP id 61FD18FC12 for ; Fri, 26 Oct 2012 17:57:02 +0000 (UTC) Received: from [10.9.208.55] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Fri, 26 Oct 2012 10:55:31 -0700 X-Server-Uuid: 06151B78-6688-425E-9DE2-57CB27892261 Received: from IRVEXCHMB11.corp.ad.broadcom.com ( [fe80::9cdd:3a57:8694:f610]) by IRVEXCHCAS07.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Fri, 26 Oct 2012 10:56:38 -0700 From: "David Christensen" To: "Eugene Mitrofanov" Subject: RE: dev.bce.3.mbuf_alloc_failed_count increases permanently Thread-Topic: dev.bce.3.mbuf_alloc_failed_count increases permanently Thread-Index: AQHNqIcx9qHWzixm9UeSl2IG5LrxgpfKWXzwgAFyNoCAACfw8A== Date: Fri, 26 Oct 2012 17:56:38 +0000 Message-ID: <3A5015FE9E557D448AF7238AF0ACE20A251BE0@IRVEXCHMB11.corp.ad.broadcom.com> References: <201210121812.37557.eugene@imedia.ru> <3A5015FE9E557D448AF7238AF0ACE20A24B0F4@IRVEXCHMB11.corp.ad.broadcom.com> <201210261227.15689.eugene@imedia.ru> In-Reply-To: <201210261227.15689.eugene@imedia.ru> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.9.208.64] MIME-Version: 1.0 X-WSS-ID: 7C94111941412155906-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 17:57:02 -0000 > > > dev.bce.3.l2fhdr_error_count: 0 > > > dev.bce.3.mbuf_alloc_failed_count: 2098856 > > > dev.bce.3.mbuf_frag_count: 2655288 > > > dev.bce.3.dma_map_addr_rx_failed_count: 0 > > > dev.bce.3.dma_map_addr_tx_failed_count: 57 > > > dev.bce.3.unexpected_attention_count: 0 > > > dev.bce.3.com_no_buffers: 0 > > > > > > > > > Any suggestions? What is the reason of this? > > > > It's normal in a system under load, the kernel can't always > > allocate memory when requested by the driver. The result > > is that RX frames will be dropped as the driver reuses an > > existing mbuf, a response taken by many other drivers. > > > > If you notice rapid increases during certain system operations > > then you should consider increasing the amount of system > > memory. > > >=20 > Thanks for you answer, Dave. >=20 > What do you mean under "systems memory"? Is it the physical memory or the > virtual one? Virtual memory is likely sufficient in this case, though more frequent swap= ping may cause an equivalent performance loss to the dropped network traffic (i.= e. you may be swapping one performance bottleneck for another). The counter=20 "dma_map_addr_*" is incremented when the OS cannot map an MBUF for DMA=20 access. If you see that incrementing as rapidly then you should definitely= look at adding physical memory. Dave From owner-freebsd-net@FreeBSD.ORG Fri Oct 26 18:12:06 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A8F51DCD; Fri, 26 Oct 2012 18:12:06 +0000 (UTC) (envelope-from np@FreeBSD.org) Received: from freefall.freebsd.org (freefall.FreeBSD.org [8.8.178.135]) by mx1.freebsd.org (Postfix) with ESMTP id 79FB98FC16; Fri, 26 Oct 2012 18:12:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q9QIC69R028527; Fri, 26 Oct 2012 18:12:06 GMT (envelope-from np@freefall.freebsd.org) Received: (from np@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q9QIC6LI028523; Fri, 26 Oct 2012 18:12:06 GMT (envelope-from np) Date: Fri, 26 Oct 2012 18:12:06 GMT Message-Id: <201210261812.q9QIC6LI028523@freefall.freebsd.org> To: np@FreeBSD.org, freebsd-net@FreeBSD.org, np@FreeBSD.org From: np@FreeBSD.org Subject: Re: kern/172364: [cxbge] cxbge_vlan_config() Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 18:12:06 -0000 Synopsis: [cxbge] cxbge_vlan_config() Fatal trap 12: page fault while in kernel mode Responsible-Changed-From-To: freebsd-net->np Responsible-Changed-By: np Responsible-Changed-When: Fri Oct 26 18:11:44 UTC 2012 Responsible-Changed-Why: I'll take this. http://www.freebsd.org/cgi/query-pr.cgi?pr=172364 From owner-freebsd-net@FreeBSD.ORG Fri Oct 26 21:40:08 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 98F67910 for ; Fri, 26 Oct 2012 21:40:08 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4D8D68FC0C for ; Fri, 26 Oct 2012 21:40:08 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so4015167oag.13 for ; Fri, 26 Oct 2012 14:40:07 -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=G+9jIEIWbYNYZBnAyFlJBb52JQvdoPgDIXG02VUk6hA=; b=TeAjTiyHZATktiPXYElIxvkV3KjLqM53BFNEBdO7aoqnlZzm1WAtT0qYgarPF0RaAE +mow4HzmIhW92buTJmydg2uFdhyXP0SqLcVH8jGRwWC+FmsErdd1IFAKENbv/F2vs/az IOsF0tNKj6u3p8QLuNYameV+uGuas2nKcA1RzF7BHx1g+g/mz4U0ozs1Io4sXQWCnEeS 4YcYhpAS9R5ls7c08HBB9tuBDFcYERR+M0AZoSSj6GvWLvcKpiFGXCSxKlYtDpUlht7e 8kJaG1kGFHW1QIuuPA7zaWkvguNAhRkQIn/VI49c6GE6/h4PPmRaOTychC7E+kuT+3xP RT9A== MIME-Version: 1.0 Received: by 10.60.21.193 with SMTP id x1mr13776278oee.142.1351287607710; Fri, 26 Oct 2012 14:40:07 -0700 (PDT) Received: by 10.182.133.40 with HTTP; Fri, 26 Oct 2012 14:40:07 -0700 (PDT) In-Reply-To: <70DCE61F-E1B9-445F-A3F6-BC90646FA2AE@netasq.com> References: <792D5931-19E7-4239-A3E8-5D2BC90F03FD@netasq.com> <70DCE61F-E1B9-445F-A3F6-BC90646FA2AE@netasq.com> Date: Fri, 26 Oct 2012 23:40:07 +0200 Message-ID: Subject: Re: ixgbe and ixgbevf drivers are not working in virtualization environment From: Sami Halabi To: =?ISO-8859-1?Q?R=E9mi_Pauchet?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org, Jack Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 21:40:08 -0000 Hi, did you try explicit "ifconfig ix0 up" instead of rebooting? Sami On Thu, Oct 25, 2012 at 4:29 PM, R=E9mi Pauchet wr= ote: > more informations about the SR-IOV issue. > > The problem is that the link is not updated in the virtual machine (VF > driver). > > ie: I start the VM with my fiber unplugged, the vf link is "no carrier". > I plug the fiber, the link stays in state "no carrier". > If I reboot the vm, I get the active link. > I reproduce the issue with esxi 5.1 and xenserver 6 > > > On other hand, I still haven't managed to get an active link with VMWare > DirectPath. > > Regards, > R=E9mi > > > Le 17 oct. 2012 =E0 09:42, R=E9mi Pauchet a =E9crit : > > > Hi > > > > My interface is configured, UP and running and I still can't get a link > > > > Can you help me with this issue ? > > > > Regards, > > R=E9mi > > > > > > Le 12 oct. 2012 =E0 09:38, R=E9mi Pauchet a =E9crit : > > > >> Hi, > >> > >> Unfortunately not: > >> > >> ix0: flags=3D8843 metric 0 mtu > 1500 > >> > options=3D401bb > >> ether 00:e0:ed:1c:99:4e > >> inet 172.16.255.254 netmask 0xffff0000 broadcast 172.16.255.255 > >> inet6 fe80::2e0:edff:fe1c:994e%ix0 prefixlen 64 scopeid 0x2 > >> nd6 options=3D29 > >> media: Ethernet autoselect > >> status: no carrier > >> ix1: flags=3D8843 metric 0 mtu > 1500 > >> > options=3D401bb > >> ether 00:e0:ed:1c:99:4f > >> inet 172.17.255.254 netmask 0xffff0000 broadcast 172.17.255.255 > >> inet6 fe80::2e0:edff:fe1c:994f%ix1 prefixlen 64 scopeid 0x3 > >> nd6 options=3D29 > >> media: Ethernet autoselect > >> status: no carrier > >> > >> Regards, > >> R=E9mi > >> > >> Le 11 oct. 2012 =E0 18:25, Jack Vogel a =E9crit : > >> > >>> The ixgbe device will not get link until you have run init, so assign > it an address or just do an ifconfig up. > >>> > >>> I have never used the driver using a passthru type setup but I believ= e > its been done successfully if > >>> memory serves. > >>> > >>> Jack > >>> > >>> > >>> On Thu, Oct 11, 2012 at 8:39 AM, R=E9mi Pauchet > wrote: > >>> Hi, > >>> > >>> I'm trying to use the ixgbe (10Gb) driver in a FreeBSD virtual machin= e > on an esxi 5 using DirectPath (PCI Passthrough) and the card is detected, > but I can't get a link (status: no carrier) > >>> > >>> ix0: > mem 0xd2420000-0xd243ffff,0xd2400000-0xd2403fff irq 18 at device 0.0 on p= ci3 > >>> > >>> ix0: flags=3D8802 metric 0 mtu 1500 > >>> > options=3D401bb > >>> ether 00:e0:ed:1c:99:4e > >>> nd6 options=3D29 > >>> media: Ethernet autoselect > >>> status: no carrier > >>> > >>> I have also tested with XenServer 6, using SR-IOV (ixgbevf driver) > with the same result: the driver is loading, but no link detected. > >>> > >>> In both case (VMWare DirectPath and XenServer SR-IOV), I tested Linux > with success. > >>> > >>> > >>> The card is an Intel 82599EB, the motherboard is an Intel X58 > (supermicro X8ST3) with a Xeon W3680 and I've tested FreeBSD 8.3 and 9.0 > >>> > >>> I've found a forum thread with the same issue: > http://forums.freebsd.org/showthread.php?t=3D29855 and no answer :) > >>> > >>> > >>> Please find in attachment the dmesg (boot -v) with the ix driver > compiled with DEBUG flags using vmware. > >>> > >>> > >>> Can anyone provide feedback about this issue ? > >>> > >>> Regards, > >>> R=E9mi Pauchet > >>> > >>> > >>> > >> > > > > --=20 Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-net@FreeBSD.ORG Sat Oct 27 01:23:26 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CCB0F741 for ; Sat, 27 Oct 2012 01:23:26 +0000 (UTC) (envelope-from prvs=16475b8f6d=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 56B5D8FC08 for ; Sat, 27 Oct 2012 01:23:25 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50000842250.msg for ; Sat, 27 Oct 2012 02:23:18 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sat, 27 Oct 2012 02:23:18 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=16475b8f6d=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <957BF31540DC46E1A043DE37EDCC9827@multiplay.co.uk> From: "Steven Hartland" To: "Sami Halabi" , =?iso-8859-1?Q?R=E9mi_Pauchet?= References: <792D5931-19E7-4239-A3E8-5D2BC90F03FD@netasq.com> <70DCE61F-E1B9-445F-A3F6-BC90646FA2AE@netasq.com> Subject: Re: ixgbe and ixgbevf drivers are not working in virtualization environment Date: Sat, 27 Oct 2012 02:23:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-net@freebsd.org, Jack Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2012 01:23:26 -0000 Link detect in ix is indeed odd even when not virtualised :( ----- Original Message ----- From: "Sami Halabi" did you try explicit "ifconfig ix0 up" instead of rebooting? ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Sat Oct 27 02:29:28 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 16FA622C; Sat, 27 Oct 2012 02:29:28 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.FreeBSD.org [8.8.178.135]) by mx1.freebsd.org (Postfix) with ESMTP id DAF348FC1A; Sat, 27 Oct 2012 02:29:27 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q9R2TRte077972; Sat, 27 Oct 2012 02:29:27 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q9R2TRDu077968; Sat, 27 Oct 2012 02:29:27 GMT (envelope-from linimon) Date: Sat, 27 Oct 2012 02:29:27 GMT Message-Id: <201210270229.q9R2TRDu077968@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/173137: [em] em(4) unable to run at gigabit with 9.1-RC2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2012 02:29:28 -0000 Old Synopsis: em(4) unable to run at gigabit with 9.1-RC2 New Synopsis: [em] em(4) unable to run at gigabit with 9.1-RC2 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Oct 27 02:29:14 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=173137 From owner-freebsd-net@FreeBSD.ORG Sat Oct 27 23:18:18 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 10F08146; Sat, 27 Oct 2012 23:18:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id C8C1A8FC08; Sat, 27 Oct 2012 23:18:17 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so3694252pbb.13 for ; Sat, 27 Oct 2012 16:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=b96HYW36O5OHgYA4N07oUosCjfyz74N2NZAf+fsnM4Q=; b=VQeC5nviTcpZ0XEzRvnzrUJHDa7yPt7Q3hFZgvnraMKIn1AXMHAapjEa8pgDxvzHAU NS1X3QuCPafeN0utWT1HQ0kABf6Qy2NEaYQ6hdmuMlnTKTp4CN8jH7HTmzNtOAPwoAdF ET9E1dKgvCbXfOu1YZ1k1+TvTyIQrCDklCb4Janu2D8grYyQamQJyPKyAs07yI9v/Jr3 llxFQ8WjtrR+ZH4S8HhH0OfQOZjMFTpOvxipDDdmTS4mwH8MDMxG3Da580DsPUYaHqWm 8hyX/9oAxqDI57xRz3VHG08WIFtWR/ejFckV8yRdef7AqeiEp/82wkMwVjlOnIarn0JJ Gt/w== MIME-Version: 1.0 Received: by 10.68.235.68 with SMTP id uk4mr81178726pbc.52.1351379891789; Sat, 27 Oct 2012 16:18:11 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.146.233 with HTTP; Sat, 27 Oct 2012 16:18:11 -0700 (PDT) Date: Sat, 27 Oct 2012 16:18:11 -0700 X-Google-Sender-Auth: KruR67QSYLbPCbg8rXh8L-ec5cI Message-ID: Subject: request for help: 'fixing' the 802.11 TX path From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , freebsd-arch@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2012 23:18:18 -0000 Hi all, I'd like to try and sort out the last remaining niggles in the 802.11 code - this email is focusing on the TX path. The TX path has a few problems: * there's a normal versus raw TX path (for raw frames, management frames, etc) - the raw path doesn't necessarily queue frames into the raw TX queue, so it's a kind of "side path" to the driver. This causes frame ordering problems with things like sequence number allocation. * there's limited locking in the TX path, primarily because you can't _really_ fine grain lock the TX path. Since you have multiple TX thread contexts all sending into the same driver queue and that queue has to share incrementing sequence number, aggregate status and CCMP encryption replay counters, you _have_ to either use some long-held mutexes to enforce this _or_ throw all sending into a TX thread and run that. * raw TX requires some extra state to be glued (the bpf_params info); I'd like to glue that into mbufs as an option, so the driver can use those instead of interpreting their own 802.11 header contents. And the one I'd like to discuss here: * Fragment transmission is totally broken and causes mbufs to be just leaked. The problem with sending fragments (at least for the ath drivr) is the packet duration calcluation requires the _next_ fragment to be available. Now, this is a design hold-over from the previous, pre-vap scheme. The driver netif would be handed a raw mbuf frame, which it would then pass through the net80211 encapsulation code and that would potentially generate 802.11 fragments. The rest of the driver TX path would then see that it was handed a fragment list and TX those. Fragments were chained together using m_nextpkt, like a normal mbuf list. This doesn't happen any longer. The net80211 vap gets the raw frame, which then sends that to the driver netif after doing the vap and 802.11 state / encapsulation work. But since all the wifi drivers use if_start() right now, m_nextpkt gets blanked on both encap and decap.. and thus things leak. Now I can't really see a way around this, without doing dirty hacks with mbuf attributes to link the fragments together. The only clean way I can see is to force all wifi drivers to use if_transmit(), and then have if_transmit() interpret a chain of frames as "the fragment list." I'm tempted to just create a new TX ic method which does what if_transmit does(), and ignore the if_start/if_transmit stuff altogether. That way any changes to if_transmit() in the future (where people may decide to have if_transmit() take a _list_ of frames to transmit) doesn't screw me. Right now if_transmit() API just sends a single frame to the driver in question, so I also don't want to abuse the semantics there to include "oh, and also fragments." I'd like to get this in soon as I'm going to have to change a bunch of wireless code in all the drivers as well as the wifi stack and this is likely going to have some fallout. I'd like to do his before 10.0 branches. I'm open to suggestions/comments. :-) Thanks! Adrian