From owner-freebsd-net@FreeBSD.ORG Sun Sep 28 01:24:07 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9EF1AB29; Sun, 28 Sep 2014 01:24:07 +0000 (UTC) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 65AFFBC7; Sun, 28 Sep 2014 01:24:07 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id tp5so13164824ieb.10 for ; Sat, 27 Sep 2014 18:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=AdousNTctSmRSRsVmCCk0X5R9kyIJbCGiQnvGwvT6L0=; b=yOhqfRv52ee5sCwsVM8uwJOftwEU7diglfAPnJReFwYGcN8YsBDgfyztnUFOSaUGqJ lLKR87iRl0O7pHTNUcoow8bEh9dX5fj7xPYyHpuhjj3RzsEHKmohWV+R9UvP6mdIAGNa VVQF0jnkRbNAXU2K+jp2dMVGoq+r2PnshFaGUtcpfgq+EjgKc/SIdDFmg/HL+pBQOdEf cyu8nfJyJ/eoQehwW9jiiiPMq3T2TfAqhToggEUOdMhADzyOrk/fiGMAGsCfCCRFb8ne xnksuBnB+KZT3E3vkZv/6/qaNlFD5kquZgAz1YJw76R4rIwrTbmUaasRKtqbsWSE9sF3 fa0A== MIME-Version: 1.0 X-Received: by 10.42.237.197 with SMTP id kp5mr7326482icb.49.1411867446753; Sat, 27 Sep 2014 18:24:06 -0700 (PDT) Sender: danny.j.mitzel@gmail.com Received: by 10.107.13.139 with HTTP; Sat, 27 Sep 2014 18:24:06 -0700 (PDT) In-Reply-To: References: <1411826158.72985.YahooMailNeo@web172803.mail.ir2.yahoo.com> Date: Sat, 27 Sep 2014 18:24:06 -0700 X-Google-Sender-Auth: qRbf8ARfdeyp7T1t-daExHG6u0A Message-ID: Subject: Re: vlan id 0 From: "Danny J. Mitzel" To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" , Tony Moseby X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 28 Sep 2014 01:24:07 -0000 On Sat, Sep 27, 2014 at 4:44 PM, Adrian Chadd wrote: > .. the spec allows vlan id=0? 0 is not a valid VLAN ID but the specs do allow it in a tagged packet, it's called "Priority tagged". The priority bits should be interpreted when making any queuing / scheduling decisions during forwarding. The VLAN ID bits are ignored and packet is to be treated as untagged during forwarding / flooding decisions. From owner-freebsd-net@FreeBSD.ORG Sun Sep 28 08:09:58 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26D35A4F for ; Sun, 28 Sep 2014 08:09:58 +0000 (UTC) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E9294182 for ; Sun, 28 Sep 2014 08:09:57 +0000 (UTC) Received: by mail-ob0-f177.google.com with SMTP id vb8so917960obc.36 for ; Sun, 28 Sep 2014 01:09:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=z9/OWe9/TtlQSHIWxbZ2iqmPcsKxt1MYTdm6HNM6JLE=; b=N4Ii+NzZMfjTJ/KcuWGZ+1UP5aIE6MbET+KxgMfebckzCmype70B0x0Y52MWoI4vU/ buN5CvLBmZy2yo9eKwTLUgWWGiyCpP2aK/j9U/riqTehNYLyxk0eROFUPTHobKD/IWJS Q8dNmB7OaVv/wFPv40j5Ksav2aMz0mNn6gDADQavLgukTVrP8bZjwKs4KgtnB8IpIz8N N23r+NfZ20FwNoeN2VoJ65doWfoNAIf9UJj4Zwt5htyNpf3sQuMqK7v+uUo6VKleusgz 8OyYRnX1ISTjRWsrVG5d68bSwutK8WKL6BxLUDD9Vrzgv70qrfMluCWgRFoDLQM8fs9Z pGbw== X-Received: by 10.60.161.68 with SMTP id xq4mr737788oeb.84.1411891797060; Sun, 28 Sep 2014 01:09:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.34.105 with HTTP; Sun, 28 Sep 2014 01:09:36 -0700 (PDT) From: Long Tran Date: Sun, 28 Sep 2014 03:09:36 -0500 Message-ID: Subject: Compiling netmap in Ubuntu 14.04 in VMWare To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "Gurkan, Deniz" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 28 Sep 2014 08:09:58 -0000 Hello, I am trying to compile netmap on my VM Ubuntu 14.04 but getting this error: make -C /lib/modules/3.13.0-29-generic/build M=/home/kl/Workspaces/netmap/LINUX CONFIG_NETMAP=m CONFIG_E1000=m CONFIG_E1000E=m CONFIG_IXGBE=m CONFIG_IGB=m CONFIG_BNX2X=m CONFIG_MLX4=m CONFIG_VIRTIO_NET=m \ EXTRA_CFLAGS='-I/home/kl/Workspaces/netmap/LINUX -I/home/kl/Workspaces/netmap/LINUX/../sys -I/home/kl/Workspaces/netmap/LINUX/../sys/dev -DCONFIG_NETMAP -Wno-unused-but-set-variable' \ O_DRIVERS="e1000/ e1000e/ igb/ ixgbe/" modules make[1]: Entering directory `/usr/src/linux-headers-3.13.0-29-generic' make[1]: Leaving directory `/usr/src/linux-headers-3.13.0-29-generic' I have downloaded the linux source code and copy the drivers in the intel directory to this directory before compiling: /lib/modules/3.13.0-29-generic/build/drivers/net/ethernet/intel/ Is that the problem with my vm or am I missing any steps to compile the netmap? Thank you, Long Tran. From owner-freebsd-net@FreeBSD.ORG Sun Sep 28 13:38:57 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34951D7 for ; Sun, 28 Sep 2014 13:38:57 +0000 (UTC) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ECE89235 for ; Sun, 28 Sep 2014 13:38:56 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id v10so2322672qac.15 for ; Sun, 28 Sep 2014 06:38:56 -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:content-type; bh=pvr0K7NQv5FeS4rG1v81l2ZbjL8Dnkmz5Ea8RkidGBY=; b=A4t9rRURFGYayK0wAjkdJLn9RF/ud/g/m7YayHroRh2OEoBPB5Fee388e4h4bM+kOB dy2lqnfqgM1N1JsBLgYAAdxc/zpEnZ9VeVcREBoLp3IJx7fZmCkSUHyd2AqehZ9IcqOS 3hCmxGM1jwbDvnhISOiSYVfe3Tz2o43f1upV3az0uZnhPfuI53RGLResgbcQXURd9vAo KbdVwZtSLztAdvi+o9n3mTKW6pNXFPxVOe3j4ZmIi+cDGw8h94nUR/y2B9H8lbcqpqiX 9Ykmch5MJtuDAcSXLLgUhrTNxwlWRIsL/AkIJ3WbhrtK4itCoCrb3L9wLJMig08g0i3O VbAA== MIME-Version: 1.0 X-Received: by 10.224.20.9 with SMTP id d9mr44036590qab.7.1411911536102; Sun, 28 Sep 2014 06:38:56 -0700 (PDT) Received: by 10.229.234.194 with HTTP; Sun, 28 Sep 2014 06:38:56 -0700 (PDT) Date: Sun, 28 Sep 2014 17:08:56 +0330 Message-ID: Subject: Re: Compiling netmap in Ubuntu 14.04 in VMWare From: Mahnaz Talebi To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 28 Sep 2014 13:38:57 -0000 Are you install kernel sources and headers? From owner-freebsd-net@FreeBSD.ORG Sun Sep 28 18:32:39 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7EC8E350 for ; Sun, 28 Sep 2014 18:32:39 +0000 (UTC) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 401A3754 for ; Sun, 28 Sep 2014 18:32:39 +0000 (UTC) Received: by mail-vc0-f172.google.com with SMTP id lf12so731239vcb.3 for ; Sun, 28 Sep 2014 11:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=WdifIGmmQdzEV971Y4d7rTDDWTruDGHYiWyKZx5NNmI=; b=ISLmiyE6j3KVDCcX84EPfHjWKtUFJvVIqrTi2fEMy4C0W2b/G+Wyc6tHbitmwPNp7T nqmBo4iwQrE6jugOwdS9hiMqQPXGD7c9KmwUHLdWwv/Wg75iAgIT4BQvs9ymrsV4z535 95qTl89oSbYYoIgkxQpNR/ocdkCXXay+nPR6XfiCSO09Sd8C8kkx9+vZTHghMGAv+KmN PILYn7xKJm/K3i+rqP5Nt4+CV58b9J8zrzczuaSHAvkwj8pttPydfnNChWGf+DlTExyl bOKHO4btu/HzSQDtpO/n2DVyqMRVNKlp+YHz7uu/3eF8FtCpHj5c1zJn6BIBwsScQYeR fKgQ== X-Received: by 10.221.62.133 with SMTP id xa5mr1705418vcb.41.1411929158268; Sun, 28 Sep 2014 11:32:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.167.193 with HTTP; Sun, 28 Sep 2014 11:32:08 -0700 (PDT) From: Long Tran Date: Sun, 28 Sep 2014 13:32:08 -0500 Message-ID: Subject: Re: Compiling netmap in Ubuntu 1.04 in VMWare To: mhnz.talebi@gmail.com Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "Gurkan, Deniz" , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 28 Sep 2014 18:32:39 -0000 Hi Mahnaz, I installed the headers and sources using these commands: sudo apt-get install linux-headers-3.13.0-29 sudo apt-get install linux-source-3.13.0 Thanks, -- *Long Tran* Research Assistant MS in Network Communications and Technology Project Management University of Houston From owner-freebsd-net@FreeBSD.ORG Sun Sep 28 20:50:36 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30C8A4A9 for ; Sun, 28 Sep 2014 20:50:36 +0000 (UTC) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AEE825E2 for ; Sun, 28 Sep 2014 20:50:35 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id ty20so4436899lab.27 for ; Sun, 28 Sep 2014 13:50:33 -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=5WNdoEaBPdDVJQFl7QVcNeVrRmyKOXEKHuWFBKIQPw0=; b=Z9sK7KBxt2B67Mr3gk4eIQJalS+9DNz8gHD7ix+y+VhRCfiQ3OCcCYoERGQmF4BJV7 jDDRat+ruOksFhslu1mFJCgNzfQNgirJCw9vLo6eUVZZLDejWYAllDdD38CEKY8yJR2n 38gIp8uK2P7iuHcvRIAi12gWYk6CrLpQDTBXMj4195QPXEnf9I7+sl9rK3FKW3CtRnQU 43hOKGPmWzFNcRWo2O98sJIVZkJ0JLaUcjzwjI/i9schKAdiIuOk1OXC+DJ5z+ZQVpQi Ipk1ZBjkwJkdMGomaY8mABGWGpcgegAS1yw2bt4QJAP79zeXZ0f+UILQAU+esogA3Rmh ec/Q== MIME-Version: 1.0 X-Received: by 10.112.140.137 with SMTP id rg9mr4276610lbb.93.1411937433649; Sun, 28 Sep 2014 13:50:33 -0700 (PDT) Received: by 10.25.167.2 with HTTP; Sun, 28 Sep 2014 13:50:33 -0700 (PDT) In-Reply-To: References: Date: Sun, 28 Sep 2014 22:50:33 +0200 Message-ID: Subject: Re: Compiling netmap in Ubuntu 14.04 in VMWare From: Andreas Nilsson To: Long Tran Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "Gurkan, Deniz" , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 28 Sep 2014 20:50:36 -0000 On Sun, Sep 28, 2014 at 10:09 AM, Long Tran wrote: > Hello, > > I am trying to compile netmap on my VM Ubuntu 14.04 but getting this error: > > make -C /lib/modules/3.13.0-29-generic/build > M=/home/kl/Workspaces/netmap/LINUX CONFIG_NETMAP=m CONFIG_E1000=m > CONFIG_E1000E=m CONFIG_IXGBE=m CONFIG_IGB=m CONFIG_BNX2X=m CONFIG_MLX4=m > CONFIG_VIRTIO_NET=m \ > EXTRA_CFLAGS='-I/home/kl/Workspaces/netmap/LINUX > -I/home/kl/Workspaces/netmap/LINUX/../sys > -I/home/kl/Workspaces/netmap/LINUX/../sys/dev -DCONFIG_NETMAP > -Wno-unused-but-set-variable' \ > O_DRIVERS="e1000/ e1000e/ igb/ ixgbe/" modules > make[1]: Entering directory `/usr/src/linux-headers-3.13.0-29-generic' > make[1]: Leaving directory `/usr/src/linux-headers-3.13.0-29-generic' > > I have downloaded the linux source code and copy the drivers in the intel > directory to this directory before compiling: > /lib/modules/3.13.0-29-generic/build/drivers/net/ethernet/intel/ > > Is that the problem with my vm or am I missing any steps to compile the > netmap? > > Thank you, > Long Tran. > Are sure you getting an error? I see no error in the output. What happens if you type make again? What happens when you run the install target ( I don't remember the name, if it is install modules_install, but it should be in the notes (or Makefile obviously). Best regards Andeas From owner-freebsd-net@FreeBSD.ORG Sun Sep 28 21:13:48 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62BECFB for ; Sun, 28 Sep 2014 21:13:48 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 39D7B959 for ; Sun, 28 Sep 2014 21:13:48 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8SLDmkY053835 for ; Sun, 28 Sep 2014 21:13:48 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201409282113.s8SLDmkY053835@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-net@FreeBSD.org Subject: Problem reports for freebsd-net@FreeBSD.org that need special attention X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Sun, 28 Sep 2014 21:13:48 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 28 Sep 2014 21:13:48 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ----------------+-----------+------------------------------------------------- Needs MFC | 183659 | [tcp] TCP stack lock contention with short-live 1 problems total for which you should take action. From owner-freebsd-net@FreeBSD.ORG Mon Sep 29 06:30:21 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A2F31AA for ; Mon, 29 Sep 2014 06:30:21 +0000 (UTC) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 079A9696 for ; Mon, 29 Sep 2014 06:30:20 +0000 (UTC) Received: by mail-vc0-f180.google.com with SMTP id hq12so4000908vcb.39 for ; Sun, 28 Sep 2014 23:30:20 -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=lR1SEFKNDZUGLKrnBZbrMjEo+cTn6UOq/g0z77naF9A=; b=C8jl2g12IR1bH0GJ6iPaLdVyza6aqxhX1YMmwr9HMaOT8xNCTiL1WCEHSGQtjdnZpY 0fqQdMYIvy8liHo9MGbOYwf69rqXOE6qANVrjNxs+4KIUOWUEBzVQa+fkrFq3zPJUVy1 qHFXnogVXp5FvlbXFcH6afhu0uHBpKKwsvs2txGRshGgpVF+ILysvPkAbtUiMabT47X2 9LyEBB1ZhzF176nRq8CSl60LLk72YQFpXJH20VOQrhWj7lp4BJrXNtS7xymhi8XjHvmc 7uyPY4SHE8AfzqWzQGO5H0DQb0O12j2F4neapJ3/tpJclrc68ivE5aNma2Flb9vKWnsu 4j+w== X-Received: by 10.220.105.148 with SMTP id t20mr28703352vco.11.1411972220077; Sun, 28 Sep 2014 23:30:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.167.193 with HTTP; Sun, 28 Sep 2014 23:29:50 -0700 (PDT) In-Reply-To: References: From: Long Tran Date: Mon, 29 Sep 2014 01:29:50 -0500 Message-ID: Subject: Re: Compiling netmap in Ubuntu 14.04 in VMWare To: Andreas Nilsson Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "Gurkan, Deniz" , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 29 Sep 2014 06:30:21 -0000 Hi Andreas, I'm sorry. I redirected the output of make command to a file but forgot to redirect the error. This is the error: make -C /lib/modules/3.13.0-29-generic/build M=/home/kl/Workspaces/netmap/LINUX CONFIG_NETMAP=m CONFIG_E1000=m CONFIG_E1000E=m CONFIG_IXGBE=m CONFIG_IGB=m CONFIG_BNX2X=m CONFIG_MLX4=m CONFIG_VIRTIO_NET=m \ EXTRA_CFLAGS='-I/home/kl/Workspaces/netmap/LINUX -I/home/kl/Workspaces/netmap/LINUX/../sys -I/home/kl/Workspaces/netmap/LINUX/../sys/dev -DCONFIG_NETMAP -Wno-unused-but-set-variable' \ O_DRIVERS="e1000/ e1000e/ igb/ ixgbe/" modules make[1]: Entering directory `/usr/src/linux-headers-3.13.0-29-generic' *make[3]: *** No rule to make target `/home/kl/Workspaces/netmap/LINUX/e1000/e1000_main.o', needed by `/home/kl/Workspaces/netmap/LINUX/e1000/e1000.o'. Stop.make[2]: *** [/home/kl/Workspaces/netmap/LINUX/e1000] Error 2make[1]: *** [_module_/home/kl/Workspaces/netmap/LINUX] Error 2* make[1]: Leaving directory `/usr/src/linux-headers-3.13.0-29-generic' make: *** [build] Error 2 I searched in the Makefile but couldn't find the module_install. Also, it seems like the Makefile contains only the rules for building the modules, not installing them. Thank you, On Sun, Sep 28, 2014 at 3:50 PM, Andreas Nilsson wrote: > > On Sun, Sep 28, 2014 at 10:09 AM, Long Tran > wrote: > >> Hello, >> >> I am trying to compile netmap on my VM Ubuntu 14.04 but getting this >> error: >> >> make -C /lib/modules/3.13.0-29-generic/build >> M=/home/kl/Workspaces/netmap/LINUX CONFIG_NETMAP=m CONFIG_E1000=m >> CONFIG_E1000E=m CONFIG_IXGBE=m CONFIG_IGB=m CONFIG_BNX2X=m CONFIG_MLX4=m >> CONFIG_VIRTIO_NET=m \ >> EXTRA_CFLAGS='-I/home/kl/Workspaces/netmap/LINUX >> -I/home/kl/Workspaces/netmap/LINUX/../sys >> -I/home/kl/Workspaces/netmap/LINUX/../sys/dev -DCONFIG_NETMAP >> -Wno-unused-but-set-variable' \ >> O_DRIVERS="e1000/ e1000e/ igb/ ixgbe/" modules >> make[1]: Entering directory `/usr/src/linux-headers-3.13.0-29-generic' >> make[1]: Leaving directory `/usr/src/linux-headers-3.13.0-29-generic' >> >> I have downloaded the linux source code and copy the drivers in the intel >> directory to this directory before compiling: >> /lib/modules/3.13.0-29-generic/build/drivers/net/ethernet/intel/ >> >> Is that the problem with my vm or am I missing any steps to compile the >> netmap? >> >> Thank you, >> Long Tran. >> > > Are sure you getting an error? I see no error in the output. What happens > if you type make again? What happens when you run the install target ( I > don't remember the name, if it is install modules_install, but it should be > in the notes (or Makefile obviously). > > Best regards > Andeas > -- *Long Tran* Research Assistant MS in Network Communications and Technology Project Management University of Houston From owner-freebsd-net@FreeBSD.ORG Mon Sep 29 06:44:07 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9AD4038D for ; Mon, 29 Sep 2014 06:44:07 +0000 (UTC) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 57D40886 for ; Mon, 29 Sep 2014 06:44:07 +0000 (UTC) Received: by mail-vc0-f176.google.com with SMTP id hq11so2313634vcb.35 for ; Sun, 28 Sep 2014 23:44:06 -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=gV5BGp2VXkWjWafgVrSjJ2tf82WAyCH8Kxjw+iF6afA=; b=PnOzItGU9/xDGb7R4cjr2dGmRnP+WyC7DbWVbSX9vNxL49wyFzHVZOkoZ996sg12ku 3JOs+amwueoSJK0YoHLChhC+68FS/ab7Kcc6ikMDJp3cIEUb7HelO+/zV1S9Ea6qNg2G k+UymZgOnoi9SoBiMXr+eHFJklgwb/9gdyRmdZuRHVGHtRIsvFuG7Po6RXWiV4KhCZAM 7BPZcTVOruNIlAJkY0mjnX23zF6GA2SuGrQTuOPs1OWt0wpEWycFuz6cDGnP/o5+KxQU PovT1L1+BmEQ2aP0vb9q0TZeMfof3o4x+veBxMcnIVUXJcpC0syBcL9a8mVYzrjE4jMU jlqQ== X-Received: by 10.220.202.202 with SMTP id ff10mr28507965vcb.15.1411973046428; Sun, 28 Sep 2014 23:44:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.167.193 with HTTP; Sun, 28 Sep 2014 23:43:36 -0700 (PDT) In-Reply-To: References: From: Long Tran Date: Mon, 29 Sep 2014 01:43:36 -0500 Message-ID: Subject: Re: Compiling netmap in Ubuntu 1.04 in VMWare To: Mahnaz Talebi Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "Gurkan, Deniz" , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 29 Sep 2014 06:44:07 -0000 Hi Mahnaz, This is my kernel: 3.13.0-29-generic I don't know if this path contains the drivers that supported by my kernel: /lib/modules/3.13.0-29-generic/kernel/drivers/net/ethernet/intel/ These are what in side that path: e1000 e1000e e100.c e100.ko i40e i40evf igb igbvf ixgb ixgbe ixgbevf Kconfig Makefile In the patches directory, I found these: e1000 e1000e igb ixgbe So I guess my kernel has the drivers supported by netmap. Also, I forgot to include the error when I run the make command. Here it is: make -C /lib/modules/3.13.0-29-generic/build M=/home/kl/Workspaces/netmap/LINUX CONFIG_NETMAP=m CONFIG_E1000=m CONFIG_E1000E=m CONFIG_IXGBE=m CONFIG_IGB=m CONFIG_BNX2X=m CONFIG_MLX4=m CONFIG_VIRTIO_NET=m \ EXTRA_CFLAGS='-I/home/kl/Workspaces/netmap/LINUX -I/home/kl/Workspaces/netmap/LINUX/../sys -I/home/kl/Workspaces/netmap/LINUX/../sys/dev -DCONFIG_NETMAP -Wno-unused-but-set-variable' \ O_DRIVERS="e1000/ e1000e/ igb/ ixgbe/" modules make[1]: Entering directory `/usr/src/linux-headers-3.13.0-29-generic' *make[3]: *** No rule to make target `/home/kl/Workspaces/netmap/LINUX/e1000/e1000_main.o', needed by `/home/kl/Workspaces/netmap/LINUX/e1000/e1000.o'. Stop.make[2]: *** [/home/kl/Workspaces/netmap/LINUX/e1000] Error 2make[1]: *** [_module_/home/kl/Workspaces/netmap/LINUX] Error 2make[1]: Leaving directory `/usr/src/linux-headers-3.13.0-29-generic'make: *** [build] Error 2* The thing is my laptop has intel card, but I don't know if my VM (I am using VMWare) has that card. Right now, I create four NICs for my VM: host only, bridge to my host's ethernet, bridge to my wireless card, and two other private NICs that connect privately within different VMs. Do you think that is the problem VM, not netmap itself? Thank you, *Long Tran* Research Assistant MS in Network Communications and Technology Project Management University of Houston On Mon, Sep 29, 2014 at 12:07 AM, Mahnaz Talebi wrote: > What is your kernel? Are you check list of supported drivers to see if > your kernel's drivers are supported whit the your version of netmap? > Supported drivers are in folder patch and their name show their supported > kernels. > > On Sun, Sep 28, 2014 at 10:02 PM, Long Tran > wrote: > >> Hi Mahnaz, >> >> I installed the headers and sources using these commands: >> sudo apt-get install linux-headers-3.13.0-29 >> sudo apt-get install linux-source-3.13.0 >> >> Thanks, >> -- >> *Long Tran* >> Research Assistant >> MS in Network Communications and Technology Project Management >> University of Houston >> > > From owner-freebsd-net@FreeBSD.ORG Mon Sep 29 07:36:46 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3761CE52 for ; Mon, 29 Sep 2014 07:36:46 +0000 (UTC) Received: from HOBEX29.hob.de (hobex29.hob.de [212.185.199.32]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "hobex29", Issuer "hobex29" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6CAD1D96 for ; Mon, 29 Sep 2014 07:36:44 +0000 (UTC) Received: from HOBEX22.hob.de (172.22.1.22) by hobex29.hob.de (172.25.1.32) with Microsoft SMTP Server (TLS) id 14.2.347.0; Mon, 29 Sep 2014 09:34:59 +0200 Received: from HOBEX21.hob.de ([fe80::886:fbb5:dd12:7a2f]) by HOBEX22.hob.de ([::1]) with mapi id 14.02.0387.000; Mon, 29 Sep 2014 09:35:28 +0200 From: "Leupoldt, Martin" To: 'Stefano Garzarella' Subject: RE: netmap on ubuntu 14.04? Thread-Topic: netmap on ubuntu 14.04? Thread-Index: Ac/Zi8NjHSQcge1oS3immNdS/agA8wAGji8AAIRwDEA= Date: Mon, 29 Sep 2014 07:35:27 +0000 Message-ID: <321E74F3FD7B9B478555010DC1AFD5D5C735958E@HOBEX21.hob.de> References: <321E74F3FD7B9B478555010DC1AFD5D5C7357FD8@HOBEX21.hob.de> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.10.202] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 29 Sep 2014 07:36:46 -0000 SGVsbG8gU3RlZmFubywNCg0KbWFueSB0aGFua3MgZm9yIHlvdXIgcmVwbHkuIEkgdGhpbmsgaXRz IGxvb2tpbmcgYmV0dGVyIG5vdzoNCg0KcHJvZzAxQHZwbjExNTp+L25ldG1hcC0zY2NkYWRhZDdk ODAvZXhhbXBsZXMkIHN1ZG8gLi9icmlkZ2UgLWkgbmV0bWFwOmV0aDEgLWkgbmV0bWFwOmV0aDIN Ci4vYnJpZGdlIGJ1aWx0IFNlcCAxMCAyMDE0IDA5OjM3OjAwDQowMzEuOTY0NTEyIG1haW4gWzI0 NF0gLS0tLS0tLSB6ZXJvY29weSBzdXBwb3J0ZWQNCjAzMS45NjQ1NTIgbWFpbiBbMjUxXSBXYWl0 IDQgc2VjcyBmb3IgbGluayB0byBjb21lIHVwLi4uDQowMzUuOTY0NjQ2IG1haW4gWzI1NV0gUmVh ZHkgdG8gZ28sIGV0aDEgMHgwLzEgPC0+IGV0aDIgMHgwLzEuDQoNCkJlc3QgcmVnYXJkcw0KTWFy dGluDQoNCkZyb206IFN0ZWZhbm8gR2FyemFyZWxsYSBbbWFpbHRvOnN0ZWZhbm9nYXJ6YXJlbGxh QGdtYWlsLmNvbV0NClNlbnQ6IEZyZWl0YWcsIDI2LiBTZXB0ZW1iZXIgMjAxNCAyMDoyMg0KVG86 IExldXBvbGR0LCBNYXJ0aW4NCkNjOiBmcmVlYnNkLW5ldEBmcmVlYnNkLm9yZw0KU3ViamVjdDog UmU6IG5ldG1hcCBvbiB1YnVudHUgMTQuMDQ/DQoNCkhpIE1hcnRpbiwNCmNhbiB5b3UgdHJ5IGlu IHRoaXMgd2F5ICJzdWRvIC4vYnJpZGdlIC1pIG5ldG1hcDpldGgxIj8NCg0KbmV0bWFwOmV0aDEg bWVhbnMgdGhhdCBldGgxIGlzIHB1dCBpbiBuZXRtYXAgbW9kZS4NCg0KDQpDaGVlcnMsDQpTdGVm YW5vDQoNCjIwMTQtMDktMjYgMTY6MTkgR01UKzAzOjAwIExldXBvbGR0LCBNYXJ0aW4gPG1hcnRp bi5sZXVwb2xkdEBob2IuZGU8bWFpbHRvOm1hcnRpbi5sZXVwb2xkdEBob2IuZGU+PjoNCkhlbGxv IHRvZ2V0aGVyLA0KDQpoYXMgYW55b25lIGV4cGVyaWVuY2UgYWJvdXQgbmV0bWFwIG9uIGEgVWJ1 bnR1IDE0LjA0IG1hY2hpbmU/DQpBY3R1YWxseSB3ZSBoYXZlIGNvbXBpbGVkIG5ldG1hcCBpbmNs dWRpbmcgdGhlIG1vZHVsZSBsaW51eF9saW4ua28gYW5kIGhhdmUgc3VjY2Vzc2Z1bGx5IGxvYWRl ZCBpdC4NCkJ1dCBldmVyeXRpbWUgd2UgdHJ5IHRvIHN0YXJ0IHRoZSBicmlkZ2UsIHdlwrRyZSBn ZXR0aW5nIHRoZSBmb2xsb3dpbmcgZXJyb3I6DQoNCi4vYnJpZGdlIGJ1aWx0IFNlcCAxMCAyMDE0 IDA5OjM3OjAwDQo4ODkuNDkxMzkwIG1haW4gWzIzM10gY2Fubm90IG9wZW4gZXRoMQ0KS2VybmVs OiBMaW51eCAzLjEzLjAtMjQtZ2VuZXJpYyB4ODZfeDY0DQoNCkRvZXMgYW55b25lIGhhdmUgYW55 IGlkZWFzDQoNCm1hbnkgdGhhbmtzLg0KDQpNaXQgZnJldW5kbGljaGVuIEdyw7zDn2VuLA0KDQpN YXJ0aW4gTGV1cG9sZHQNCkxlaXRlciBTZXJ2ZXIgU3lzdGVtZQ0KDQpUZWwgKzQ5ICgwKTkxMDMt NzE1LTMyNzINCkZheCArNDkgKDApOTEwMy03MTUtMzI5OQ0KDQpFLW1haWw6IG1hcnRpbi5sZXVw b2xkdEBob2IuZGU8bWFpbHRvOm1hcnRpbi5sZXVwb2xkdEBob2IuZGU+DQpJbnRlcm5ldDogaHR0 cDovL3d3dy5ob2IuZGUNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpG b2xsb3cgSE9COg0KDQotIEhPQjogaHR0cDovL3d3dy5ob2IuZGUvcmVkaXJlY3QvaG9iLmh0bWwN Ci0gWGluZzogaHR0cDovL3d3dy5ob2IuZGUvcmVkaXJlY3QveGluZy5odG1sDQotIExpbmtlZElu OiBodHRwOi8vd3d3LmhvYi5kZS9yZWRpcmVjdC9saW5rZWRpbi5odG1sDQotIEhPQkxpbmsgTW9i aWxlOiBodHRwOi8vd3d3LmhvYi5kZS9yZWRpcmVjdC9ob2JsaW5rbW9iaWxlLmh0bWwNCi0gRmFj ZWJvb2s6IGh0dHA6Ly93d3cuaG9iLmRlL3JlZGlyZWN0L2ZhY2Vib29rLmh0bWwNCi0gVHdpdHRl cjogaHR0cDovL3d3dy5ob2IuZGUvcmVkaXJlY3QvdHdpdHRlci5odG1sDQotIFlvdVR1YmU6IGh0 dHA6Ly93d3cuaG9iLmRlL3JlZGlyZWN0L3lvdXR1YmUuaHRtbA0KLSBFLU1haWw6IGh0dHA6Ly93 d3cuaG9iLmRlL3JlZGlyZWN0L21haWwuaHRtbA0KDQoNCkhPQiBSRCBWUE4gLSBlaW5mYWNoLCBz aWNoZXIgdW5kIGZsZXhpYmVsIGF1ZiBhbGxlIFVudGVybmVobWVuc2Fud2VuZHVuZ2VuIHVuZCAt ZGF0ZW4genVncmVpZmVuDQoNClByYWVzZW50YXRpb24gdW50ZXI6IGh0dHA6Ly93d3cuaG9iLmRl L3JkdnBuMi8NCg0KDQpIT0IgR21iSCAmIENvLiBLRw0KU2Nod2FkZXJtdWVobHN0ci4gMw0KRC05 MDU1NiBDYWRvbHpidXJnDQoNCkdlc2NoYWVmdHNmdWVocnVuZzogS2xhdXMgQnJhbmRzdGFldHRl ciwgWm9yYW4gQWRhbW92aWMNCg0KQUcgRnVlcnRoLCBIUkEgNTE4MA0KU3RldWVyLU5yLiAyMTgv MTYzLzAwMTA3DQpVU3QtSUQtTnIuIERFIDEzMjc0NzAwMg0KDQpLb21wbGVtZW50YWVyaW4gSE9C IGVsZWN0cm9uaWMgQmV0ZWlsaWd1bmdzIEdtYkgNCkFHIEZ1ZXJ0aCwgSFJCIDM0MTYNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpmcmVlYnNkLW5ldEBm cmVlYnNkLm9yZzxtYWlsdG86ZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmc+IG1haWxpbmcgbGlzdA0K aHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1uZXQNClRv IHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvICJmcmVlYnNkLW5ldC11bnN1YnNjcmliZUBm cmVlYnNkLm9yZzxtYWlsdG86ZnJlZWJzZC1uZXQtdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmc+Ig0K DQoNCg0KLS0NClN0ZWZhbm8gR2FyemFyZWxsYQ0Kc3RlZmFuby5nYXJ6YXJlbGxhQGdtYWlsLmNv bTxtYWlsdG86c3RlZmFuby5nYXJ6YXJlbGxhQGdtYWlsLmNvbT4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KRm9sbG93IEhPQjoNCg0KLSBIT0I6IGh0dHA6Ly93d3cuaG9i LmRlL3JlZGlyZWN0L2hvYi5odG1sDQotIFhpbmc6IGh0dHA6Ly93d3cuaG9iLmRlL3JlZGlyZWN0 L3hpbmcuaHRtbA0KLSBMaW5rZWRJbjogaHR0cDovL3d3dy5ob2IuZGUvcmVkaXJlY3QvbGlua2Vk aW4uaHRtbA0KLSBIT0JMaW5rIE1vYmlsZTogaHR0cDovL3d3dy5ob2IuZGUvcmVkaXJlY3QvaG9i bGlua21vYmlsZS5odG1sDQotIEZhY2Vib29rOiBodHRwOi8vd3d3LmhvYi5kZS9yZWRpcmVjdC9m YWNlYm9vay5odG1sDQotIFR3aXR0ZXI6IGh0dHA6Ly93d3cuaG9iLmRlL3JlZGlyZWN0L3R3aXR0 ZXIuaHRtbA0KLSBZb3VUdWJlOiBodHRwOi8vd3d3LmhvYi5kZS9yZWRpcmVjdC95b3V0dWJlLmh0 bWwNCi0gRS1NYWlsOiBodHRwOi8vd3d3LmhvYi5kZS9yZWRpcmVjdC9tYWlsLmh0bWwNCg0KDQpI T0IgUkQgVlBOIC0gZWluZmFjaCwgc2ljaGVyIHVuZCBmbGV4aWJlbCBhdWYgYWxsZSBVbnRlcm5l aG1lbnNhbndlbmR1bmdlbiB1bmQgLWRhdGVuIHp1Z3JlaWZlbg0KDQpQcmFlc2VudGF0aW9uIHVu dGVyOiBodHRwOi8vd3d3LmhvYi5kZS9yZHZwbjIvDQoNCg0KSE9CIEdtYkggJiBDby4gS0cNClNj aHdhZGVybXVlaGxzdHIuIDMNCkQtOTA1NTYgQ2Fkb2x6YnVyZw0KDQpHZXNjaGFlZnRzZnVlaHJ1 bmc6IEtsYXVzIEJyYW5kc3RhZXR0ZXIsIFpvcmFuIEFkYW1vdmljDQoNCkFHIEZ1ZXJ0aCwgSFJB IDUxODANClN0ZXVlci1Oci4gMjE4LzE2My8wMDEwNw0KVVN0LUlELU5yLiBERSAxMzI3NDcwMDIN Cg0KS29tcGxlbWVudGFlcmluIEhPQiBlbGVjdHJvbmljIEJldGVpbGlndW5ncyBHbWJIDQpBRyBG dWVydGgsIEhSQiAzNDE2DQo= From owner-freebsd-net@FreeBSD.ORG Mon Sep 29 08:00:14 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95B8C30A for ; Mon, 29 Sep 2014 08:00:14 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6A1B3F8E for ; Mon, 29 Sep 2014 08:00:14 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8T80ExL040777 for ; Mon, 29 Sep 2014 08:00:14 GMT (envelope-from bugzilla-noreply@freebsd.org) Message-Id: <201409290800.s8T80ExL040777@kenobi.freebsd.org> From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [FreeBSD Bugzilla] Commit Needs MFC MIME-Version: 1.0 X-Bugzilla-Type: whine X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated Date: Mon, 29 Sep 2014 08:00:14 +0000 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 29 Sep 2014 08:00:14 -0000 Hi, You have a bug in the "Needs MFC" state which has not been touched in 7 or more days. This email serves as a reminder that you may want to MFC this bug or marked it as completed. In the event you have a longer MFC timeout you may update this bug with a comment and I won't remind you again for 7 days. This reminder is only sent on Mondays. Please file a bug about concerns you may have. This search was scheduled by eadler@FreeBSD.org. (1 bugs) Bug 183659: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183659 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-net@FreeBSD.org Status: Needs MFC Resolution: Summary: [tcp] TCP stack lock contention with short-lived connections From owner-freebsd-net@FreeBSD.ORG Mon Sep 29 09:16:11 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7C1B7C7 for ; Mon, 29 Sep 2014 09:16:11 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9F24DAB7 for ; Mon, 29 Sep 2014 09:16:11 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8T9GB08098435 for ; Mon, 29 Sep 2014 09:16:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 185967] [lagg] [patch] Link Aggregation LAGG: LACP not working in 10.0 Date: Mon, 29 Sep 2014 09:16:11 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: vanheugten@gmail.com X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 29 Sep 2014 09:16:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185967 Jeroen van Heugten changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vanheugten@gmail.com --- Comment #12 from Jeroen van Heugten --- Created attachment 147795 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147795&action=edit Output of ifconfig -a -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Sep 29 09:16:46 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3DBE856 for ; Mon, 29 Sep 2014 09:16:46 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8BD3DAC6 for ; Mon, 29 Sep 2014 09:16:46 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8T9GkJb098694 for ; Mon, 29 Sep 2014 09:16:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 185967] [lagg] [patch] Link Aggregation LAGG: LACP not working in 10.0 Date: Mon, 29 Sep 2014 09:16:46 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: vanheugten@gmail.com X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 29 Sep 2014 09:16:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185967 --- Comment #13 from Jeroen van Heugten --- We are facing the same problem, running FreeBSD 10.0-p9, connected with LACP to two Juniper EX4550 switches (virtual-chassis/stacked). In our case the Junipers are already in active mode, but we still have issues with the connection. We are experiencing lots of outages (every few mins). dmesg shows (on -multiple- FreeBSD servers: ix1: Interface stopped DISTRIBUTING, possible flapping ix1: Interface stopped DISTRIBUTING, possible flapping ix1: Interface stopped DISTRIBUTING, possible flapping Juniper configuration: ae21 { description "serverX (xe-0/0/17 en xe-1/0/17)"; aggregated-ether-options { link-speed 10g; lacp { active; periodic fast; } } unit 0 { family ethernet-switching { port-mode access; vlan { members S1_SERVERS; } } } } - attached output of "ifconfig -a" - attached output of "/etc/rc.conf" -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Sep 29 09:18:44 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1DAD790E for ; Mon, 29 Sep 2014 09:18:44 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 052E2AE5 for ; Mon, 29 Sep 2014 09:18:44 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8T9Ih8L099750 for ; Mon, 29 Sep 2014 09:18:43 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 185967] [lagg] [patch] Link Aggregation LAGG: LACP not working in 10.0 Date: Mon, 29 Sep 2014 09:18:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: vanheugten@gmail.com X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 29 Sep 2014 09:18:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185967 --- Comment #14 from Jeroen van Heugten --- Created attachment 147796 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147796&action=edit LACP settings in /etc/rc.conf -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Sep 29 12:36:53 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1EACB32D for ; Mon, 29 Sep 2014 12:36:53 +0000 (UTC) Received: from nbfkord-smmo02.seg.att.com (nbfkord-smmo02.seg.att.com [209.65.160.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C61DB2B1 for ; Mon, 29 Sep 2014 12:36:52 +0000 (UTC) Received: from unknown [12.187.104.25] (EHLO nbfkord-smmo02.seg.att.com) by nbfkord-smmo02.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 46259245.2b624c833940.1188909.00-2465.3027646.nbfkord-smmo02.seg.att.com (envelope-from ); Mon, 29 Sep 2014 12:36:52 +0000 (UTC) X-MXL-Hash: 542952643f89faa4-26d75f514698fa4e57b2a6acbd80760152949321 Received: from unknown [12.187.104.25] by nbfkord-smmo02.seg.att.com(mxl_mta-7.2.2-0) with SMTP id d5259245.0.1188834.00-2347.3027579.nbfkord-smmo02.seg.att.com (envelope-from ); Mon, 29 Sep 2014 12:36:51 +0000 (UTC) X-MXL-Hash: 54295263367d3c04-73a760c4de14c9771702f297348aac398bf759c4 Received: from [192.168.38.17] (84.52.89.52) by webmail.SolarFlare.com (10.20.40.31) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 29 Sep 2014 05:35:48 -0700 Message-ID: <54295246.6010502@solarflare.com> Date: Mon, 29 Sep 2014 16:36:22 +0400 From: Andrew Rybchenko User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Subject: Choice of private ioctl approach Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: [84.52.89.52] X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-20982.005 X-TM-AS-Result: No--5.561900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-AnalysisOut: [v=2.0 cv=Y8NPRGiN c=1 sm=1 a=MkjXnYnS3dyNWGSWLXxFFQ==:17 a] X-AnalysisOut: [=Ozv50jBIw7UA:10 a=4oxowH2qkH0A:10 a=RB3BGLmKESwA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zRKbQ67AAAAA:8 a=qg_zykTt] X-AnalysisOut: [5_OaQZwxDF0A:9 a=wPNLvfGTeEIA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [12.187.104.25] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 29 Sep 2014 12:36:53 -0000 Hello, we need to add private ioctl to the driver sfxge(4) to make FW update, do internal diagnostics commands etc. We see at least two approaches in other drivers: 1. SIOCGPRIVATE_0/ SIOCGPRIVATE_1 on net device 2. dedicated char device with its own ioctl's Is there any recommendations on which way is preferred? Thanks, Andrew. The information contained in this message is confidential and is intended f= or the addressee(s) only. If you have received this message in error, pleas= e notify the sender immediately and delete the message. Unless you are an a= ddressee (or authorized to receive for an addressee), you may not use, copy= or disclose to anyone this message or any information contained in this me= ssage. The unauthorized use, disclosure, copying or alteration of this mess= age is strictly prohibited. From owner-freebsd-net@FreeBSD.ORG Mon Sep 29 17:33:01 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A8AD7B5 for ; Mon, 29 Sep 2014 17:33:01 +0000 (UTC) Received: from cp-out7.libero.it (cp-out7.libero.it [151.1.108.64]) by mx1.freebsd.org (Postfix) with ESMTP id E8D4FAE2 for ; Mon, 29 Sep 2014 17:33:00 +0000 (UTC) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0C0208.542997C5.005E,ss=1,re=0.000,fgs=0 X-libjamoibt: 1555 Received: from soth.ventu (151.41.137.184) by cp-out7.libero.it (8.5.133) id 53075AA8174E4967 for freebsd-net@freebsd.org; Mon, 29 Sep 2014 19:32:53 +0200 Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.9/8.14.7) with ESMTP id s8THWpgE036826 for ; Mon, 29 Sep 2014 19:32:51 +0200 (CEST) (envelope-from ml@netfence.it) Message-ID: <542997C3.5090004@netfence.it> Date: Mon, 29 Sep 2014 19:32:51 +0200 From: Andrea Venturoli User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: pf stuck Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 29 Sep 2014 17:33:01 -0000 Hello. Today a box of mine (8.4p16/amd64) stopped working as a router; I don't have a clear picture, but the internal nets were working perfectly, while the external interfaces lagged, dropped connections or stopped packets from passing. The box is running pf (for handling multiple Internet lines) + ipfw (for firewalling). I tried a simple telnet xxx:80 and this is what I observed: _ tcpdump would see packets going out and replies coming in; _ an early ipfw allow rule with setup keep-state would see no packet going out and would not create any dinamic rule. This lead me to look into pf... "/etc/rc.d/pf restart" did not solve. "/etc/rc.d/pf stop ; /etc/rc.d/pf start" did! These are my pf rules: > pass out quick inet from 192.168.x.0/24 to 192.168.y.0/24 no state > pass out quick inet from 192.168.x.0/24 to 192.168.z.0/24 no state > pass out log quick route-to (vlan3 192.168.x.x) inet from 192.168.x.0/24 to ! 192.168.x.0/24 no state > pass out quick inet from a.b.c.d/29 to 192.168.y.0/24 no state > pass out quick inet from a.b.c.d/29 to 192.168.z.0/24 no state > pass out log quick route-to (vlan1 a.b.c.e) inet from a.b.c.d/29 to ! a.b.c.d/29 no state > pass out quick inet from i.j.k.l/29 to 192.168.z.0/24 no state > pass out quick inet from i.j.k.l/29 to 192.168.z.0/24 no state > pass out log quick route-to (vlan2 i.j.k.m) inet from i.j.k.l/29 to ! i.j.k.l/29 no state These rules are working fine, but have hanged already twice in two weeks (once on this box, once on an almost identical one). Is there any known problem wrt running pf? pf+ipfw? pf on 8.4? Any hint on how to search for what's wrong? bye & Thanks av. P.S. Please, forgive me, but I'm quite noob with pf. From owner-freebsd-net@FreeBSD.ORG Mon Sep 29 17:36:05 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BBB5A8F0; Mon, 29 Sep 2014 17:36:05 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 370D2B18; Mon, 29 Sep 2014 17:36:05 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id cc10so526237wib.4 for ; Mon, 29 Sep 2014 10:36:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=vwHiFikahJCYTBs2GpNW9ZJp5Lqqiix0FxjricIwt/c=; b=FbmXoHdsI4TTFn6onL0MX9ifsZU/hVXBDgebvUcyWev8MEV2lYffc1zQXhdkMa7gqL D81J1VnbDcAl97Nu4t+6ctYiHG1bnWENA3QjsrdVt8HfecKfh2tkKE3xLJHnto96EgMX 0nPinamaqS+rzsFdKzYSaqFwsR6IhnHTfDhMTswhZmtYAR2cVcetbI/M9eL4JHrpDz/k 5MFjMY+WIVR01eYInPPIo4kv3uM4GIIJsLJiX/Ynz7AP90fH4cxeHv+1VSHWdJKcCiPD AOOXWh6y5Qi/+SuuPUzFnjayOmLc7d4nbh36UGy9s7bdfdUjm0oY7jmADoizLqCHVzYA FDog== MIME-Version: 1.0 X-Received: by 10.194.191.135 with SMTP id gy7mr45566204wjc.39.1412012163386; Mon, 29 Sep 2014 10:36:03 -0700 (PDT) Sender: hiren.panchasara@gmail.com Received: by 10.27.47.137 with HTTP; Mon, 29 Sep 2014 10:36:03 -0700 (PDT) Date: Mon, 29 Sep 2014 10:36:03 -0700 X-Google-Sender-Auth: zRRT3-rsfqYefGSK9TV3RdP4klU Message-ID: Subject: igb update - 2.4.0 -> 2.4.2 From: hiren panchasara To: "freebsd-net@freebsd.org" , Jack F Vogel , ricera10@gmail.com Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 29 Sep 2014 17:36:05 -0000 Jack/ Eric, When do you guys plan to bring this in the tree? https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=15815 cheers, Hiren From owner-freebsd-net@FreeBSD.ORG Mon Sep 29 18:21:24 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 938FAE7B; Mon, 29 Sep 2014 18:21:24 +0000 (UTC) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E4099BF; Mon, 29 Sep 2014 18:21:23 +0000 (UTC) Received: by mail-la0-f43.google.com with SMTP id gb8so9167094lab.30 for ; Mon, 29 Sep 2014 11:21: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:message-id:subject :from:to:cc:content-type; bh=Yjx1yn6MydME2mxs/qMVRuP6upr3R6TJYVDodSmrsOU=; b=HUPO5UCUXHzNUlme7AjM5pQ+1Hg2HJ6LQUAGD26yB3GXhKdfJAQydCqR+zlx+xM+HZ WEgXQXmGCV/fKNL15mSp+y6x2inN4VQHSORzlECac5BZ69ZuiGUBaazrq+BOJ/1SqlVj 5xFw3+fJn/2ulUQPL0FIJZMku+VuQvx7m1Qga5kS2k4d7aEA1S0FTSZXJCXaU+maCkcU xKkXIf636GPmO+x5LnT3TQ0EusWY4SEm1Y7OPN7/sKDfP6zW4J9CvW/b8PXuaRgzVp0h UmfaOygBLpkvO2tqqMh8DwlXEEs2N1u6ia1M0Bnm6Huh875b2nmOqFSlPajOzoHFQW5B jXSw== MIME-Version: 1.0 X-Received: by 10.112.55.7 with SMTP id n7mr39352621lbp.16.1412014881739; Mon, 29 Sep 2014 11:21:21 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.25.43.2 with HTTP; Mon, 29 Sep 2014 11:21:21 -0700 (PDT) In-Reply-To: <542997C3.5090004@netfence.it> References: <542997C3.5090004@netfence.it> Date: Mon, 29 Sep 2014 20:21:21 +0200 X-Google-Sender-Auth: FAnmGr4HNbaZku0os09YqLT0e8Y Message-ID: Subject: Re: pf stuck From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= To: Andrea Venturoli , "freebsd-pf@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 29 Sep 2014 18:21:24 -0000 Probably is better you ask this on freebsd-pf@. Though this sounds like state limit reached. On Mon, Sep 29, 2014 at 7:32 PM, Andrea Venturoli wrote: > Hello. > > Today a box of mine (8.4p16/amd64) stopped working as a router; I don't > have a clear picture, but the internal nets were working perfectly, while > the external interfaces lagged, dropped connections or stopped packets from > passing. > > The box is running pf (for handling multiple Internet lines) + ipfw (for > firewalling). > I tried a simple telnet xxx:80 and this is what I observed: > _ tcpdump would see packets going out and replies coming in; > _ an early ipfw allow rule with setup keep-state would see no packet going > out and would not create any dinamic rule. > > This lead me to look into pf... > "/etc/rc.d/pf restart" did not solve. > "/etc/rc.d/pf stop ; /etc/rc.d/pf start" did! > > > > These are my pf rules: > >> pass out quick inet from 192.168.x.0/24 to 192.168.y.0/24 no state >> pass out quick inet from 192.168.x.0/24 to 192.168.z.0/24 no state >> pass out log quick route-to (vlan3 192.168.x.x) inet from 192.168.x.0/24 >> to ! 192.168.x.0/24 no state >> pass out quick inet from a.b.c.d/29 to 192.168.y.0/24 no state >> pass out quick inet from a.b.c.d/29 to 192.168.z.0/24 no state >> pass out log quick route-to (vlan1 a.b.c.e) inet from a.b.c.d/29 to ! >> a.b.c.d/29 no state >> pass out quick inet from i.j.k.l/29 to 192.168.z.0/24 no state >> pass out quick inet from i.j.k.l/29 to 192.168.z.0/24 no state >> pass out log quick route-to (vlan2 i.j.k.m) inet from i.j.k.l/29 to ! >> i.j.k.l/29 no state >> > > These rules are working fine, but have hanged already twice in two weeks > (once on this box, once on an almost identical one). > > > > Is there any known problem wrt running pf? pf+ipfw? pf on 8.4? > Any hint on how to search for what's wrong? > > > > bye & Thanks > av. > > P.S. Please, forgive me, but I'm quite noob with pf. > _______________________________________________ > 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" > -- Ermal From owner-freebsd-net@FreeBSD.ORG Mon Sep 29 20:42:20 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9AC94573; Mon, 29 Sep 2014 20:42:20 +0000 (UTC) Received: from cp-out8.libero.it (cp-out8.libero.it [151.1.108.65]) by mx1.freebsd.org (Postfix) with ESMTP id 28024381; Mon, 29 Sep 2014 20:42:19 +0000 (UTC) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0C0204.5429C425.0028,ss=1,re=0.000,fgs=0 X-libjamoibt: 1555 Received: from soth.ventu (151.41.137.184) by cp-out8.libero.it (8.5.133) id 53075C36173CB621; Mon, 29 Sep 2014 22:42:13 +0200 Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.9/8.14.7) with ESMTP id s8TKgCZg041181; Mon, 29 Sep 2014 22:42:12 +0200 (CEST) (envelope-from ml@netfence.it) Message-ID: <5429C424.9060400@netfence.it> Date: Mon, 29 Sep 2014 22:42:12 +0200 From: Andrea Venturoli User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: =?UTF-8?B?RXJtYWwgTHXDp2k=?= , "freebsd-pf@freebsd.org" Subject: Re: pf stuck References: <542997C3.5090004@netfence.it> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 29 Sep 2014 20:42:20 -0000 On 09/29/14 20:21, Ermal Luçi wrote: > Probably is better you ask this on freebsd-pf@. Thanks, I see you have already cc:ed it. > Though this sounds like state limit reached. Can this happen even if all my pf rules have "no state"? bye & Thanks av. From owner-freebsd-net@FreeBSD.ORG Mon Sep 29 22:42:01 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB9B7E47 for ; Mon, 29 Sep 2014 22:42:01 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6486E23F for ; Mon, 29 Sep 2014 22:42:01 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id cc10so402550wib.2 for ; Mon, 29 Sep 2014 15:41:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=vZ4yO+/Dd4EckceUioTJuvp3lCwq7pjqIMQTPv6hO4g=; b=FB+jLtLgJ6YHePoTWfECePwELETiN0VnspgorvUdBQ8u+oDOYZqzYdo48z0Qqrkbsu TgGfsJ/eWHDJ/XOLhSgfTyo7wAQptml1u0f6tH7mblSfOywLwOYxrBLWVB0RKKiOoFuM GiEixMrvJ9ZH80E2zXFHUjeFApAQcyMGdlUGXpxfg3WwqM5uLfOv4QWkAKkNI00dnFZt hJ78xOuAyCiBNtcdvKQV9PABeN1+ayrSBx2GLmGJjU8LzO0dVR08d0uiAk7bPv0N5R2X +R0PPgxLPBHvgTF/Ss+3Il8+jqWvm7ufDO34wS7XBTAChHp9DtYcTwJUqWtAFN9MAQFE LRnw== MIME-Version: 1.0 X-Received: by 10.180.107.100 with SMTP id hb4mr897847wib.59.1412030519728; Mon, 29 Sep 2014 15:41:59 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Mon, 29 Sep 2014 15:41:59 -0700 (PDT) In-Reply-To: References: <1411826158.72985.YahooMailNeo@web172803.mail.ir2.yahoo.com> Date: Mon, 29 Sep 2014 15:41:59 -0700 X-Google-Sender-Auth: NX2d0CtFwqRQTG95-o41YT6LuWw Message-ID: Subject: Re: vlan id 0 From: Adrian Chadd To: "Danny J. Mitzel" Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" , Tony Moseby X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 29 Sep 2014 22:42:01 -0000 Ok.. Can someone please submit a PR with a patch that addresses this? I'll try to make sure it gets into freebsd-head. -a On 27 September 2014 18:24, Danny J. Mitzel wrote: > On Sat, Sep 27, 2014 at 4:44 PM, Adrian Chadd wrote: > > .. the spec allows vlan id=0? > > 0 is not a valid VLAN ID but the specs do allow it > in a tagged packet, it's called "Priority tagged". > The priority bits should be interpreted when making > any queuing / scheduling decisions during forwarding. > The VLAN ID bits are ignored and packet is to be > treated as untagged during forwarding / flooding > decisions. From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 02:07:03 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C04196A0; Tue, 30 Sep 2014 02:07:03 +0000 (UTC) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8FDFA6D9; Tue, 30 Sep 2014 02:07:03 +0000 (UTC) Received: by mail-pd0-f179.google.com with SMTP id r10so3751321pdi.10 for ; Mon, 29 Sep 2014 19:07:03 -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:in-reply-to:user-agent; bh=ExfCYkjEBKrn///UOJrEw4oX2yow0vwqVWN7oSD6kh0=; b=A4WVD3Vr5nWq2xiLby0VhFTdf0FrBaLT48WaBOqRw/t54V5leZ/GZTSMVOoC66VBEa MGl4ym18gRrZn4O5hpfelElG+qkbXEgLa+Ed4+zTZF6CFJagXbMRfDgR61K0RYGhSwdF n88onMidEohaZ6Ua86NJdxspYwRLlN3Q6OAqdqqzXYLkiLC8jFE6oITyx0Gz9nsta87d BrWYqLcjHpJ4E1iIMFMQ0DaEMFJKdgB0PrioSioFPiuNrbThb5q3Vp/42cSGVqQ5rqq5 X+8XUGTpdzOXpojok9tAzEJsvh73xbTyEosksM1jEfyLGkNdldpLIoleOvngdqukGSz9 skeQ== X-Received: by 10.70.100.34 with SMTP id ev2mr60550988pdb.53.1412042823131; Mon, 29 Sep 2014 19:07:03 -0700 (PDT) Received: from pyunyh@gmail.com ([106.247.248.2]) by mx.google.com with ESMTPSA id c3sm13618851pdk.3.2014.09.29.19.06.59 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 29 Sep 2014 19:07:01 -0700 (PDT) From: Yonghyeon PYUN X-Google-Original-From: "Yonghyeon PYUN" Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 30 Sep 2014 11:06:55 +0900 Date: Tue, 30 Sep 2014 11:06:55 +0900 To: Nils Beyer Subject: Re: Success with Qualcomm Atheros QCA8171 Message-ID: <20140930020655.GD2451@michelle.fasterthan.com> Reply-To: pyunyh@gmail.com References: <3320661411119387@web21h.yandex.ru> <20140925094737.CE280B5B@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140925094737.CE280B5B@hub.freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, freebsd-drivers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Sep 2014 02:07:03 -0000 On Thu, Sep 25, 2014 at 11:44:24AM +0200, Nils Beyer wrote: > Hi Gulyaev, > > Gulyaev Ghosh wrote: > > Since I ask on the FreeBSD forums, there is a proposition to check > > alx-freebsd and have initialized interface. > > > > So if someone have similar hardware, you can got your experience with > > that project and share info. > > I've got an onboard "AR8161 Gigabit Ethernet" adapter. With your proposed GIT- > repository and using its branch "master" I'm able to rudimentarily use the > NIC. But only if the network cable is short (< 2m). Using longer cables gives > me a "no carrier" status. When it is connected, speed is abysmal and functio- > nality ceases as soon as I perform an "iperf" benchmark until I reboot. > FYI: I've completed adding AR816x/AR817x support . You can find diff at the following URLs. http://people.freebsd.org/~yongari/alc/pci.quirk.diff http://people.freebsd.org/~yongari/alc/alc.diff.20140930 From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 05:30:26 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F1DB83D for ; Tue, 30 Sep 2014 05:30:26 +0000 (UTC) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EE476C40 for ; Tue, 30 Sep 2014 05:30:25 +0000 (UTC) Received: by mail-vc0-f174.google.com with SMTP id hy4so2533555vcb.33 for ; Mon, 29 Sep 2014 22:30:24 -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=JShsEUjAVaMPK715V7nqtpvBPRoVuxkIy/V3y+gmwK8=; b=NcoYfEUmMYiSsIQTGjGCMbTIzEnLdzSNOogsYmFaIydsKi6MCGX7h+2GvnE2FIlk3y 1obyTGOfd326QNky0r/ue4VuUIuu64dbDv9P5pZK5ePUdz5ltgNLfW0Wc9EE5Wc0Es/A M9m5TEk2VWIs0yV0NFv2iQFL3PpmCRguV3zWR8tzlyw2MuOKmJGh8pUqznNclE0qhit6 liVMjK4l/PuDMk8/V7MFIh6mcUQ+8qTEfP9bV/WC6LgGACjojUpcBk4PKZ4M368Yev9c rO3n3yZQIpxGFgg0h8um4CLWfObD6Exe0hjRfPk6Lj+4JkaCDyaU9SZdG9od0ldfekMZ Cz7w== X-Received: by 10.220.88.76 with SMTP id z12mr33855406vcl.14.1412055024847; Mon, 29 Sep 2014 22:30:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.167.193 with HTTP; Mon, 29 Sep 2014 22:29:54 -0700 (PDT) In-Reply-To: References: From: Long Tran Date: Tue, 30 Sep 2014 00:29:54 -0500 Message-ID: Subject: Re: Compiling netmap in Ubuntu 1.04 in VMWare To: Mahnaz Talebi Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "Gurkan, Deniz" , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Sep 2014 05:30:26 -0000 Hi Mahnaz, Thank you. I just got it worked without drivers. Could you please explain how netmap can be used without drivers? I thought it required the NIC's driver to run. Thanks, Long. *Long Tran* Research Assistant MS in Network Communications and Technology Project Management University of Houston On Mon, Sep 29, 2014 at 2:04 AM, Mahnaz Talebi wrote: > I guess that all of your NICs use e1000 driver. You can check out this by > 'lsmod | grep e1000'. I have been faced this problem that arising from > incompatibility between netmap and your kernel. I guess that netmap doesn't > support your kernel. > > About patches: for example, diff--e1000e--20620--20623 support kernel > 2.6.20 to 2.6.23. > I use ubunto 12.4 and upgrade its kernel to 3.8.7 and can install and use > netmap successfully. > You can install netmap without drivers by 'make NODRIVERS=1'. > > On Mon, Sep 29, 2014 at 10:13 AM, Long Tran > wrote: > >> Hi Mahnaz, >> >> This is my kernel: 3.13.0-29-generic >> I don't know if this path contains the drivers that supported by my >> kernel: >> /lib/modules/3.13.0-29-generic/kernel/drivers/net/ethernet/intel/ >> >> These are what in side that path: >> e1000 e1000e e100.c e100.ko i40e i40evf igb igbvf ixgb ixgbe >> ixgbevf Kconfig Makefile >> >> In the patches directory, I found these: >> e1000 e1000e igb ixgbe >> >> So I guess my kernel has the drivers supported by netmap. >> >> Also, I forgot to include the error when I run the make command. Here it >> is: >> make -C /lib/modules/3.13.0-29-generic/build >> M=/home/kl/Workspaces/netmap/LINUX CONFIG_NETMAP=m CONFIG_E1000=m >> CONFIG_E1000E=m CONFIG_IXGBE=m CONFIG_IGB=m CONFIG_BNX2X=m CONFIG_MLX4=m >> CONFIG_VIRTIO_NET=m \ >> EXTRA_CFLAGS='-I/home/kl/Workspaces/netmap/LINUX >> -I/home/kl/Workspaces/netmap/LINUX/../sys >> -I/home/kl/Workspaces/netmap/LINUX/../sys/dev -DCONFIG_NETMAP >> -Wno-unused-but-set-variable' \ >> O_DRIVERS="e1000/ e1000e/ igb/ ixgbe/" modules >> make[1]: Entering directory `/usr/src/linux-headers-3.13.0-29-generic' >> >> >> >> >> >> *make[3]: *** No rule to make target >> `/home/kl/Workspaces/netmap/LINUX/e1000/e1000_main.o', needed by >> `/home/kl/Workspaces/netmap/LINUX/e1000/e1000.o'. Stop.make[2]: *** >> [/home/kl/Workspaces/netmap/LINUX/e1000] Error 2make[1]: *** >> [_module_/home/kl/Workspaces/netmap/LINUX] Error 2make[1]: Leaving >> directory `/usr/src/linux-headers-3.13.0-29-generic'make: *** [build] Error >> 2* >> >> The thing is my laptop has intel card, but I don't know if my VM (I am >> using VMWare) has that card. Right now, I create four NICs for my VM: host >> only, bridge to my host's ethernet, bridge to my wireless card, and two >> other private NICs that connect privately within different VMs. >> >> Do you think that is the problem VM, not netmap itself? >> Thank you, >> >> *Long Tran* >> Research Assistant >> MS in Network Communications and Technology Project Management >> University of Houston >> >> On Mon, Sep 29, 2014 at 12:07 AM, Mahnaz Talebi >> wrote: >> >>> What is your kernel? Are you check list of supported drivers to see if >>> your kernel's drivers are supported whit the your version of netmap? >>> Supported drivers are in folder patch and their name show their supported >>> kernels. >>> >>> On Sun, Sep 28, 2014 at 10:02 PM, Long Tran >>> wrote: >>> >>>> Hi Mahnaz, >>>> >>>> I installed the headers and sources using these commands: >>>> sudo apt-get install linux-headers-3.13.0-29 >>>> sudo apt-get install linux-source-3.13.0 >>>> >>>> Thanks, >>>> -- >>>> *Long Tran* >>>> Research Assistant >>>> MS in Network Communications and Technology Project Management >>>> University of Houston >>>> >>> >>> >> > From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 07:27:38 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E90042EC for ; Tue, 30 Sep 2014 07:27:38 +0000 (UTC) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx11.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C6121AA9 for ; Tue, 30 Sep 2014 07:27:38 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.04,625,1406617200"; d="asc'?scan'208";a="157878393" Received: from hioexcmbx03-prd.hq.netapp.com ([10.122.105.36]) by mx11-out.netapp.com with ESMTP; 30 Sep 2014 00:27:29 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 30 Sep 2014 00:27:07 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::79b6:a9a2:f48b:f065%21]) with mapi id 15.00.0913.011; Tue, 30 Sep 2014 00:27:07 -0700 From: "Eggert, Lars" To: "Leupoldt, Martin" Subject: Re: netmap on ubuntu 14.04? Thread-Topic: netmap on ubuntu 14.04? Thread-Index: Ac/Zi8NjHSQcge1oS3immNdS/agA8wDLuHGA Date: Tue, 30 Sep 2014 07:27:07 +0000 Message-ID: <5F642017-96B2-4086-89BF-8917D9BEC932@netapp.com> References: <321E74F3FD7B9B478555010DC1AFD5D5C7357FD8@HOBEX21.hob.de> In-Reply-To: <321E74F3FD7B9B478555010DC1AFD5D5C7357FD8@HOBEX21.hob.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_0EFA0B8F-BB1E-436E-B6FB-2C9BB49955F4"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Sep 2014 07:27:39 -0000 --Apple-Mail=_0EFA0B8F-BB1E-436E-B6FB-2C9BB49955F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 2014-9-26, at 15:19, Leupoldt, Martin wrote: > has anyone experience about netmap on a Ubuntu 14.04 machine? I've compiled it with 3.13 under Debian; 3.16 fails to compile because = the patch doesn't apply cleanly. Lars --Apple-Mail=_0EFA0B8F-BB1E-436E-B6FB-2C9BB49955F4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBVCpbWdZcnpRveo1xAQLKPgP8C7rjFUqLrsXP6UfikwhEU/h6HAjr3Z52 b307VpDPDxksxYZEHJ+eM+BONwn4NL2BY9tLx2D3IYpl9zk/8n3zAY6RmC1cC2KM OLMRrQtVvxETUBQbnD/bMMK45ka7Cxzl3BBhOOiVrRP8KS2vx6meDsohThapS9V+ Ls0j6z09RaU= =Ox6F -----END PGP SIGNATURE----- --Apple-Mail=_0EFA0B8F-BB1E-436E-B6FB-2C9BB49955F4-- From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 08:20:49 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 566BEF2F for ; Tue, 30 Sep 2014 08:20:49 +0000 (UTC) Received: from nijmegen.renzel.net (mx1.renzel.net [195.243.213.130]) by mx1.freebsd.org (Postfix) with ESMTP id 139FFC8 for ; Tue, 30 Sep 2014 08:20:47 +0000 (UTC) Received: from dublin.vkf.isb.de.renzel.net (unknown [10.0.0.80]) by nijmegen.renzel.net (smtpd) with ESMTP id B4E8414148F6 for ; Tue, 30 Sep 2014 10:20:19 +0200 (CEST) Received: from asbach.renzel.net (unknown [10.2.0.7]) by dublin.vkf.isb.de.renzel.net (Postfix) with ESMTP id E5C9198A01 for ; Tue, 30 Sep 2014 10:20:31 +0200 (CEST) Content-Type: text/plain; charset="ISO-8859-1" From: Nils Beyer Organization: VKF Renzel GmbH Date: Tue, 30 Sep 2014 10:20:31 +0200 User-Agent: KNode/4.12.5 Content-Transfer-Encoding: 7Bit Subject: Re: [CFT] alc(4) QAC AR816x/AR817x ethernet controller support To: freebsd-net@freebsd.org References: <20140930015741.GA2451@michelle.fasterthan.com> Lines: 44 MIME-Version: 1.0 X-Virus-Scanned: clamav-milter 0.98 at nijmegen.renzel.net X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=7.0 tests=BAYES_00,MISSING_MID, UNPARSEABLE_RELAY autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on nijmegen.renzel.net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Sep 2014 08:20:49 -0000 Hi Yonghyeon, Yonghyeon PYUN wrote: > I've added support for QAC AR816x/AR817x ethernet controllers. It > passed my limited testing and I need more testers. You can find > patches from the following URLs. [...] My NIC (System: "Dell Inc. Vostro 3460"): ------------------------------------------------------------------------------- none2@pci0:2:0:0: class=0x020000 card=0x05621028 chip=0x10911969 rev=0x10 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR8161 Gigabit Ethernet' class = network subclass = ethernet ------------------------------------------------------------------------------- I've successfully applied both of your patches to 10.1-BETA3 (r272295) sources and rebuilt the kernel. Then I've connected a network cable and rebooted. I've got a link and performed an "iperf" test. The results are really good: around 930 Mbit/s TX and 840 Mbit/s RX. CPU load during that test: "70.75% kernel{alc0 taskq}". Then I've dis- and reconnected the network cable. Unfortunately, I cannot get a link anymore; it stays at: "status: no carrier" - tried "ifconfig down/up", re- connecting the network cable several times, but it stays down. After another reboot the link can be established again. That doesn't always happen. Sometimes I easily get a link again, sometimes not and I need to reboot. If you need any further information or debugging, please let me know. For now, I'm using "if_alc" as an unloadable module - in case the NIC stalls for some reason; and am quite happy about being able to use that NIC now. Thanks for having added support for these NICs. Because I'm not using CURRENT, I've replied to the "net" mailing list. I hope, it is okay for you... Regards, Nils From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 08:52:37 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A0726CF for ; Tue, 30 Sep 2014 08:52:37 +0000 (UTC) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1EBD85E2 for ; Tue, 30 Sep 2014 08:52:37 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id g10so1472088pdj.4 for ; Tue, 30 Sep 2014 01:52:36 -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:in-reply-to:user-agent; bh=saiXql5W3xRaOczmn9rWDpTf3/f9fNvilTvaXpjW9co=; b=ygiBwZbWn4wklmBoGrgPqpUMd27IZsjgRqVOxoTgwnHhc54OoMTM1tzNoIMNydKP39 HaF2P6wctA95gJ0kIhkUGI30gh+0Z/tL/Ex2z8UtE1hfOt28LGvk1qqDkX1V+4o3BGsD Bj9464yNNsNQoRcDmyAT4hTRPsn0QaNBUIAoxYunq+ui3KHhWS9PTfKhen9r9IltbHfG r3fnlD/H8yloaoIMSPeIKLmdJvfMD9Pg3+YN7vdhXC3aNLsE9+uJDDwfJ7Y19dv5iu4a hkaYT5wRTAtmb8cLSuUv4gQJrAehnZXCnqQYhkxcAeCZSHO1teOopbSs4PtoaOCE+wfY syvQ== X-Received: by 10.68.201.230 with SMTP id kd6mr69118014pbc.74.1412067156603; Tue, 30 Sep 2014 01:52:36 -0700 (PDT) Received: from pyunyh@gmail.com ([106.247.248.2]) by mx.google.com with ESMTPSA id hr1sm14515190pbb.17.2014.09.30.01.52.32 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 30 Sep 2014 01:52:35 -0700 (PDT) From: Yonghyeon PYUN X-Google-Original-From: "Yonghyeon PYUN" Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 30 Sep 2014 17:52:28 +0900 Date: Tue, 30 Sep 2014 17:52:28 +0900 To: Nils Beyer Subject: Re: [CFT] alc(4) QAC AR816x/AR817x ethernet controller support Message-ID: <20140930085228.GB969@michelle.fasterthan.com> Reply-To: pyunyh@gmail.com References: <20140930015741.GA2451@michelle.fasterthan.com> <20140930082053.4D9EFF8F@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140930082053.4D9EFF8F@hub.freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Sep 2014 08:52:37 -0000 On Tue, Sep 30, 2014 at 10:20:31AM +0200, Nils Beyer wrote: > Hi Yonghyeon, > > Yonghyeon PYUN wrote: > > I've added support for QAC AR816x/AR817x ethernet controllers. It > > passed my limited testing and I need more testers. You can find > > patches from the following URLs. [...] > > My NIC (System: "Dell Inc. Vostro 3460"): > ------------------------------------------------------------------------------- > none2@pci0:2:0:0: class=0x020000 card=0x05621028 chip=0x10911969 rev=0x10 hdr=0x00 > vendor = 'Atheros Communications Inc.' > device = 'AR8161 Gigabit Ethernet' > class = network > subclass = ethernet > ------------------------------------------------------------------------------- > > I've successfully applied both of your patches to 10.1-BETA3 (r272295) sources > and rebuilt the kernel. > Thanks for testing and detailed report. > Then I've connected a network cable and rebooted. I've got a link and performed > an "iperf" test. The results are really good: around 930 Mbit/s TX and 840 > Mbit/s RX. CPU load during that test: "70.75% kernel{alc0 taskq}". > Hmm, the RX performance number looks bad to me. You have to see more than 920Mbps. Could you show me the output of "pciconf -lcbv"? > Then I've dis- and reconnected the network cable. Unfortunately, I cannot get a > link anymore; it stays at: "status: no carrier" - tried "ifconfig down/up", re- > connecting the network cable several times, but it stays down. After another > reboot the link can be established again. > > That doesn't always happen. Sometimes I easily get a link again, sometimes not > and I need to reboot. > I thought I verified link lost condition before requesting test. After reading your mail, I was successfully reproduce it with engineering sample board. It seems when link lost time lasts long enough alc(4) fails to re-establish a link. I don't have idea how to address that at this moment but I'll let you know if I manage to find a clue. > If you need any further information or debugging, please let me know. For now, > I'm using "if_alc" as an unloadable module - in case the NIC stalls for some > reason; and am quite happy about being able to use that NIC now. > > Thanks for having added support for these NICs. > > > Because I'm not using CURRENT, I've replied to the "net" mailing list. I hope, > it is okay for you... > That's ok. From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 09:25:28 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB501EFF for ; Tue, 30 Sep 2014 09:25:28 +0000 (UTC) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AC46C996 for ; Tue, 30 Sep 2014 09:25:28 +0000 (UTC) Received: by mail-qg0-f48.google.com with SMTP id i50so3145761qgf.21 for ; Tue, 30 Sep 2014 02:25: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:date:message-id:subject:from:to :cc:content-type; bh=jqr8HmmaRGoLnu6H5dF/6gZYqUntb4A1JIGym3VI1LY=; b=JJCARL1Lzm/herNmxB3aAmfoV7Ky62vd4ugSGAzjeLKG3IPwP0GgeSl6aVlBDVStd4 qDUlrUutjQQn1LxqvGPpSxveuN6SToxQ0UNimSLzgvS2H1IMhEkln9dZbMdSRHNbU6ot vfzcMu0GFgG51FGuQlQa01fqY+yRxbqoOux8STuIYNi+MtFUwEpYkcy0k0uVTtSe7M8j dQ/8o3Vgvpz1lr+zsCzhNtgDnR/T5kCTbHwPRXyKNqgYmQKaywlqbPUG7zNQGmaw54Ij Usuub6pc/WPiodCtw1AaeYlTMVdUcYyW14eg9U1tANlaSyxctYXeOXn9NbDHjjnhXSRb 2vhw== MIME-Version: 1.0 X-Received: by 10.224.92.83 with SMTP id q19mr41034889qam.29.1412069127855; Tue, 30 Sep 2014 02:25:27 -0700 (PDT) Received: by 10.140.86.139 with HTTP; Tue, 30 Sep 2014 02:25:27 -0700 (PDT) In-Reply-To: <5F642017-96B2-4086-89BF-8917D9BEC932@netapp.com> References: <321E74F3FD7B9B478555010DC1AFD5D5C7357FD8@HOBEX21.hob.de> <5F642017-96B2-4086-89BF-8917D9BEC932@netapp.com> Date: Tue, 30 Sep 2014 11:25:27 +0200 Message-ID: Subject: Re: netmap on ubuntu 14.04? From: Stefano Garzarella To: "Eggert, Lars" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , "Leupoldt, Martin" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Sep 2014 09:25:29 -0000 Hi Lars, for linux 3.16, can you try with "next" branch in https://code.google.com/p/netmap/? Thanks, Stefano 2014-09-30 9:27 GMT+02:00 Eggert, Lars : > On 2014-9-26, at 15:19, Leupoldt, Martin wrote: > > has anyone experience about netmap on a Ubuntu 14.04 machine? > > I've compiled it with 3.13 under Debian; 3.16 fails to compile because the > patch doesn't apply cleanly. > > Lars > -- *Stefano Garzarella* stefano.garzarella@gmail.com From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 09:35:13 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A73E93E6 for ; Tue, 30 Sep 2014 09:35:13 +0000 (UTC) Received: from nijmegen.renzel.net (mx1.renzel.net [195.243.213.130]) by mx1.freebsd.org (Postfix) with ESMTP id 6A02BBED for ; Tue, 30 Sep 2014 09:35:13 +0000 (UTC) Received: from dublin.vkf.isb.de.renzel.net (unknown [10.0.0.80]) by nijmegen.renzel.net (smtpd) with ESMTP id 5312E14148A0 for ; Tue, 30 Sep 2014 11:34:51 +0200 (CEST) Received: from asbach.renzel.net (unknown [10.2.0.7]) by dublin.vkf.isb.de.renzel.net (Postfix) with ESMTP id 82A9A98724 for ; Tue, 30 Sep 2014 11:35:03 +0200 (CEST) Content-Type: text/plain; charset="ISO-8859-1" From: Nils Beyer Organization: VKF Renzel GmbH Date: Tue, 30 Sep 2014 11:35:03 +0200 User-Agent: KNode/4.12.5 Content-Transfer-Encoding: 7Bit Subject: Re: [CFT] alc(4) QAC AR816x/AR817x ethernet controller support To: freebsd-net@freebsd.org References: <20140930015741.GA2451@michelle.fasterthan.com> <20140930082053.4D9EFF8F@hub.freebsd.org> <20140930085228.GB969@michelle.fasterthan.com> Lines: 59 MIME-Version: 1.0 X-Virus-Scanned: clamav-milter 0.98 at nijmegen.renzel.net X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=7.0 tests=BAYES_00,MISSING_MID, UNPARSEABLE_RELAY autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on nijmegen.renzel.net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Sep 2014 09:35:13 -0000 Hi, Yonghyeon PYUN wrote: >> Then I've connected a network cable and rebooted. I've got a link and >> performed an "iperf" test. The results are really good: around 930 Mbit/s >> TX and 840 Mbit/s RX. CPU load during that test: "70.75% kernel{alc0 >> taskq}". > > Hmm, the RX performance number looks bad to me. You have to see > more than 920Mbps. You're right; my fault - sorry for that. The "iperf partner" seems to have a bad/weak NIC because it also only gets 840 Mbit/s sending to another computer. So I've exchanged the "iperf partner" with another computer and am getting now 935 Mbit/s in both directions. I should always measure measuring equipment before measuring. > Could you show me the output of "pciconf -lcbv"? Probably not neccessary anymore, but here you are (with additional -e option): ------------------------------------------------------------------------------- #pciconf -lcbve | tail -20 alc0@pci0:2:0:0: class=0x020000 card=0x05621028 chip=0x10911969 rev=0x10 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR8161 Gigabit Ethernet' class = network subclass = ethernet bar [10] = type Memory, range 64, base 0xd0400000, size 262144, enabled bar [18] = type I/O Port, range 32, base 0x2000, size 128, enabled cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 10[58] = PCI-Express 1 endpoint max data 128(4096) link x1(x1) speed 2.5(2.5) ASPM L1(L0s/L1) cap 05[c0] = MSI supports 16 messages, 64 bit, vector masks cap 11[d8] = MSI-X supports 16 messages, enabled Table in map 0x10[0x2000], PBA in map 0x10[0x3000] ecap 0001[100] = AER 1 0 fatal 1 non-fatal 1 corrected ecap 0003[180] = Serial 1 ff55c9fb5cf9ddff PCI-e errors = Correctable Error Detected Non-Fatal Error Detected Unsupported Request Detected Non-fatal = Unsupported Request Corrected = Bad DLLP ------------------------------------------------------------------------------- > I thought I verified link lost condition before requesting test. > After reading your mail, I was successfully reproduce it with > engineering sample board. It seems when link lost time lasts long > enough alc(4) fails to re-establish a link. Confirmed - if the network cable is disconnected long enough I cannot get a link either. As a workaround I un- and reload the "if_alc" module; then everything is working again as before... Regards, Nils From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 10:21:07 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA52CE65; Tue, 30 Sep 2014 10:21:07 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1BBDAEA; Tue, 30 Sep 2014 10:21:06 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id n3so4019267wiv.8 for ; Tue, 30 Sep 2014 03:21:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hFARJahobUKFOgLnhR4/76ypxolUjHInGg9lPhO3vLk=; b=jl/ZG3vMgehxYZNb/1guYGxaWIakxoYgLNhgQk0n3P8Ohk2ViBmBqa/Cc3zZhOx3O2 mrkpICwemUDUMvtJ7+xFQb3krUfj5j0cJjssYYBWkmPOUPf/reyB62vogRL0/df58R/W 0a+vgdodBfW5YnfFyHgHWkciyPj7uZnpoH+ukLBAp0OYqYxor5vur2TjddnBZtrBQDeO mNN2LnI8SkwIQHV1jvWaholeXp7r4F/s1ZTtrXXZDLltFWw949y4657Xo7HToKp+DcD1 EamN94tPvkzuy3M/NrOYHi46FhmpYyJt/4D1xIOI/f1XwXGjByIBWg6O9j/QkWndCv6M RrmQ== X-Received: by 10.194.184.111 with SMTP id et15mr32369453wjc.14.1412072465393; Tue, 30 Sep 2014 03:21:05 -0700 (PDT) Received: from [192.168.2.30] ([2.176.158.152]) by mx.google.com with ESMTPSA id a2sm9180871wic.19.2014.09.30.03.21.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Sep 2014 03:21:04 -0700 (PDT) Message-ID: <542A8411.1060608@gmail.com> Date: Tue, 30 Sep 2014 13:51:05 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Andrea Venturoli Subject: Re: pf stuck References: <542997C3.5090004@netfence.it> <5429C424.9060400@netfence.it> In-Reply-To: <5429C424.9060400@netfence.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net , "freebsd-pf@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Sep 2014 10:21:07 -0000 On 9/30/2014 12:12 AM, Andrea Venturoli wrote: > On 09/29/14 20:21, Ermal Luçi wrote: >> Probably is better you ask this on freebsd-pf@. > > Thanks, I see you have already cc:ed it. > > > >> Though this sounds like state limit reached. > > Can this happen even if all my pf rules have "no state"? No. Anyway, you can check state statistics with: pfctl -s i ; pfctl -s m -- Best regards. Hooman Fazaeli From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 14:58:54 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10FD6985 for ; Tue, 30 Sep 2014 14:58:54 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B1E48879 for ; Tue, 30 Sep 2014 14:58:52 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s8UEwP9c023017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 30 Sep 2014 16:58:25 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id s8UEwJ1d052398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Sep 2014 16:58:20 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id s8UEwJua065862; Tue, 30 Sep 2014 16:58:19 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s8UEwJK3065861; Tue, 30 Sep 2014 16:58:19 +0200 (CEST) (envelope-from ticso) Date: Tue, 30 Sep 2014 16:58:19 +0200 From: Bernd Walter To: freebsd-net@freebsd.org Subject: wrong source address with neighbor solicitation from jail Message-ID: <20140930145819.GB62759@cicely7.cicely.de> Reply-To: ticso@cicely.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: ticso@cicely.de X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Sep 2014 14:58:54 -0000 At first I'd thought it is the plain old broken multicast ethernet support story, since I noticed it with an IPv6 only ARM system. But multicast on all the system works fine, it is the neighbor solitictaion request at fault selecting the wrong My setup. One client system, which failed to communication with a jail with an IP configured as /128 on lo0. The jail host itself with a LAN IP on em0 and the jail IP. My gateway, used as defeault GW on the client and server and knows a route for the /128 to the jail host. It is in the route path from the client to the jail IP. (unrelated question: isn't there some kind of redirect supprt as with IPv4?) All systems are on the same LAN. When I e.g. telnet from the jail host to the client I see the following: 16:41:23.970458 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2a02:21e0:16e0:2000::105 > ff02::1:ff00:1001: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a02:21e0:16e0:2000::1001 source link-address option (1), length 8 (1): 00:1e:8c:f2:41:2d 0x0000: 001e 8cf2 412d 16:41:23.970792 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2a02:21e0:16e0:2000::1001 > 2a02:21e0:16e0:2000::105: [icmp6 sum ok ] ICMP6, neighbor advertisement, length 32, tgt is 2a02:21e0:16e0:2000::1001, Flags [solicited, override] destination link-address option (2), length 8 (1): 00:1f:7b:b4:0c:41 0x0000: 001f 7bb4 0c41 16:41:23.970800 IP6 (flowlabel 0xe9bb0, hlim 64, next-header TCP (6) payload length: 40) 2a02:21e0:16e0:2000::105.50941 > 2a02:21e0:16e0:2000: :1001.23: Flags [S], cksum 0xcaee (correct), seq 690679932, win 65535, options [mss 1440,nop,wscale 6,sackOK,TS val 291271812 ecr 0], length 0 16:41:23.971066 IP6 (hlim 64, next-header TCP (6) payload length: 20) 2a02:21e0:16e0:2000::1001.23 > 2a02:21e0:16e0:2000::105.50941: Flags [R. ], cksum 0xb889 (correct), seq 0, ack 690679933, win 0, length 0 The jail host issues a neighbor solicitaion request from his LAN IP to the multicast IP for the required target IP. It gets an answer and tries to connect. Everything is perfectly OK. Now if I do the same from the jail (after deleting the ndp entry): 16:43:30.686371 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2a02:21e0:16e0:20fe::101:6 > ff02::1:ff00:1001: [icmp6 sum ok] ICMP 6, neighbor solicitation, length 32, who has 2a02:21e0:16e0:2000::1001 source link-address option (1), length 8 (1): 00:1e:8c:f2:41:2d 0x0000: 001e 8cf2 412d And this is where my problems starts. It is issuing basicly the same NS packet, but this time with it's jail address. Now the other system won't answer to the request. Maybe because it is not on the same LAN as the requesting address. The jail host, which selects the wrong source address is running 9.1-STABLE r246590. So maybe this is fixed already? But since I've never heared about such a problem I guess it still exists. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 15:31:08 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7810BEF for ; Tue, 30 Sep 2014 15:31:08 +0000 (UTC) Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) by mx1.freebsd.org (Postfix) with SMTP id 3A511CDD for ; Tue, 30 Sep 2014 15:31:06 +0000 (UTC) Received: from mail-ie0-f170.google.com ([209.85.223.170]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKVCrMtIuuDIDznk4WrHUDb+J5DZk6MXJ9@postini.com; Tue, 30 Sep 2014 08:31:07 PDT Received: by mail-ie0-f170.google.com with SMTP id rd18so2357949iec.29 for ; Tue, 30 Sep 2014 08:30:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=9YLcPLJjvliPXnCxthFe5Z5x0v53pptIXJBq7UBSBkI=; b=QivWmtgntfW/3xdTyJWi01VbOMLRp18eViRywn2t2X6ddrSSnRxBJunmUcDELYtveA IQa2Kh82qT4kdosoA9UMkCJZXIeGgRjUm3kp9SzFO3+AFLM74cppYj1CfWZfwQSlgadI QSBXKcqZCdwM4tXZaoYa4z+RDd94ODXHjQx4sKzrt8swd20iuXWNfKj7NGUMCzl3kzAN lWhLCCyPMXCJCjFzyjWKw4ooQHA8Z1vis2GhXjSekPjXoJZekaw0BPibsg8JUJeo66Yv P/JXa9KRzfUCtXYaJyi2Wd6Jvu77vDyUf4k0Q3Lbx3nlChUOivUt2wrenTpbn5qg/9/T 5Usg== X-Received: by 10.50.170.196 with SMTP id ao4mr9137903igc.46.1412090697974; Tue, 30 Sep 2014 08:24:57 -0700 (PDT) X-Gm-Message-State: ALoCoQlUvLMlrh+3tAuAo/AnULq8KIsrS0vytHsWb8FFs5q10DryJZ9C7cKdE6Bi4JAOK+E31nFLmHC1y4XPqjZDvgqqtncWBf+b+8Q/jBhCBFJVWTeP89E8Inl0Qdc4i+J3zrm3S678tZsH7B+/s/HiupShDjn/dA== MIME-Version: 1.0 X-Received: by 10.50.170.196 with SMTP id ao4mr9137886igc.46.1412090697865; Tue, 30 Sep 2014 08:24:57 -0700 (PDT) Received: by 10.43.61.201 with HTTP; Tue, 30 Sep 2014 08:24:57 -0700 (PDT) Date: Tue, 30 Sep 2014 11:24:57 -0400 Message-ID: Subject: Addressing refcount issues in ip6_setdstifaddr and ip6_getdstifaddr routines. From: Vedant Mathur To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Sep 2014 15:31:09 -0000 Hi all, I am trying to address the refcount issues in the routine ip6_setdstifaddr defined in the file ip6_input.c. The issue is described below: The ip6_setdstifaddr routine is responsible for adding m_tags to an mbuf and stashing the struct in6_ifaddr reference in the m_tag. Since the in6_ifaddr struct stores a reference to the struct ifaddr as well, we have the ability to access the memory location of the struct ifaddr using the ip6_getdstifaddr routine. We can access the memory location of the struct ifaddr by accessing the reference to it stored in the in6_ifaddr in the m_tag prepended to the mbuf. The struct ifaddr is refcounted using the routines defined in the file refcount.h. The problem here is that we may be accessing freed memory when we call the ip6_getdstifaddr routine since we are not incrementing the refcount for the struct ifaddr, whose reference is stored in the in6_ifaddr, whose reference is stashed in the m_tag. We should be incrementing the refcount of the struct ifaddr when we stash the in6_ifaddr reference in the m_tag. This is the first part of the issue. The second part of the issue is addressing concerns regarding copying and freeing of the m_tag/mbuf. We need to modify the routines involved in copying and freeing of m_tags/mbufs such that they manage the refcount properly. The comments above the two routines in question mention the second part of the issue described above to some extent. It is attributed to the lack of deep copy support for the m_tags. > 1028 * XXXRW: We should bump the refcount on ia6 before sticking it in > the m_tag, > 1029 * and then bump it when the tag is copied, and release it when the > tag is > 1030 * freed. Unfortunately, m_tags don't support deep copies (yet), so > instead > 1031 * we just bump the ia refcount when we receive it. This should be > fixed. > 1032 */ > 1033 static struct ip6aux * > 1034 ip6_setdstifaddr(struct mbuf *m, struct in6_ifaddr *ia6) > 1035 { > 1036 struct ip6aux *ip6a; > 1037 > 1038 ip6a = ip6_addaux(m); > 1039 if (ip6a) > 1040 ip6a->ip6a_dstia6 = ia6; <<<<<<<<<< > We should be incrementing the refcount to struct ifaddr in &ia6->ia_ifa > here. > 1041 return ip6a; /* NULL if failed to set */ > 1042 } > 1043 > 1044 struct in6_ifaddr * > 1045 ip6_getdstifaddr(struct mbuf *m) > 1046 { > 1047 struct ip6aux *ip6a; > 1048 struct in6_ifaddr *ia; > 1049 > 1050 ip6a = ip6_findaux(m); > 1051 if (ip6a) { > 1052 ia = ip6a->ip6a_dstia6; > 1053 ifa_ref(&ia->ia_ifa); <<<<<<< This reference > to the struct ifaddr (&ia->ia_ifa) can be stale and can potentially point > to freed memory. > 1054 return ia; > 1055 } else > 1056 return NULL; > 1057 } > 1058 The following change also talks about the issue somewhat: https://svnweb.freebsd.org/base?view=revision&revision=194760 Below I have a couple solutions and would like your feedback on these solutions. Which one of these two solutions would you think is better and why. I would prefer to incorporate a solution in my code which aligns more with the FreeBSD community so that future refreshes are easier. *Solution 1:* 1) Increment the refcount when we stash the struct in6_ifaddr reference in the m_tag in ip6_setdstifaddr routine. 2) Modify the m_tag_copy routine to address the special case of the IPv6 tag where it calls ifa_ref(). This is to make sure that IF AT ANY POINT we copy the mbuf with the IPv6 tag we are incrementing the refcnt. Also any other routines capable of copying the m_tag/mbuf should be modified similarly. 3) Modify the m_tag_delete() routine to address the special case of the IPv6 tag where it calls ifa_free(). This is to make sure that when we delete the mbuf/m_tag with the IPv6 tag we decrement the refcnt. Also any other routines capable of freeing the mbuf/m_tag should be modified. *Solution 2:* In ip6_setdstifaddr() routine we can access the struct ifa using ia6->ia_ifa and retrieve the IP address from the ifa and then push it into the m_tag instead of the struct in6_ifaddr pointer. Then we will not require a refcnt increment and in the ip6_getdstifaddr() we can use the ifa_withifaddr() routines to retrieve the ia by basically looping through the list of ifaddrs. Regards, Vedant Mathur From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 15:31:09 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70CE6BF1 for ; Tue, 30 Sep 2014 15:31:09 +0000 (UTC) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49B1ECDF for ; Tue, 30 Sep 2014 15:31:09 +0000 (UTC) Received: from rrcs-50-74-141-241.nyc.biz.rr.com ([50.74.141.241]:57457 helo=[192.168.1.39]) by vps.hungerhost.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1XYzON-0005Cq-6T for net@freebsd.org; Tue, 30 Sep 2014 11:31:07 -0400 From: "George Neville-Neil" To: net@freebsd.org Subject: Neworking Wiki Page updated... Date: Tue, 30 Sep 2014 11:31:08 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.8r4469) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Sep 2014 15:31:09 -0000 Howdy, I've attempted to gather all the Networking TODOs from our various, scattered, wiki pages and concentrate them all in one place. Please review https://wiki.freebsd.org/Networking and if you need update that page. That is now the central page for all our networking todos and the like. Best, George From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 15:33:15 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8F6ADB2 for ; Tue, 30 Sep 2014 15:33:15 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A433DD11 for ; Tue, 30 Sep 2014 15:33:15 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2E441B939; Tue, 30 Sep 2014 11:33:14 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: getting factory MAC address Date: Tue, 30 Sep 2014 11:29:24 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <1411301597.21088.7.camel@eva02> In-Reply-To: <1411301597.21088.7.camel@eva02> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201409301129.24825.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 30 Sep 2014 11:33:14 -0400 (EDT) Cc: clutton X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Sep 2014 15:33:15 -0000 On Sunday, September 21, 2014 8:13:17 am clutton wrote: > Hi list. I'm relatively new here. So, Hi. :) > > I don't know how to read the real MAC, I mean the one which is burned in > ROM. Is it possible from the user space? I've ported GNU macchanger and > it's the last non ported feature. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187363 > > In Linux it can be done like this: > https://github.com/alobbs/macchanger/blob/master/src/netinfo.c#L118 There is currently not a way to do this, though there is a patch to add this functionality currently on the lists. I believe gnn@ is looking at that patch? -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 15:33:17 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 616A9DB3 for ; Tue, 30 Sep 2014 15:33:17 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3B03ED12 for ; Tue, 30 Sep 2014 15:33:17 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F1A2CB93B; Tue, 30 Sep 2014 11:33:15 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: Choice of private ioctl approach Date: Tue, 30 Sep 2014 11:31:31 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <54295246.6010502@solarflare.com> In-Reply-To: <54295246.6010502@solarflare.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201409301131.31309.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 30 Sep 2014 11:33:16 -0400 (EDT) Cc: Andrew Rybchenko X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Sep 2014 15:33:17 -0000 On Monday, September 29, 2014 8:36:22 am Andrew Rybchenko wrote: > Hello, > > we need to add private ioctl to the driver sfxge(4) to make FW update, > do internal diagnostics commands etc. > We see at least two approaches in other drivers: > 1. SIOCGPRIVATE_0/ SIOCGPRIVATE_1 on net device > 2. dedicated char device with its own ioctl's > > Is there any recommendations on which way is preferred? I would be inclined towards 2). It is more flexible if you need to add more custom ioctls in the future. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 16:45:24 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5F7989D for ; Tue, 30 Sep 2014 16:45:23 +0000 (UTC) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B4BC07FA for ; Tue, 30 Sep 2014 16:45:23 +0000 (UTC) Received: by mail-oi0-f51.google.com with SMTP id e131so4780790oig.38 for ; Tue, 30 Sep 2014 09:45:23 -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:content-type; bh=Fky1DaKMVUlLPzhmTsbUttmaPhuJHliuTZKr/M6/fOk=; b=cuZHa6Fy0u7Z5pHIX8GSAOebMaFtTT/HNLU6l1xZ2d12vUAtA1U755Ojb4475M4G/M H1rH7sKNlarbecZnnG14pQVUf6JnLB3jgFWkD+A2ikwsfQCwiJ0OcRFQrVR/Z68dnWDJ 9FTHM4qnWYOje5AtQ5vfvbJF3cjZZhPkEEZuIHaPOgJRdrTlek8Ktoxi98MI6kOCHXuO aMbj1QKGAqB2Iky1lOev9LCdiZQrj5qZAZ2McYbcBEws5a8ANPghZx7nO+AjUkO4N215 3zkKo31etkDQ6OuxYUMoMIlkdtDuYTBy4HxYYyg4OwW7ZD2m80LUtYptO/008+D5L2aB 0zVw== MIME-Version: 1.0 X-Received: by 10.60.124.115 with SMTP id mh19mr49306834oeb.40.1412095522937; Tue, 30 Sep 2014 09:45:22 -0700 (PDT) Received: by 10.202.115.4 with HTTP; Tue, 30 Sep 2014 09:45:22 -0700 (PDT) Date: Tue, 30 Sep 2014 13:45:22 -0300 Message-ID: Subject: Will netmap-ipfw fwd? From: Eduardo Meyer To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Sep 2014 16:45:24 -0000 I have a problem, where I need to fwd a high rate of pps, and I dont have enough CPU. It's around 900Kpps, so I would like to know if ipfw userland version with netmap support will do fwd? Here are my current rules: 00100 fwd 10.1.2.1 tag tcp from table(100) to any dst-port 80,1024-65535 in { via lagg0 or via vlan1010 } 00200 prob 0.500000 fwd 10.1.2.2 tcp from any 80,1024-65535 to table(100) in { via igb6 or via igb7 } 00300 fwd 10.1.2.3 tcp from any 80,1024-65535 to table(100) in { via igb6 or via igb7 } With those rules, my CPU interrupt rate raises from 30% to 80%. If netmap/ipfw has the ability to fwd should I expect a better interrupt rate and lower load? Sorry to ask before actually trying but this is a production environment and I don't have enough room to test, I would like to read opinions before finding out a nightly window to do the changes and tests. Thank you. -- =========== Eduardo Meyer pessoal: dudu.meyer@gmail.com profissional: ddm.farmaciap@saude.gov.br From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 16:49:49 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88C50CF0 for ; Tue, 30 Sep 2014 16:49:49 +0000 (UTC) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1011E840 for ; Tue, 30 Sep 2014 16:49:48 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id hz20so3982108lab.25 for ; Tue, 30 Sep 2014 09:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=tiOJHapF75kZIfpl9Jx7Gq3ibPGEuclTrCli1K8G/8o=; b=QnYAsddT8moLE4gJOyv0BjeCFRuOiGu8j8w8gBRvsiWU5UBaprziHb9CAbDsj8flNu vGF/Gwv98UGkRR9bVS9hMH2ZgHLONiHUXECQZiDO5b4Uz0bEyk4KvFJtj+uwZi4bBPKq q0drQ2y5wgUIl4aN0b0NRjRUTPrjtapBuC+uCJLlnDlenF2PfCj7BBTEGLx+NuZxAayU JyU6vjfF3knr37Faj05XhL2r5nV3DDjM8qfxl/PauYik4JZjQTvxbfqQN9o9GYZAxRmS 2xGPJo5g12pGu6WuCVaS+jiwj2hA1iS20CkxoGAx01lkO3iTHxb7pv4YCCuHN/6pSX98 c1eQ== MIME-Version: 1.0 X-Received: by 10.112.169.37 with SMTP id ab5mr24641399lbc.27.1412095786278; Tue, 30 Sep 2014 09:49:46 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.26.37 with HTTP; Tue, 30 Sep 2014 09:49:46 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Sep 2014 18:49:46 +0200 X-Google-Sender-Auth: gT8MKj8eRsiKwae1cM21XpJaJSA Message-ID: Subject: Re: Will netmap-ipfw fwd? From: Luigi Rizzo To: Eduardo Meyer Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Sep 2014 16:49:49 -0000 Should work. Please try the latest version from code.google.com/p/netmap-ipfw/ Cheers Luigi On Tuesday, September 30, 2014, Eduardo Meyer wrote: > I have a problem, where I need to fwd a high rate of pps, and I dont have > enough CPU. It's around 900Kpps, so I would like to know if ipfw userland > version with netmap support will do fwd? > > Here are my current rules: > > 00100 fwd 10.1.2.1 tag tcp from table(100) to any dst-port 80,1024-65535 in > { via lagg0 or via vlan1010 } > > 00200 prob 0.500000 fwd 10.1.2.2 tcp from any 80,1024-65535 to table(100) > in { via igb6 or via igb7 } > 00300 fwd 10.1.2.3 tcp from any 80,1024-65535 to table(100) in { via igb6 > or via igb7 } > > With those rules, my CPU interrupt rate raises from 30% to 80%. > > If netmap/ipfw has the ability to fwd should I expect a better interrupt > rate and lower load? > > Sorry to ask before actually trying but this is a production environment > and I don't have enough room to test, I would like to read opinions before > finding out a nightly window to do the changes and tests. > > Thank you. > > -- > =========== > Eduardo Meyer > pessoal: dudu.meyer@gmail.com > profissional: ddm.farmaciap@saude.gov.br > _______________________________________________ > 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 > " > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 18:01:02 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFBFBBD1; Tue, 30 Sep 2014 18:01:02 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9B5981DD; Tue, 30 Sep 2014 18:01:02 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5622EB9CF; Tue, 30 Sep 2014 14:01:01 -0400 (EDT) From: John Baldwin To: net@freebsd.org Subject: [PATCH] Only lock send buffer in sopoll() if needed Date: Tue, 30 Sep 2014 14:00:09 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201409301400.09999.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 30 Sep 2014 14:01:01 -0400 (EDT) Cc: Robert Watson X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Sep 2014 18:01:02 -0000 Right now sopoll() always locks both socket buffers. The receive socket buffer lock is always needed, but the send socket buffer lock is only needed while polling for writing (there is a potential test of SBS_CANTSENDMORE without the lock, but I think this might be ok). What do folks think? Index: uipc_socket.c =================================================================== --- uipc_socket.c (revision 272305) +++ uipc_socket.c (working copy) @@ -3003,7 +3003,12 @@ sopoll_generic(struct socket *so, int events, stru { int revents = 0; - SOCKBUF_LOCK(&so->so_snd); + if (events & (POLLOUT | POLLWRNORM)) + SOCKBUF_LOCK(&so->so_snd); + /* + * The so_rcv lock doubles as SOCK_LOCK so it it is needed for + * all requests. + */ SOCKBUF_LOCK(&so->so_rcv); if (events & (POLLIN | POLLRDNORM)) if (soreadabledata(so)) @@ -3038,7 +3043,8 @@ sopoll_generic(struct socket *so, int events, stru } SOCKBUF_UNLOCK(&so->so_rcv); - SOCKBUF_UNLOCK(&so->so_snd); + if (events & (POLLOUT | POLLWRNORM)) + SOCKBUF_UNLOCK(&so->so_snd); return (revents); } -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 18:27:48 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2FCB4DE for ; Tue, 30 Sep 2014 18:27:48 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [67.212.89.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 70AE1673 for ; Tue, 30 Sep 2014 18:27:47 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id CE571139CA for ; Tue, 30 Sep 2014 15:19:36 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-transfer-encoding:content-type:content-type :in-reply-to:references:subject:subject:to:mime-version :user-agent:from:from:date:date:message-id; s=dkim; t= 1412101175; x=1412965176; bh=rQ2dcahoMtrMKfBS1PFvVJkdQxkZcs3RpUL pxkg4dOM=; b=fjZFbwkp66xOQBcnjf85n7PuV+XiODK9NMb8rHETvVdLabBHcgo HGlaF8AGh0edzYdzr4DINS0VHqLKAGq4ACmBXjihed0fzZiW9j6mIvX6dSGuP69m IU4o6JD340l9ZGa5aU9ry58FU8SJEQy8L3TC91VCOxsGOTiDCe+434z0= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nOvFdUR5LD5 for ; Tue, 30 Sep 2014 15:19:35 -0300 (BRT) Received: from [192.168.88.15] (unknown [186.193.48.8]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id 7875C139C9 for ; Tue, 30 Sep 2014 15:19:35 -0300 (BRT) Message-ID: <542AF42B.60206@bsdinfo.com.br> Date: Tue, 30 Sep 2014 15:19:23 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Will netmap-ipfw fwd? References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Sep 2014 18:27:48 -0000 On 30/09/2014 13:49, Luigi Rizzo wrote: > Should work. > Please try the latest version from code.google.com/p/netmap-ipfw/ > > Cheers > Luigi Hi Luigi, The netmap-ipfw be included in the FreeBSD 10.1 final? Cheers, Gondim > > On Tuesday, September 30, 2014, Eduardo Meyer wrote: > >> I have a problem, where I need to fwd a high rate of pps, and I dont have >> enough CPU. It's around 900Kpps, so I would like to know if ipfw userland >> version with netmap support will do fwd? >> >> Here are my current rules: >> >> 00100 fwd 10.1.2.1 tag tcp from table(100) to any dst-port 80,1024-65535 in >> { via lagg0 or via vlan1010 } >> >> 00200 prob 0.500000 fwd 10.1.2.2 tcp from any 80,1024-65535 to table(100) >> in { via igb6 or via igb7 } >> 00300 fwd 10.1.2.3 tcp from any 80,1024-65535 to table(100) in { via igb6 >> or via igb7 } >> >> With those rules, my CPU interrupt rate raises from 30% to 80%. >> >> If netmap/ipfw has the ability to fwd should I expect a better interrupt >> rate and lower load? >> >> Sorry to ask before actually trying but this is a production environment >> and I don't have enough room to test, I would like to read opinions before >> finding out a nightly window to do the changes and tests. >> >> Thank you. >> >> -- >> =========== >> Eduardo Meyer >> pessoal: dudu.meyer@gmail.com >> profissional: ddm.farmaciap@saude.gov.br >> _______________________________________________ From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 18:33:33 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41D067EC for ; Tue, 30 Sep 2014 18:33:33 +0000 (UTC) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A8FBA7B2 for ; Tue, 30 Sep 2014 18:33:32 +0000 (UTC) Received: by mail-lb0-f175.google.com with SMTP id u10so5091138lbd.34 for ; Tue, 30 Sep 2014 11:33:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9MyqWwXmSkiqbdaLfId1HA58cpvr/67CodtjKmFRgcc=; b=wZ3ib8CgmEOjznR57XR0IQHYjqq5VJwvpl+fSh682Dp7AR4YkWTt4hO1BxqhPScEsX z/iY6/SDlyN8SO/QNYgdVZuGlfvC5WzlzV+GbXo520tLQdmLDZFk1wQCtWbBJ/voxVo3 x+gZD+lBBoss3J9xSVhMK+fhVtxgvpTv4oZ1TG6fMtRP7EwaFIYsEwx6xocYjUzV61DM /lLSlpGU+DPR3W/cnUlQZWO78+C/llBf3/qvmDqfCiT50vx3ioY2bd3oKMW5fIbGWnty ji6M1lAPGhhzM6ndljCTH3xxCBg7aN/+wT67Q0IkiL7+TNTVf2MXouVR3bnRdDTIBYFl sSwg== MIME-Version: 1.0 X-Received: by 10.112.72.10 with SMTP id z10mr17924717lbu.87.1412102010501; Tue, 30 Sep 2014 11:33:30 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.26.37 with HTTP; Tue, 30 Sep 2014 11:33:30 -0700 (PDT) In-Reply-To: <542AF42B.60206@bsdinfo.com.br> References: <542AF42B.60206@bsdinfo.com.br> Date: Tue, 30 Sep 2014 20:33:30 +0200 X-Google-Sender-Auth: uttLRZUgw67vwJn06IyLPYm_QJ8 Message-ID: Subject: Re: Will netmap-ipfw fwd? From: Luigi Rizzo To: Marcelo Gondim Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Sep 2014 18:33:33 -0000 On Tue, Sep 30, 2014 at 8:19 PM, Marcelo Gondim wrote: > On 30/09/2014 13:49, Luigi Rizzo wrote: > >> Should work. >> Please try the latest version from code.google.com/p/netmap-ipfw/ >> >> Cheers >> Luigi >> > > Hi Luigi, > > The netmap-ipfw be included in the FreeBSD 10.1 final? > =E2=80=8Bno it is out of the tree. it's a userspace application anyways, so easy to build cheers luigi =E2=80=8B > > Cheers, > Gondim > > >> On Tuesday, September 30, 2014, Eduardo Meyer >> wrote: >> >> I have a problem, where I need to fwd a high rate of pps, and I dont ha= ve >>> enough CPU. It's around 900Kpps, so I would like to know if ipfw userla= nd >>> version with netmap support will do fwd? >>> >>> Here are my current rules: >>> >>> 00100 fwd 10.1.2.1 tag tcp from table(100) to any dst-port 80,1024-6553= 5 >>> in >>> { via lagg0 or via vlan1010 } >>> >>> 00200 prob 0.500000 fwd 10.1.2.2 tcp from any 80,1024-65535 to >>> table(100) >>> in { via igb6 or via igb7 } >>> 00300 fwd 10.1.2.3 tcp from any 80,1024-65535 to table(100) in { via ig= b6 >>> or via igb7 } >>> >>> With those rules, my CPU interrupt rate raises from 30% to 80%. >>> >>> If netmap/ipfw has the ability to fwd should I expect a better interrup= t >>> rate and lower load? >>> >>> Sorry to ask before actually trying but this is a production environmen= t >>> and I don't have enough room to test, I would like to read opinions >>> before >>> finding out a nightly window to do the changes and tests. >>> >>> Thank you. >>> >>> -- >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> Eduardo Meyer >>> pessoal: dudu.meyer@gmail.com >>> profissional: ddm.farmaciap@saude.gov.br >>> _______________________________________________ >>> >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --=20 -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 18:40:39 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F85CA59 for ; Tue, 30 Sep 2014 18:40:39 +0000 (UTC) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.103]) by mx1.freebsd.org (Postfix) with ESMTP id EB233814 for ; Tue, 30 Sep 2014 18:40:38 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=subject:from:to:in-reply-to:references:content-type:date:message-id:mime-version; b=I0HfgZq37NkaKR9Km1qcNorCj73c2dEkjiXvoUw20aNw8TAh50CWHvpX4ZR3gJ1YjRVxdh1wX0ea hTrum2S2V10DfsnyUciTyARY3wlzbKa4QPlRC/9Dr35QVe1ZRZH6 Received: from [192.168.11.5] (46.229.54.117 [46.229.54.117]) by mx.zohomail.com with SMTPS id 1412101438604867.2155824796317; Tue, 30 Sep 2014 11:23:58 -0700 (PDT) Subject: Re: getting factory MAC address From: clutton To: freebsd-net@freebsd.org In-Reply-To: <201409301129.24825.jhb@freebsd.org> References: <1411301597.21088.7.camel@eva02> <201409301129.24825.jhb@freebsd.org> Content-Type: text/plain; charset="UTF-8" Date: Tue, 30 Sep 2014 21:23:54 +0300 Message-ID: <1412101434.4372.11.camel@eva02.mbsd> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-ZohoMail: Ss SS_10 UW UB ZCF-710TPL UW UB SF_TD_EXT SGR3_1_23094_97 X-ZohoMail-Owner: <1412101434.4372.11.camel@eva02.mbsd>+zmo_0_ X-ZohoMail-Sender: 46.229.54.117 X-Zoho-Virus-Status: 2 X-ZohoMailClient: External X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Sep 2014 18:40:39 -0000 Thank you for answering, I looked for functionality by myself, and found none before asking. Drivers do it in different ways. On Tue, 2014-09-30 at 11:29 -0400, John Baldwin wrote: > On Sunday, September 21, 2014 8:13:17 am clutton wrote: > > Hi list. I'm relatively new here. So, Hi. :) > > > > I don't know how to read the real MAC, I mean the one which is burned in > > ROM. Is it possible from the user space? I've ported GNU macchanger and > > it's the last non ported feature. > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187363 > > > > In Linux it can be done like this: > > https://github.com/alobbs/macchanger/blob/master/src/netinfo.c#L118 > > There is currently not a way to do this, though there is a patch to add this > functionality currently on the lists. I believe gnn@ is looking at that > patch? > From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 18:57:59 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9CE26133 for ; Tue, 30 Sep 2014 18:57:59 +0000 (UTC) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 66607A7C for ; Tue, 30 Sep 2014 18:57:59 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id wp18so56509obc.5 for ; Tue, 30 Sep 2014 11:57:58 -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=eXwQDzfRET+GvA5QvGii8HbI8l9g7DYllQaiL28vWzQ=; b=v+dDXCLQl2B+PIaYjNl8O3zi99RT5x11CkCfcij67k9GmM/Yonnm7byMn6KPNi/lRw 6ar2mCG3AnifKwJcp/9yD6xGjcg6VAV1ACL2I0KwfevtQIH3e78JRylrGIjHv2hdvzRp V9SWZO9VMCPq5vdgtSeyi/vzw9FshVN4giftXiIBohmyAyNcfk6I4dQRLqWs5LRsA98f pYRKuuDDf0qMXRQOsjTt50JuGO45aLs86Yg8rYBiKcTp0LFqFta8z7T+poWt0wkVHCVZ 3+Q2SGjPljhAioc+GMSbpHIhr75Pg9jKZJhnw0Bbemnc/buLwabzAiGtWcoFkFDx9LO+ 5bkw== MIME-Version: 1.0 X-Received: by 10.60.160.74 with SMTP id xi10mr51853552oeb.56.1412103478425; Tue, 30 Sep 2014 11:57:58 -0700 (PDT) Received: by 10.202.115.4 with HTTP; Tue, 30 Sep 2014 11:57:58 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Sep 2014 15:57:58 -0300 Message-ID: Subject: Re: Will netmap-ipfw fwd? From: Eduardo Meyer To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Sep 2014 18:57:59 -0000 On Tue, Sep 30, 2014 at 1:49 PM, Luigi Rizzo wrote: > Should work. > Please try the latest version from code.google.com/p/netmap-ipfw/ > > Cheers > Luigi > OK just cloned. What should tbe topology be like? igb(4) -> netmap bridge -> vale -> ipfw? will lagg0 -> netmap bridge -> ipfw work too? > > On Tuesday, September 30, 2014, Eduardo Meyer > wrote: > >> I have a problem, where I need to fwd a high rate of pps, and I dont have >> enough CPU. It's around 900Kpps, so I would like to know if ipfw userland >> version with netmap support will do fwd? >> >> Here are my current rules: >> >> 00100 fwd 10.1.2.1 tag tcp from table(100) to any dst-port 80,1024-65535 >> in >> { via lagg0 or via vlan1010 } >> >> 00200 prob 0.500000 fwd 10.1.2.2 tcp from any 80,1024-65535 to table(100) >> in { via igb6 or via igb7 } >> 00300 fwd 10.1.2.3 tcp from any 80,1024-65535 to table(100) in { via igb6 >> or via igb7 } >> >> With those rules, my CPU interrupt rate raises from 30% to 80%. >> >> If netmap/ipfw has the ability to fwd should I expect a better interrupt >> rate and lower load? >> >> Sorry to ask before actually trying but this is a production environment >> and I don't have enough room to test, I would like to read opinions before >> finding out a nightly window to do the changes and tests. >> >> Thank you. >> >> -- >> =========== >> Eduardo Meyer >> pessoal: dudu.meyer@gmail.com >> profissional: ddm.farmaciap@saude.gov.br >> _______________________________________________ >> 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" >> > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2211611 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > > -- =========== Eduardo Meyer pessoal: dudu.meyer@gmail.com profissional: ddm.farmaciap@saude.gov.br From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 19:20:18 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB01F8B4 for ; Tue, 30 Sep 2014 19:20:18 +0000 (UTC) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 511C1CF3 for ; Tue, 30 Sep 2014 19:20:18 +0000 (UTC) Received: by mail-la0-f44.google.com with SMTP id gi9so10656115lab.3 for ; Tue, 30 Sep 2014 12:20:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=nbAFOXEWQzrxS3aNrzGz3Ko+NyNlQzSz/rI642SaIRA=; b=OO4j/rxjJSjqrXssatLJ7k8+Ay3Jz3z99ec6ZhiStr5tilafkgpYD9QoZfGCUugiC7 kvkIZVXgbnnOMi3wvlEWRTKlEZbqX3Yn5KOHtNFrxe/5IKbWpZs1IdH9zgoZuOSFgVuS 9pJ2vs5ZPh6V44NzZKFjDJiI4H0r4dR/l2GQxnryUWR8MvcgJV1fsu4Ywqg10jhAUxlg UUn7M4hYXplxUu+BklM0g3liMEEaGATvsJ+dVmvgHbhb0HEDuA9SGO8v6ugAeyV+IwBI LoH/XNlYS31QeyX0UAyRXAq+qhk38xufMPjKsLl3+Qpq4cRPdpEdBhGA9vqkyKj6mx8M ygUw== MIME-Version: 1.0 X-Received: by 10.152.42.173 with SMTP id p13mr48060811lal.23.1412104816233; Tue, 30 Sep 2014 12:20:16 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.26.37 with HTTP; Tue, 30 Sep 2014 12:20:16 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Sep 2014 21:20:16 +0200 X-Google-Sender-Auth: 8R2KZ1clp-RKZJu5cRpqlQbr8bM Message-ID: Subject: Re: Will netmap-ipfw fwd? From: Luigi Rizzo To: Eduardo Meyer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Sep 2014 19:20:18 -0000 On Tue, Sep 30, 2014 at 8:57 PM, Eduardo Meyer wrote= : > > > On Tue, Sep 30, 2014 at 1:49 PM, Luigi Rizzo wrote: > >> Should work. >> Please try the latest version from code.google.com/p/netmap-ipfw/ >> >> Cheers >> Luigi >> > > OK just cloned. > > What should tbe topology be like? > > igb(4) -> netmap bridge -> vale -> ipfw? > > will lagg0 -> netmap bridge -> ipfw work too? > netmap-ipfw runs directly on top of the interfaces. please try to understand the model of operation of netmap before using it. cheers luigi =E2=80=8B From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 19:42:48 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1288CF1C for ; Tue, 30 Sep 2014 19:42:48 +0000 (UTC) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CF14F8 for ; Tue, 30 Sep 2014 19:42:47 +0000 (UTC) Received: by mail-oi0-f41.google.com with SMTP id a141so1210161oig.0 for ; Tue, 30 Sep 2014 12:42: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=zgbPX/NASrmssDrVESfwSa9c9gj/aRSvWiIzH8c8JqU=; b=jptIy7OuqUHiThzH0Qvwn2yE0wYSc9d+qHogqUvdJhcDuoQVI7T6EXTXKxi8B8t9TE e3kjmjXHpQrrRPngwQi94HeMaWqvDeUAD1Z9/9ep8v1+TaiJX+sTb0PQyAbo6AKStlBO iZRPu1HQbV/KARbBih4Kj22SISzh0ZOLVcU5w+C5FjOzvxC3CNLP8NUMjbOSbbAKXCX1 ZEz8b2glNQPVnA961KV7ZVyCrZwQknb6M24wYsGHA59XOQjECkdmb7elyI7Dk8sk4rrA sH0dHNQnSqI0BG35KJKyUO19342JVclM5d4J1AujrGwbSwxQwoGDfsGqGOyT2v4WGIOP hefw== MIME-Version: 1.0 X-Received: by 10.60.124.115 with SMTP id mh19mr50628403oeb.40.1412106166842; Tue, 30 Sep 2014 12:42:46 -0700 (PDT) Received: by 10.202.115.4 with HTTP; Tue, 30 Sep 2014 12:42:46 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Sep 2014 16:42:46 -0300 Message-ID: Subject: Re: Will netmap-ipfw fwd? From: Eduardo Meyer To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Sep 2014 19:42:48 -0000 On Tue, Sep 30, 2014 at 4:20 PM, Luigi Rizzo wrote: > > > On Tue, Sep 30, 2014 at 8:57 PM, Eduardo Meyer > wrote: > >> >> >> On Tue, Sep 30, 2014 at 1:49 PM, Luigi Rizzo wrote: >> >>> Should work. >>> Please try the latest version from code.google.com/p/netmap-ipfw/ >>> >>> Cheers >>> Luigi >>> >> >> OK just cloned. >> >> What should tbe topology be like? >> >> igb(4) -> netmap bridge -> vale -> ipfw? >> >> will lagg0 -> netmap bridge -> ipfw work too? >> > > netmap-ipfw runs directly on top of the interfaces. > please try to understand the model of operation > of netmap before using it. > > cheers > luigi > =E2=80=8B > Im trying but im lacking documentation and examples. On top of the interface I tried this way: ./kipfw netmap:igb0 netmap:igb1 & But the interfaces just died. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Eduardo Meyer pessoal: dudu.meyer@gmail.com profissional: ddm.farmaciap@saude.gov.br From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 20:00:27 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3382D438 for ; Tue, 30 Sep 2014 20:00:27 +0000 (UTC) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 97FE8363 for ; Tue, 30 Sep 2014 20:00:26 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id gm9so3118225lab.41 for ; Tue, 30 Sep 2014 13:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=liJj1RFvyuco2rR98yYxga87JRfjg4+6DYd68A5tEOA=; b=aSm47ouq33Tm6lJRFv4hPwTquN+aX2kqDdetl+f8eRxnitC6rNmPaUx1SPF86BD8K7 NKofClDNwVp0nbqKukgpHBelil4SW3F3/YeOD9SKhsQqQ6npbouDSpHtGqxlSc7Xty7j k19SlbraXf5zEDceOAf1IWikIFeAGqYutl9epGSE7nzfBhJBAiumQJuouoDFgIizzH4o JckpGyxjExZSAatOLIiBKZ6NNjp7WfqpMEpCtB0vEzIP6/7j2yvh9cFZ0AMIQ0J5P151 2DGCNV+IhWNHFgZt2iGTgIjacOHOAZMEyqWbMh1VV5PIdZnvnpd4aoskXNWoHdRvb89i 6PxA== MIME-Version: 1.0 X-Received: by 10.152.198.204 with SMTP id je12mr50437401lac.52.1412107224501; Tue, 30 Sep 2014 13:00:24 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.26.37 with HTTP; Tue, 30 Sep 2014 13:00:24 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Sep 2014 22:00:24 +0200 X-Google-Sender-Auth: NsgAn_COQGo7LGDw5JWQMkNtk1U Message-ID: Subject: Re: Will netmap-ipfw fwd? From: Luigi Rizzo To: Eduardo Meyer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Sep 2014 20:00:27 -0000 On Tue, Sep 30, 2014 at 9:42 PM, Eduardo Meyer wrote= : > > > On Tue, Sep 30, 2014 at 4:20 PM, Luigi Rizzo wrote: > >> >> >> On Tue, Sep 30, 2014 at 8:57 PM, Eduardo Meyer >> wrote: >> >>> >>> >>> On Tue, Sep 30, 2014 at 1:49 PM, Luigi Rizzo wrote= : >>> >>>> Should work. >>>> Please try the latest version from code.google.com/p/netmap-ipfw/ >>>> >>>> Cheers >>>> Luigi >>>> >>> >>> OK just cloned. >>> >>> What should tbe topology be like? >>> >>> igb(4) -> netmap bridge -> vale -> ipfw? >>> >>> will lagg0 -> netmap bridge -> ipfw work too? >>> >> >> netmap-ipfw runs directly on top of the interfaces. >> please try to understand the model of operation >> of netmap before using it. >> >> cheers >> luigi >> =E2=80=8B >> > > > Im trying but im lacking documentation and examples. > > On top of the interface I tried this way: > > ./kipfw netmap:igb0 netmap:igb1 & > > But the interfaces just died. > > =E2=80=8Bsorry if i sound direct but this is why i urged you to "understand before using it". There are several papers and slides =E2=80=8Band videos =E2=80=8B on my web page =E2=80=8B and the youtube,=E2=80=8B a pretty long manpage, =E2=80=8B all indicating what happens to the interface (which does not die) when you switch to netmap mode. =E2=80=8BI=E2=80=8B t =E2=80=8Bmay =E2=80=8B take some time to =E2=80=8B read and familiarize with the above, but it is the only way to move forward. We cannot give you recipes because your expectations on what netmap =E2=80=8B =E2=80=8B does do not match =E2=80=8Bthe actual behaviour=E2=80=8B =E2=80=8B. cheers luigi=E2=80=8B =E2=80=8B =E2=80=8B From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 20:58:59 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 045B9762 for ; Tue, 30 Sep 2014 20:58:59 +0000 (UTC) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CEEACCBB for ; Tue, 30 Sep 2014 20:58:58 +0000 (UTC) Received: from pool-96-250-5-187.nycmny.fios.verizon.net ([96.250.5.187]:64073 helo=[192.168.1.13]) by vps.hungerhost.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1XZ4Vd-0001ps-4A; Tue, 30 Sep 2014 16:58:57 -0400 From: "George Neville-Neil" To: "Andrew Rybchenko" Subject: Re: [PATCH 4/4] sfxge: Support tunable to control Tx deferred packet list limits Date: Tue, 30 Sep 2014 16:58:59 -0400 Message-ID: In-Reply-To: <54241572.6000702@solarflare.com> References: <54241572.6000702@solarflare.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.8r4469) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Sep 2014 20:58:59 -0000 On 25 Sep 2014, at 9:15, Andrew Rybchenko wrote: > Support tunable to control Tx deferred packet list limits > > Also increase default for Tx queue get-list limit. > Too small limit results in TCP packets drops especiall when many > streams are running simultaneously. > Put list may be kept small enought since it is just a temporary > location if transmit function can't get Tx queue lock. > The information contained in this message is confidential and is > intended for the addressee(s) only. If you have received this message > in error, please notify the sender immediately and delete the message. > Unless you are an addressee (or authorized to receive for an > addressee), you may not use, copy or disclose to anyone this message > or any information contained in this message. The unauthorized use, > disclosure, copying or alteration of this message is strictly > prohibited. > > [dpl_max.txt] Howdy, All four of the submitted patches have been committed to HEAD as of today. Best, George From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 22:57:54 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A2522CC for ; Tue, 30 Sep 2014 22:57:54 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 71827FEC for ; Tue, 30 Sep 2014 22:57:54 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8UMvsgH078345 for ; Tue, 30 Sep 2014 22:57:54 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 185967] [lagg] [patch] Link Aggregation LAGG: LACP not working in 10.0 Date: Tue, 30 Sep 2014 22:57:54 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ict@gcecad-service.nl X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Sep 2014 22:57:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185967 ict@gcecad-service.nl changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ict@gcecad-service.nl --- Comment #15 from ict@gcecad-service.nl --- Is the patch supposed to be included with 10.1-BETA3? There does not seem to be a sysctl entry called net.link.lagg.lacp.lacp_strict_mode -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Oct 1 00:40:04 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6754C896 for ; Wed, 1 Oct 2014 00:40:04 +0000 (UTC) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3AA18C8E for ; Wed, 1 Oct 2014 00:40:04 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id kq14so82783pab.40 for ; Tue, 30 Sep 2014 17:40:03 -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:in-reply-to:user-agent; bh=0K8gjTXjHrYOkYMF0YiPboHeUmuXrWmHI82xzs71na0=; b=i9rD0xMql9AkaUohNQUeMpAQ7IWmmgwqApHgksvV7UcyuFOcBgml33238Z4klOYKRC IH5GXvHoKNtxMgQIJWZVvLSttV6GXJu0Vvc4YB/URzERaF8ZRZIwyNedVKavelbM44oM xtOlCP0QUXQODhip0ugAS+XjfSPIzxm9J3ykHjnIsV1Yd78Cy4iMwIA1X4Ndpv89OoBI 8Zm01LMLu9UIzX6tbc+kwGZeawkkcCu3RGtjcvPJ0wKwy5ipfxgeO9uzD5s7LhKVRnpG N5xwbf9D8XgNqumsFvaziIzYBfAcq9vB6+h8Fw0yDrmYVOQOooPJGyu+F+QfxZ81h8RW SniQ== X-Received: by 10.70.126.41 with SMTP id mv9mr79697263pdb.129.1412124003809; Tue, 30 Sep 2014 17:40:03 -0700 (PDT) Received: from pyunyh@gmail.com ([106.247.248.2]) by mx.google.com with ESMTPSA id fn4sm16335770pab.39.2014.09.30.17.39.59 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 30 Sep 2014 17:40:02 -0700 (PDT) From: Yonghyeon PYUN X-Google-Original-From: "Yonghyeon PYUN" Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 01 Oct 2014 09:39:54 +0900 Date: Wed, 1 Oct 2014 09:39:54 +0900 To: Nils Beyer Subject: Re: [CFT] alc(4) QAC AR816x/AR817x ethernet controller support Message-ID: <20141001003954.GA2632@michelle.fasterthan.com> Reply-To: pyunyh@gmail.com References: <20140930015741.GA2451@michelle.fasterthan.com> <20140930082053.4D9EFF8F@hub.freebsd.org> <20140930085228.GB969@michelle.fasterthan.com> <20140930093516.80A8943F@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140930093516.80A8943F@hub.freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Oct 2014 00:40:04 -0000 On Tue, Sep 30, 2014 at 11:35:03AM +0200, Nils Beyer wrote: > Hi, > > Yonghyeon PYUN wrote: > >> Then I've connected a network cable and rebooted. I've got a link and > >> performed an "iperf" test. The results are really good: around 930 Mbit/s > >> TX and 840 Mbit/s RX. CPU load during that test: "70.75% kernel{alc0 > >> taskq}". > > > > Hmm, the RX performance number looks bad to me. You have to see > > more than 920Mbps. > > You're right; my fault - sorry for that. The "iperf partner" seems to have a > bad/weak NIC because it also only gets 840 Mbit/s sending to another computer. > So I've exchanged the "iperf partner" with another computer and am getting now > 935 Mbit/s in both directions. > Ok, thanks for letting me know that. If you use jumbo frame you would get better performance numbers. > I should always measure measuring equipment before measuring. > Default interrupt moderation policy is targeted to reduce latency so it will generate up to 10k interrupts/sec under high network load. If you want to reduce number of interrupts/sec, tune interrupt moderation sysctl variables mentioned in alc(4). > > > Could you show me the output of "pciconf -lcbv"? > > Probably not neccessary anymore, but here you are (with additional -e option): > ------------------------------------------------------------------------------- > #pciconf -lcbve | tail -20 > alc0@pci0:2:0:0: class=0x020000 card=0x05621028 chip=0x10911969 rev=0x10 hdr=0x00 > vendor = 'Atheros Communications Inc.' > device = 'AR8161 Gigabit Ethernet' > class = network > subclass = ethernet > bar [10] = type Memory, range 64, base 0xd0400000, size 262144, enabled > bar [18] = type I/O Port, range 32, base 0x2000, size 128, enabled > cap 01[40] = powerspec 3 supports D0 D3 current D0 > cap 10[58] = PCI-Express 1 endpoint max data 128(4096) link x1(x1) > speed 2.5(2.5) ASPM L1(L0s/L1) > cap 05[c0] = MSI supports 16 messages, 64 bit, vector masks > cap 11[d8] = MSI-X supports 16 messages, enabled > Table in map 0x10[0x2000], PBA in map 0x10[0x3000] > ecap 0001[100] = AER 1 0 fatal 1 non-fatal 1 corrected > ecap 0003[180] = Serial 1 ff55c9fb5cf9ddff > PCI-e errors = Correctable Error Detected > Non-Fatal Error Detected > Unsupported Request Detected > Non-fatal = Unsupported Request > Corrected = Bad DLLP > ------------------------------------------------------------------------------- Thanks for the info. > > > > I thought I verified link lost condition before requesting test. > > After reading your mail, I was successfully reproduce it with > > engineering sample board. It seems when link lost time lasts long > > enough alc(4) fails to re-establish a link. > > Confirmed - if the network cable is disconnected long enough I cannot get a > link either. As a workaround I un- and reload the "if_alc" module; then > everything is working again as before... > Updated the diff to address link establishment issue. http://people.freebsd.org/~yongari/alc/pci.quirk.diff http://people.freebsd.org/~yongari/alc/alc.diff.20141001 Thanks. From owner-freebsd-net@FreeBSD.ORG Wed Oct 1 04:07:30 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2C87427 for ; Wed, 1 Oct 2014 04:07:30 +0000 (UTC) Received: from forward4p.cmail.yandex.net (forward4p.cmail.yandex.net [IPv6:2a02:6b8:0:1465::14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5FD5A365 for ; Wed, 1 Oct 2014 04:07:30 +0000 (UTC) Received: from smtp16.mail.yandex.net (smtp16.mail.yandex.net [95.108.252.16]) by forward4p.cmail.yandex.net (Yandex) with ESMTP id BC03713C5; Wed, 1 Oct 2014 08:07:23 +0400 (MSK) Received: from smtp16.mail.yandex.net (localhost [127.0.0.1]) by smtp16.mail.yandex.net (Yandex) with ESMTP id 816E16A0B27; Wed, 1 Oct 2014 08:07:23 +0400 (MSK) Received: from 84.201.165.11-vpn.dhcp.yndx.net (84.201.165.11-vpn.dhcp.yndx.net [84.201.165.11]) by smtp16.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 47IFGsWlof-7M5mnGGj; Wed, 1 Oct 2014 08:07:23 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 9a1cdb24-f338-42ba-9d52-c1369c5910ba DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1412136443; bh=MccTSkLwrrtUrFM9+Bk6b6pDq4uyrQYgp+zjyWn8Iro=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=GVHHcb8KxeZ+EKwppcOc5lBbRE+Rdxxg1vA+IMC6dfUNpysy7oBS0NgByd1ZUJIme c+GJccxkJurDBUf0Sa2Xait1B0bunIJdQG1sCm2siWOkRxoF+iGhtb8JBNF/K05kOk 5ppqBK4tafgXWCIks6Y9gLE8/+jauXs3a5mH/Ktw= Authentication-Results: smtp16.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <542B7D74.4090302@yandex.ru> Date: Wed, 01 Oct 2014 08:05:08 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Vedant Mathur , freebsd-net@freebsd.org Subject: Re: Addressing refcount issues in ip6_setdstifaddr and ip6_getdstifaddr routines. References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Oct 2014 04:07:30 -0000 On 30.09.2014 19:24, Vedant Mathur wrote: > *Solution 2:* > > In ip6_setdstifaddr() routine we can access the struct ifa using > ia6->ia_ifa and retrieve the IP address from the ifa and then push it > into the m_tag instead of the struct in6_ifaddr pointer. Then we will > not require a refcnt increment and in the ip6_getdstifaddr() we can > use the ifa_withifaddr() routines to retrieve the ia by basically > looping through the list of ifaddrs. > Hi, *Solution 3:* Remove this code :) What you think about this? https://svnweb.freebsd.org/base?view=revision&revision=256673 -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Wed Oct 1 08:42:37 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6BE3303 for ; Wed, 1 Oct 2014 08:42:37 +0000 (UTC) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 94E8EE8B for ; Wed, 1 Oct 2014 08:42:37 +0000 (UTC) Received: by mail-oi0-f52.google.com with SMTP id a3so243880oib.25 for ; Wed, 01 Oct 2014 01:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=QwtrdoUuJhbWFPv+Sz7AoR1qNC+BV9r8G6jHVKQKQHs=; b=s0yH8A6yxPnzhW2xxjWnyVrTT14v3WFhnGEF6Ik8YMDyrT/QH0554strIAjnFK43lZ C9x4eY13UekfnJ3DXurS5bRdi6YPnjUg2NXGYwFF1GA4hZ4DlrOgLk+X0qIEu0ZKs5M6 2sCHsuRws7E3lsoj7cGtWl8qLUVelREkUVCAqcRhQixJbchwNgu1OUXGOfo1mZzNJJKv cOtpMAORjI2Bp9E7XlqUgcDsGuBnbbFfis5nJrHs3c0N/RPPOukcsuzhOUno8TnDpZYV l3bDXIZ6mFHYWACiGFhkBo+/cxTrFr7fgXkT1civOyRPZfO9+BX/6XNfZOy+giBAjrDH mjhw== X-Received: by 10.182.52.197 with SMTP id v5mr10109159obo.85.1412152956905; Wed, 01 Oct 2014 01:42:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.34.105 with HTTP; Wed, 1 Oct 2014 01:42:06 -0700 (PDT) From: Long Tran Date: Wed, 1 Oct 2014 03:42:06 -0500 Message-ID: Subject: Netmap - Packet generating performance changes To: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "Gurkan, Deniz" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Oct 2014 08:42:37 -0000 Hello, I am experimenting netmap and see one strange behavior. When I am generating packets using pkt-gen example from PC1 to PC2, the rate is about 3Mpps. But when I run pkg-gen -f rx -i p1p1 from PC2, the generating rate in PC1 goes up to 14.66Mpps. I thought the performance of netmap in one PC didn't depend on the other end. Could anyone help explain it to me please? Thanks, *Long Tran* Research Assistant MS in Network Communications and Technology Project Management University of Houston From owner-freebsd-net@FreeBSD.ORG Wed Oct 1 08:51:05 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9BA670D for ; Wed, 1 Oct 2014 08:51:05 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 7BFFBFAA for ; Wed, 1 Oct 2014 08:51:05 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 96A037300A; Wed, 1 Oct 2014 10:56:01 +0200 (CEST) Date: Wed, 1 Oct 2014 10:56:01 +0200 From: Luigi Rizzo To: Long Tran Subject: Re: Netmap - Packet generating performance changes Message-ID: <20141001085601.GA5641@onelab2.iet.unipi.it> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "Gurkan, Deniz" , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Oct 2014 08:51:05 -0000 On Wed, Oct 01, 2014 at 03:42:06AM -0500, Long Tran wrote: > Hello, > > I am experimenting netmap and see one strange behavior. > When I am generating packets using pkt-gen example from PC1 to PC2, the > rate is about 3Mpps. But when I run pkg-gen -f rx -i p1p1 from PC2, the > generating rate in PC1 goes up to 14.66Mpps. > > I thought the performance of netmap in one PC didn't depend on the other > end. > Could anyone help explain it to me please? flow control on the link is responsible for the slowdown. On FreeBSD, sysctl dev.ix.0.fc=0 disables that On Linux i think it is some ethtool command cheers luigi > > Thanks, > *Long Tran* > Research Assistant > MS in Network Communications and Technology Project Management > University of Houston > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Oct 1 09:15:18 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03525F3D for ; Wed, 1 Oct 2014 09:15:18 +0000 (UTC) Received: from nijmegen.renzel.net (mx1.renzel.net [195.243.213.130]) by mx1.freebsd.org (Postfix) with ESMTP id B53C4323 for ; Wed, 1 Oct 2014 09:15:16 +0000 (UTC) Received: from dublin.vkf.isb.de.renzel.net (unknown [10.0.0.80]) by nijmegen.renzel.net (smtpd) with ESMTP id 6F017141486E for ; Wed, 1 Oct 2014 11:14:47 +0200 (CEST) Received: from asbach.renzel.net (unknown [10.2.0.7]) by dublin.vkf.isb.de.renzel.net (Postfix) with ESMTP id BABBC98529 for ; Wed, 1 Oct 2014 11:14:59 +0200 (CEST) Content-Type: text/plain; charset="ISO-8859-1" From: Nils Beyer Organization: VKF Renzel GmbH Date: Wed, 01 Oct 2014 11:14:59 +0200 User-Agent: KNode/4.12.5 Content-Transfer-Encoding: 7Bit Subject: Re: [CFT] alc(4) QAC AR816x/AR817x ethernet controller support To: freebsd-net@freebsd.org References: <20140930015741.GA2451@michelle.fasterthan.com> <20140930082053.4D9EFF8F@hub.freebsd.org> <20140930085228.GB969@michelle.fasterthan.com> <20140930093516.80A8943F@hub.freebsd.org> <20141001003954.GA2632@michelle.fasterthan.com> Lines: 36 MIME-Version: 1.0 X-Virus-Scanned: clamav-milter 0.98 at nijmegen.renzel.net X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=7.0 tests=BAYES_00,MISSING_MID, UNPARSEABLE_RELAY autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on nijmegen.renzel.net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Oct 2014 09:15:18 -0000 Hi, Yonghyeon PYUN wrote: > Default interrupt moderation policy is targeted to reduce latency > so it will generate up to 10k interrupts/sec under high network > load. If you want to reduce number of interrupts/sec, tune > interrupt moderation sysctl variables mentioned in alc(4). Tried several values here: dev.alc.0.int_rx_mod={1000,10000,100000} dev.alc.0.int_tx_mod={1000,10000,100000} but didn't notice any changes neither in CPU usage nor throughput during the "iperf" test; "kernel{alc0 taskq}" stays at 70-75%. I've downed/upped the interface "alc0" after every change. A simple iSCSI test using the native CTL interface works really well. A "fio" test results in 100MB/s read and write. Double-checking using "netstat -I" confirms gigabit-line speeds at around 120MB/s. CPU usage at "kernel{alc0 taskq}" is as high as in the "iperf" test. So I think that's a limitation of the AR8161 chip. > Updated the diff to address link establishment issue. > http://people.freebsd.org/~yongari/alc/pci.quirk.diff > http://people.freebsd.org/~yongari/alc/alc.diff.20141001 Confirmed; with the anti-hibernation patch, link estalishment is now working flawlessly. Thank you very much for your work... Regards, Nils From owner-freebsd-net@FreeBSD.ORG Wed Oct 1 09:48:52 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F27B177A; Wed, 1 Oct 2014 09:48:51 +0000 (UTC) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F20484C; Wed, 1 Oct 2014 09:48:50 +0000 (UTC) Received: by mail-lb0-f178.google.com with SMTP id w7so401654lbi.37 for ; Wed, 01 Oct 2014 02:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=8jus+cC9lVbpbSamaQAH6btlprDhdy2k39KIMqiox+I=; b=P+mJzrOM9e4UjH1kRc+IlEJb4/N8EgvNjw7QGkkIcgNuCY9kslDsMCL7BJD/bqn/Wj vXVWJeEJOvypbuMWTcrcnmiu5ijPu1u5v2x/BAO5KWfCePxUsLh/RBecIzt2htiJeDEs eQLLkQnjG0W+sTBZpwTJfnAG6EkAXm2msv5HHxmdGfHKANAefDkB9qT36FwCkUWIOvDB 1OQQJaw2OHPNJv+RWoNOPwNINtVCrN28G29/VCZIOPualVhdw3nQWvPgPIF0yxWoawdt Ekjf8jLSuQK4y0ymcxV1LEvOH6cSKv1x8S27MZxGIEKaDGR7323L4t+rBVQJPemVD2wv FeFg== MIME-Version: 1.0 X-Received: by 10.112.185.103 with SMTP id fb7mr10156847lbc.32.1412156928850; Wed, 01 Oct 2014 02:48:48 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.26.37 with HTTP; Wed, 1 Oct 2014 02:48:48 -0700 (PDT) Date: Wed, 1 Oct 2014 11:48:48 +0200 X-Google-Sender-Auth: ktkvZ1IHCJsrE0p3MVCM367DqVo Message-ID: Subject: individual queue blocking entire rx unit on ixgbe (Re: How do I balance bandwidth over several virtual NICs?) From: Luigi Rizzo To: Adrian Chadd , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Elof Ofel , "Alexander V. Chernikov" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Oct 2014 09:48:52 -0000 reviving this thread: i am just running experiments on 10.1 beta3 and even setting dev.ix.*.fc=0 and flipping the interface up and down does not seem to help: if i read only from a subset of the queues, the entire rx unit stalls eventually. I need to drain all queues to keep moving. Just tested this with 8 instances of netmap-ipfw running on an 8-core machine (8 queues enabled). netmap-ipfw netmap:ix0-0 netmap:ix1-0 netmap-ipfw netmap:ix0-1 netmap:ix1-1 ... and the source on another box is blasting on multiple queues with pkt-gen -f tx -i ix0 -d 10.0.10.0-10.0.10.255 I going to look at the driver's code now to see if/how this issue can be addressed. cheers luigi On Tue, Sep 23, 2014 at 6:00 PM, Adrian Chadd wrote: > Ah, this behaviour. > > It's called DROP_EN on the intel igb / ixgbe hardware. Grep the > drivers for that particular register bit/setting. > > Set that bit for an RX queue and it'll instruct the MAC to drop frames > destined if that RX ring is full to it and keep receiving on the other > rings. Otherwise yes, receiving on that ring with the ring full cuases > the MAC to stop receiving on all rings until that ring has free space. > > You flip this on with ixgbe and igb by disabling tx/rx flowcontrol > (sysctl dev.ix|igb.X.fc=0) before configuring the interface. > > > > -a > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Wed Oct 1 10:51:13 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8333BC64 for ; Wed, 1 Oct 2014 10:51:13 +0000 (UTC) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx11.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D707EB1 for ; Wed, 1 Oct 2014 10:51:13 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.04,631,1406617200"; d="asc'?scan'208";a="158152312" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx11-out.netapp.com with ESMTP; 01 Oct 2014 03:51:12 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 1 Oct 2014 03:50:53 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::79b6:a9a2:f48b:f065%21]) with mapi id 15.00.0913.011; Wed, 1 Oct 2014 03:50:53 -0700 From: "Eggert, Lars" To: Stefano Garzarella Subject: Re: netmap on ubuntu 14.04? Thread-Topic: netmap on ubuntu 14.04? Thread-Index: Ac/Zi8NjHSQcge1oS3immNdS/agA8wDLuHGAAAQf5YAANUjTgA== Date: Wed, 1 Oct 2014 10:50:52 +0000 Message-ID: <606F9DB2-CBE2-4334-9C12-089027DED150@netapp.com> References: <321E74F3FD7B9B478555010DC1AFD5D5C7357FD8@HOBEX21.hob.de> <5F642017-96B2-4086-89BF-8917D9BEC932@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_D8075536-3C1F-4D06-B441-23066D696781"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" , "Leupoldt, Martin" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Oct 2014 10:51:13 -0000 --Apple-Mail=_D8075536-3C1F-4D06-B441-23066D696781 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2014-9-30, at 11:25, Stefano Garzarella = wrote: > for linux 3.16, can you try with "next" branch in > https://code.google.com/p/netmap/? Can confirm that the "next" branch works (as in, drivers compile = correctly for 3.16). Not tested behavior/performance yet. Lars --Apple-Mail=_D8075536-3C1F-4D06-B441-23066D696781 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBVCvcndZcnpRveo1xAQKQHAP+Pa75dxL5snQnoXTKyTNdeRTO3tCvhoFb trCm3Ki5tXjsjB536rNGU6DIyly7K4xohhHyUW11OhcmZdxWlzKTdCze+9MO5qXx YNVEzcIERemvRihnDX+taXhnQV/u8hcdvbUkE5JaLCIVn0hOHaHSVYm2UX04KH/g l2Qw7F/yz3E= =pbPO -----END PGP SIGNATURE----- --Apple-Mail=_D8075536-3C1F-4D06-B441-23066D696781-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 1 15:05:48 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89291D68 for ; Wed, 1 Oct 2014 15:05:48 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 10772330 for ; Wed, 1 Oct 2014 15:05:47 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id s91F5i44082247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Oct 2014 19:05:44 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id s91F5iPL082246; Wed, 1 Oct 2014 19:05:44 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 1 Oct 2014 19:05:44 +0400 From: Gleb Smirnoff To: Andrea Venturoli Subject: Re: pf stuck Message-ID: <20141001150544.GP73266@FreeBSD.org> References: <542997C3.5090004@netfence.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <542997C3.5090004@netfence.it> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Oct 2014 15:05:48 -0000 On Mon, Sep 29, 2014 at 07:32:51PM +0200, Andrea Venturoli wrote: A> Today a box of mine (8.4p16/amd64) stopped working as a router; I don't A> have a clear picture, but the internal nets were working perfectly, A> while the external interfaces lagged, dropped connections or stopped A> packets from passing. I'd suggest to upgrade to FreeBSD 10. pf(4) was significantly improved there. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Wed Oct 1 16:59:05 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2904F602 for ; Wed, 1 Oct 2014 16:59:05 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E221B5EE for ; Wed, 1 Oct 2014 16:59:04 +0000 (UTC) Received: from [192.168.1.102] (p508F3C1B.dip0.t-ipconnect.de [80.143.60.27]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id C1C161C0E978B for ; Wed, 1 Oct 2014 18:59:00 +0200 (CEST) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: UDP/IPv6 handling Message-Id: Date: Wed, 1 Oct 2014 18:58:58 +0200 To: FreeBSD Net Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Oct 2014 16:59:05 -0000 Dear all, in udp6_input() we have the following code: if (nxt =3D=3D IPPROTO_UDP && plen !=3D ulen) { UDPSTAT_INC(udps_badlen); goto badunlocked; }=20 /* * Checksum extended UDP header and data. */ if (uh->uh_sum =3D=3D 0) { if (ulen > plen || ulen < sizeof(struct udphdr)) { UDPSTAT_INC(udps_nosum); goto badunlocked; } } I'm trying to understand the UDP code path... So (ulen > plen) can't be true. I'm wondering why do we only check the = ulen is not too short only in the case when the UDP checksum is zero. A zero checksum = should also never happen. I think we should check for ulen < sizeof(struct udphdr) in any case. Opinions? Best regards Michael= From owner-freebsd-net@FreeBSD.ORG Wed Oct 1 17:37:37 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E66A3C3; Wed, 1 Oct 2014 17:37:37 +0000 (UTC) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 01154AD7; Wed, 1 Oct 2014 17:37:36 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id cc10so1469979wib.5 for ; Wed, 01 Oct 2014 10:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=xKAC0DuG0t2kpNlWTOBjo/pPb+quriTVKrJXR/oU32E=; b=loNBnFVSgobYGzS5w0kvExuzNir3Kx1+a7HM0b5xhLaKBSA+fjw+Ys9V9RtqUBV7Mj mW/vE0UdpmUwiapG6P+u1vz0M03V2cfyG+6O3CJGBV+OkI+nOwYDo8IEGBZhSAntttlI QJlHoJOtl5RKIk5luZ7yyeY+xp5ATKPWSUfEGnlfwoo71OMf3tJlnHjufpW61DFfU4lB VCzb3Q2+/UUlJl+MpML9T17xnZngelabaLw1sOgu7rORgB5i10J/NxbazaT7206bBWWu cGz3ow1YrXivQJqUPwZ9mhAc/PI5AJnkY+Ywn83TfkyULH/NEC8ZUM7QuRNQVfpL5te0 CL8Q== MIME-Version: 1.0 X-Received: by 10.180.101.129 with SMTP id fg1mr16222158wib.20.1412185055104; Wed, 01 Oct 2014 10:37:35 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Wed, 1 Oct 2014 10:37:35 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Oct 2014 10:37:35 -0700 X-Google-Sender-Auth: HLlOrRcDzR5rZaH253KHyR2X4HU Message-ID: Subject: Re: individual queue blocking entire rx unit on ixgbe (Re: How do I balance bandwidth over several virtual NICs?) From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" , Elof Ofel , "Alexander V. Chernikov" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Oct 2014 17:37:37 -0000 Hi, Try this on -HEAD. There were some recent fixes to ixgbe that haven't been RFCed. -a From owner-freebsd-net@FreeBSD.ORG Wed Oct 1 18:21:54 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E93CF505; Wed, 1 Oct 2014 18:21:53 +0000 (UTC) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4632B147; Wed, 1 Oct 2014 18:21:53 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id s18so924787lam.23 for ; Wed, 01 Oct 2014 11:21:51 -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=/L0LjQGX5t5YwNzfDixN9VoNW1CEEJyNVx1Z6Vkc/+4=; b=jowJk4cloNB0n1opiUVpoDc+6vSJZQhVghMeB2yRA4OQJb/OcMPEpDp4JgYXB/+agu CavdUQwmD946JFjj8qye9xwzGaetHI1DQWlwkXwUYnnf0+TtfHlfbTb77orQWM2BCjJP BrSXAW1vNtgsihFvraijCMV6skfIz/Uqadv2lobB1yLCtlMok5JqfADBefoATtyGIZoz b41J7PmJvZ+z3kTBZod9LaZD0pyz4cRnlcua3hM+X01//NpTJYZSKsZt5OUkAF31CSYj bIBwC1iOc3tuQLTQjOX5Tq/PCg8PWropCPKYUPz9m+yvHQQKcIybbBp6Bg2XKQhsw6jV 0uzQ== MIME-Version: 1.0 X-Received: by 10.152.204.231 with SMTP id lb7mr56701983lac.44.1412187711200; Wed, 01 Oct 2014 11:21:51 -0700 (PDT) Received: by 10.25.15.96 with HTTP; Wed, 1 Oct 2014 11:21:51 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Oct 2014 11:21:51 -0700 Message-ID: Subject: Re: [Bug 193053] ixgbe(4) IXGBE_LEGACY_TX + ALTQ path broken From: Nick Rogers To: bugzilla-noreply@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Oct 2014 18:21:54 -0000 Any chance we can get some kind of resolution to this for 10.1? On Mon, Sep 22, 2014 at 4:40 PM, wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053 > > --- Comment #8 from ncrogers@gmail.com --- > (In reply to ncrogers from comment #7) > > (In reply to Eric Joyner from comment #6) > > > You didn't try a kernel build with the newer driver that I posted? > > > > I have not. > > I finally had a chance to try this. The newer driver you posted (2.5.25) > seems > to compile successfully with IXGBE_LEGACY_TX defined. This happens to be > under > 9-STABLE. I was not able to test ALTQ behavior with the new driver, but I > imagine it works since the LEGACY path is fixed. > > -- > You are receiving this mail because: > You are the assignee for the bug. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Oct 1 18:28:12 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F807627 for ; Wed, 1 Oct 2014 18:28:12 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 26FF919E for ; Wed, 1 Oct 2014 18:28:12 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s91ISCpN033334 for ; Wed, 1 Oct 2014 18:28:12 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193053] ixgbe(4) IXGBE_LEGACY_TX + ALTQ path broken Date: Wed, 01 Oct 2014 18:28:12 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ncrogers@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Oct 2014 18:28:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053 --- Comment #9 from ncrogers@gmail.com --- Any chance we can get some kind of resolution on this before 10.1? It seems like simply upgrading the ixgbe driver with the latest from Intel fixes the problem. If that is not possible, the changes in the patch I posted are still working for me in production -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Oct 1 18:29:02 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4335B6C8; Wed, 1 Oct 2014 18:29:02 +0000 (UTC) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 75F6C1B0; Wed, 1 Oct 2014 18:29:01 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id hz20so942993lab.11 for ; Wed, 01 Oct 2014 11:28:59 -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=wq2yI7Mg3kkvpWnHgAT8FHPOdgpYoTIHDV6AwEXNgyE=; b=Op6wb6AIt51UGM4MZmEWonSufQnUskMjBF16iNtbAGUHQTY8XbMpZgCy5RFHqQGhPM TbCX0XWR3Wjh0b0XWbjp0MmDjmb1MawxouMo6HZJssS3BPmhStMgVIhkCUwoG3dAkQkX xg2QND58t+/4ai38H33yoCUazpi5b5RYVMUEBXWbpXy6kF6TZh4Lk10mFp1xTgPSUFnK k9kQTFzj59RdWSV/JZw6l0EqSCuB0YVZLxOBhBUIvvgxuq0xsuHzTPKL4zX8tivY4EKT JuXy5/K1BVzv4CUUoIO0Y6Z0ee3IzGe+f5nH3Rg1xyllbN7G9aZY6ZZ12iIgk5Ip+YlR Sn8g== MIME-Version: 1.0 X-Received: by 10.152.19.225 with SMTP id i1mr57429662lae.21.1412188139268; Wed, 01 Oct 2014 11:28:59 -0700 (PDT) Received: by 10.25.15.96 with HTTP; Wed, 1 Oct 2014 11:28:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Oct 2014 11:28:59 -0700 Message-ID: Subject: Re: ixgbe IXGBE_LEGACY_TX breaks build (patch/fix included) From: Nick Rogers To: Nick Rogers Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Adrian Chadd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Oct 2014 18:29:02 -0000 On Wed, Sep 17, 2014 at 8:17 AM, Nick Rogers wrote: > > > On Tue, Aug 26, 2014 at 4:16 PM, Nick Rogers wrote: > >> >> >> >> On Tue, Aug 26, 2014 at 3:36 PM, Adrian Chadd wrote: >> >>> Hi, >>> >>> I'm not surprised the legacy tx path has bitrotted there. >>> >>> Please file a bug with this - https://bugs.freebsd.org/submit/ - and >>> then just keep poking people until it's done. >>> >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053 >> > > Poke. Looking for some triage? > Any chance we can get some kind of resolution on this before 10.1? It seems like simply upgrading the ixgbe driver with the latest from Intel fixes the problem. If that is not possible, the changes in the patch I posted are still working for me in production. > > >> >>> Thank! >>> >>> >>> -a >>> >>> >>> On 26 August 2014 13:42, Nick Rogers wrote: >>> > Hello, >>> > >>> > I am trying to get the ixgbe driver + PF/ALTQ working under stable/9. >>> > Initially, loading a PF rulset with ALTQ enabled fails on an ix >>> interface, >>> > reporting "ix0: driver does not support altq". This is similar to the >>> > behavior over the last few years when dealing with the igb driver. >>> However, >>> > I have been using ALTQ + igb with great success by defining >>> IGB_LEGACY_TX >>> > in the e1000/igb driver code. I noticed that ixgbe has a similar define >>> > IXGBE_LEGACY_TX to enable the legacy, non-multiqueue transmit behavior, >>> > that also "enables" ALTQ support. >>> > >>> > After adding the IXGBE_LEGACY_TX define to ixgbe source, building the >>> > driver fails with the following compile errors: >>> > >>> > /usr/src/sys/dev/ixgbe/ixgbe.c: In function 'ixgbe_msix_que': >>> > /usr/src/sys/dev/ixgbe/ixgbe.c:1529: error: invalid type argument of >>> '->' >>> > (have 'struct ifaltq') >>> > /usr/src/sys/dev/ixgbe/ixgbe.c:1529: error: invalid type argument of >>> '->' >>> > (have 'struct ifaltq') >>> > /usr/src/sys/dev/ixgbe/ixgbe.c: In function 'ixgbe_local_timer': >>> > /usr/src/sys/dev/ixgbe/ixgbe.c:2077: error: 'struct tx_ring' has no >>> member >>> > named 'txq_task' >>> > /usr/src/sys/dev/ixgbe/ixgbe.c: In function >>> 'ixgbe_free_transmit_buffers': >>> > /usr/src/sys/dev/ixgbe/ixgbe.c:3255: error: 'struct tx_ring' has no >>> member >>> > named 'br' >>> > /usr/src/sys/dev/ixgbe/ixgbe.c:3256: error: 'struct tx_ring' has no >>> member >>> > named 'br' >>> > >>> > So it seems that the IXGBE_LEGACY_TX path no longer compiles >>> successfully, >>> > and perhaps never did? Using e1000 as a reference, fixing the pointer >>> > error, and looking at previous revisions of ixgbe.c, I was able to >>> come up >>> > with the following patch that got the driver to compile while having >>> > IXGBE_LEGACY_TX defined. Note that the following svn diff is against >>> HEAD, >>> > which as far as I can tell contains the same broken IXGBE_LEGACY_TX >>> path as >>> > stable/9 and stable/10. >>> > >>> > Index: ixgbe.c >>> > =================================================================== >>> > --- ixgbe.c (revision 270665) >>> > +++ ixgbe.c (working copy) >>> > @@ -1543,7 +1543,7 @@ >>> > IXGBE_TX_LOCK(txr); >>> > ixgbe_txeof(txr); >>> > #ifdef IXGBE_LEGACY_TX >>> > - if (!IFQ_DRV_IS_EMPTY(ifp->if_snd)) >>> > + if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) >>> > ixgbe_start_locked(txr, ifp); >>> > #else >>> > if (!drbr_empty(ifp, txr->br)) >>> > @@ -2091,7 +2091,11 @@ >>> > (paused == 0)) >>> > ++hung; >>> > else if (txr->queue_status == IXGBE_QUEUE_WORKING) >>> > +#ifndef IXGBE_LEGACY_TX >>> > taskqueue_enqueue(que->tq, &txr->txq_task); >>> > +#else >>> > + taskqueue_enqueue(que->tq, &que->que_task); >>> > +#endif >>> > } >>> > /* Only truely watchdog if all queues show hung */ >>> > if (hung == adapter->num_queues) >>> > @@ -3327,10 +3331,6 @@ >>> > tx_buffer->map = NULL; >>> > } >>> > } >>> > -#ifdef IXGBE_LEGACY_TX >>> > - if (txr->br != NULL) >>> > - buf_ring_free(txr->br, M_DEVBUF); >>> > -#endif >>> > if (txr->tx_buffers != NULL) { >>> > free(txr->tx_buffers, M_DEVBUF); >>> > txr->tx_buffers = NULL; >>> > =================================================================== >>> > >>> > Using a stable/9 kernel with the above patch allowed me to load my PF >>> > ruleset on a machine with an ixgbe interface and ALTQ enabled. i.e. I >>> no >>> > longer received the "driver does not support altq error". Queueing on >>> the >>> > ix interface now appears to work as it should. >>> > >>> > I am hoping someone can help verify my work and perhaps audit and >>> correct >>> > the IXGBE_LEGACY_TX path currently in the svn tree. >>> > >>> > Also, FWIW, here is relevant pciconf output for the ixbge card. >>> > >>> > ix0@pci0:1:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 >>> rev=0x01 >>> > hdr=0x00 >>> > vendor = 'Intel Corporation' >>> > device = '82599EB 10-Gigabit SFI/SFP+ Network Connection' >>> > class = network >>> > subclass = ethernet >>> > cap 01[40] = powerspec 3 supports D0 D3 current D0 >>> > cap 05[50] = MSI supports 1 message, 64 bit, vector masks >>> > cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled >>> > cap 10[a0] = PCI-Express 2 endpoint max data 128(512) link x8(x8) >>> > ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected >>> > ecap 0003[140] = Serial 1 0023faffff300715 >>> > ecap 000e[150] = unknown 1 >>> > ecap 0010[160] = unknown 1 >>> > ix1@pci0:1:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 >>> rev=0x01 >>> > hdr=0x00 >>> > vendor = 'Intel Corporation' >>> > device = '82599EB 10-Gigabit SFI/SFP+ Network Connection' >>> > class = network >>> > subclass = ethernet >>> > cap 01[40] = powerspec 3 supports D0 D3 current D0 >>> > cap 05[50] = MSI supports 1 message, 64 bit, vector masks >>> > cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled >>> > cap 10[a0] = PCI-Express 2 endpoint max data 128(512) link x8(x8) >>> > ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected >>> > ecap 0003[140] = Serial 1 0023faffff300715 >>> > ecap 000e[150] = unknown 1 >>> > ecap 0010[160] = unknown 1 >>> > >>> > Thanks! >>> > >>> > -Nick >>> > _______________________________________________ >>> > freebsd-net@freebsd.org mailing list >>> > http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> >> > From owner-freebsd-net@FreeBSD.ORG Wed Oct 1 20:27:24 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08A86F6; Wed, 1 Oct 2014 20:27:24 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id BCEAB1C3; Wed, 1 Oct 2014 20:27:23 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 43E2E7300A; Wed, 1 Oct 2014 22:32:23 +0200 (CEST) Date: Wed, 1 Oct 2014 22:32:23 +0200 From: Luigi Rizzo To: Adrian Chadd , "freebsd-net@freebsd.org" , "Alexander V. Chernikov" , Elof Ofel , jfvogel@gmail.com Subject: Re: individual queue blocking entire rx unit on ixgbe (Re: How do I balance bandwidth over several virtual NICs?) Message-ID: <20141001203223.GA12122@onelab2.iet.unipi.it> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Oct 2014 20:27:24 -0000 On Wed, Oct 01, 2014 at 10:37:35AM -0700, Adrian Chadd wrote: > Hi, > > Try this on -HEAD. There were some recent fixes to ixgbe that haven't > been RFCed. I don't have a way to test this on HEAD. Do you know if there is any change that could be related ? On 10.1 beta 3 I noticed is that when I open a single queue on an ixgbe (and with incoming traffic), the rx unit stalls no matter what the previous state of dev.ix.*.fc (i.e. the DROP_EN bits) or QDE are. In this state, toggling DROP_EN has no effect, whereas something that seems effective is setting the QDE bit(s) in the PFQDE register for all queues, _after_ i open the device. >From the above my take is the following: - on NIC reset, the SRRCTL register starts at 0 including DROP_EN; same goes for PFQDE.QDE - setting SRRCTL.DROP_EN must happen before the receive unit is started; - conversely, toggling PFQDE.QDE has effect even when the receive unit has started - sysctl dev.ix.*.fc sets/clear DROP_EN but at the wrong time (the right time seems to be the window between reset and start) I am going to run more tests to figure out. cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Oct 1 21:15:57 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 037D74C6; Wed, 1 Oct 2014 21:15:57 +0000 (UTC) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 13F55AD6; Wed, 1 Oct 2014 21:15:55 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id z11so1095411lbi.41 for ; Wed, 01 Oct 2014 14:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=DJpZfu1yTveOa0uaYljaIJaMmnEIyA3W6dw0O7qqb1Q=; b=RYmSHryKAHuKwTOjhiGMQXQCmIG2+u/bvWi/az0VXwY7/GmdibzlaccNojwxUUsAD7 V0MAIF6Hehp4nZo5rYCR+OBi3FyQn0YGT22X2evBAoOiWOltX165T6UiDIi33jcCc+Ux 7pvSdjKWwMsBUrUOa+u39+WpwTIrR5rvoTQKo7VFDKvPZvYECmjo9G8gNG1Q/OOx+oou 8XvUy4fRD837836S05X6cmK4+/QNxr9tHkiePVG3cmpH/qfddT+bHybnaM3gSXDhxtwQ tdBLS8Z/XzZZ/a2TkVRlHfwMdKX9SiVdaBQTu1WknHsa3S3r+efCjsZtX1fhC8BHqlj1 Wajg== MIME-Version: 1.0 X-Received: by 10.112.12.5 with SMTP id u5mr8173090lbb.87.1412198153894; Wed, 01 Oct 2014 14:15:53 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.26.37 with HTTP; Wed, 1 Oct 2014 14:15:53 -0700 (PDT) In-Reply-To: <2FAAD083-7EAF-4E5F-A3D5-0AFB08C4ED9D@westryn.net> References: <2FAAD083-7EAF-4E5F-A3D5-0AFB08C4ED9D@westryn.net> Date: Wed, 1 Oct 2014 23:15:53 +0200 X-Google-Sender-Auth: Onhbc4lw0XEFl14E1c5pHrx7MRQ Message-ID: Subject: Re: individual queue blocking entire rx unit on ixgbe (Re: How do I balance bandwidth over several virtual NICs?) From: Luigi Rizzo To: Kim Shrier Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Adrian Chadd , Elof Ofel , "Alexander V. Chernikov" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Oct 2014 21:15:57 -0000 On Wed, Oct 1, 2014 at 11:12 PM, Kim Shrier wrote: > Not sure if this is related. I was testing on 10.1 beta3 and I was copyi= ng > approximately 250 GB of data to the test machine, I noticed that the > network would periodically slow down to about 4 mbits/sec or it would > pause for about 20 seconds and then continue at full speed. > > The ethernet interface on the test machine is: > > bge0: 0x57766001> mem 0xa0400000-0xa040ffff,0xa0410000-0xa041ffff irq 16 at > device 0.0 on pci1 > bge0: CHIP ID 0x57766001; ASIC REV 0x57766; CHIP REV 0x577660; PCI-E > =E2=80=8Bno that seems totally unrelated to this thread. We are talking specifically about the ixgbe / 82599 cheers luigi =E2=80=8B > > > The machine I am transferring from is using the em0 interface: > > em0: port 0xdc00-0xdc1f mem > 0xfb5e0000-0xfb5fffff,0xfb5dc000-0xfb5dffff irq 16 at device 0.0 on pci2 > > > I haven=E2=80=99t noticed any slow down when transferring between machine= s where > both sides are using the em driver. > > During the slow downs and pauses, when I had a top command running, > the process state would show up as =E2=80=9Cdp->dp=E2=80=9D or =E2=80=9Cr= l->l_=E2=80=9D instead of > something > normal like =E2=80=9Cselect=E2=80=9D or CPUn. > > If this is related, then maybe the problem is somewhere other than the > device > driver. > > Kim > > On Oct 1, 2014, at 3:48 AM, Luigi Rizzo wrote: > > > reviving this thread: > > > > i am just running experiments on 10.1 beta3 and even > > setting dev.ix.*.fc=3D0 and flipping the interface up and down > > does not seem to help: if i read only from a subset of the > > queues, the entire rx unit stalls eventually. > > > > I need to drain all queues to keep moving. > > > > Just tested this with 8 instances of netmap-ipfw running > > on an 8-core machine (8 queues enabled). > > > > netmap-ipfw netmap:ix0-0 netmap:ix1-0 > > netmap-ipfw netmap:ix0-1 netmap:ix1-1 > > ... > > > > and the source on another box is blasting on multiple queues with > > > > pkt-gen -f tx -i ix0 -d 10.0.10.0-10.0.10.255 > > > > > > I going to look at the driver's code now to see if/how > > this issue can be addressed. > > > > cheers > > luigi > > > > > > On Tue, Sep 23, 2014 at 6:00 PM, Adrian Chadd > wrote: > > > >> Ah, this behaviour. > >> > >> It's called DROP_EN on the intel igb / ixgbe hardware. Grep the > >> drivers for that particular register bit/setting. > >> > >> Set that bit for an RX queue and it'll instruct the MAC to drop frames > >> destined if that RX ring is full to it and keep receiving on the other > >> rings. Otherwise yes, receiving on that ring with the ring full cuases > >> the MAC to stop receiving on all rings until that ring has free space. > >> > >> You flip this on with ixgbe and igb by disabling tx/rx flowcontrol > >> (sysctl dev.ix|igb.X.fc=3D0) before configuring the interface. > >> > >> > >> > >> -a > >> > > > > > > > > -- > > -----------------------------------------+-----------------------------= -- > > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > > TEL +39-050-2211611 . via Diotisalvi 2 > > Mobile +39-338-6809875 . 56122 PISA (Italy) > > -----------------------------------------+-----------------------------= -- > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > --=20 -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Wed Oct 1 21:21:02 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07145631; Wed, 1 Oct 2014 21:21:02 +0000 (UTC) Received: from mail.westryn.net (mail.westryn.net [199.48.135.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C5CF0B56; Wed, 1 Oct 2014 21:21:01 +0000 (UTC) Received: from sneffels.westryn.net (225x169.ouraynet.com [204.16.225.169]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.westryn.net (Postfix) with ESMTPSA id 0C8319432A1; Wed, 1 Oct 2014 15:13:54 -0600 (MDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: individual queue blocking entire rx unit on ixgbe (Re: How do I balance bandwidth over several virtual NICs?) From: Kim Shrier In-Reply-To: Date: Wed, 1 Oct 2014 15:12:30 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2FAAD083-7EAF-4E5F-A3D5-0AFB08C4ED9D@westryn.net> References: To: Luigi Rizzo X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-net@freebsd.org" , Adrian Chadd , Elof Ofel , "Alexander V. Chernikov" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Oct 2014 21:21:02 -0000 Not sure if this is related. I was testing on 10.1 beta3 and I was = copying approximately 250 GB of data to the test machine, I noticed that the network would periodically slow down to about 4 mbits/sec or it would pause for about 20 seconds and then continue at full speed. The ethernet interface on the test machine is: bge0: mem 0xa0400000-0xa040ffff,0xa0410000-0xa041ffff irq 16 at = device 0.0 on pci1 bge0: CHIP ID 0x57766001; ASIC REV 0x57766; CHIP REV 0x577660; PCI-E The machine I am transferring from is using the em0 interface: em0: port 0xdc00-0xdc1f mem = 0xfb5e0000-0xfb5fffff,0xfb5dc000-0xfb5dffff irq 16 at device 0.0 on pci2 I haven=92t noticed any slow down when transferring between machines = where both sides are using the em driver. During the slow downs and pauses, when I had a top command running, the process state would show up as =93dp->dp=94 or =93rl->l_=94 instead = of something normal like =93select=94 or CPUn. If this is related, then maybe the problem is somewhere other than the = device driver. Kim On Oct 1, 2014, at 3:48 AM, Luigi Rizzo wrote: > reviving this thread: >=20 > i am just running experiments on 10.1 beta3 and even > setting dev.ix.*.fc=3D0 and flipping the interface up and down > does not seem to help: if i read only from a subset of the > queues, the entire rx unit stalls eventually. >=20 > I need to drain all queues to keep moving. >=20 > Just tested this with 8 instances of netmap-ipfw running > on an 8-core machine (8 queues enabled). >=20 > netmap-ipfw netmap:ix0-0 netmap:ix1-0 > netmap-ipfw netmap:ix0-1 netmap:ix1-1 > ... >=20 > and the source on another box is blasting on multiple queues with >=20 > pkt-gen -f tx -i ix0 -d 10.0.10.0-10.0.10.255 >=20 >=20 > I going to look at the driver's code now to see if/how > this issue can be addressed. >=20 > cheers > luigi >=20 >=20 > On Tue, Sep 23, 2014 at 6:00 PM, Adrian Chadd = wrote: >=20 >> Ah, this behaviour. >>=20 >> It's called DROP_EN on the intel igb / ixgbe hardware. Grep the >> drivers for that particular register bit/setting. >>=20 >> Set that bit for an RX queue and it'll instruct the MAC to drop = frames >> destined if that RX ring is full to it and keep receiving on the = other >> rings. Otherwise yes, receiving on that ring with the ring full = cuases >> the MAC to stop receiving on all rings until that ring has free = space. >>=20 >> You flip this on with ixgbe and igb by disabling tx/rx flowcontrol >> (sysctl dev.ix|igb.X.fc=3D0) before configuring the interface. >>=20 >>=20 >>=20 >> -a >>=20 >=20 >=20 >=20 > --=20 > = -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. = dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2211611 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > = -----------------------------------------+------------------------------- > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Oct 1 23:02:51 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8FEFF984; Wed, 1 Oct 2014 23:02:51 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 4FF67BC2; Wed, 1 Oct 2014 23:02:51 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id F35FF73027; Thu, 2 Oct 2014 01:07:53 +0200 (CEST) Date: Thu, 2 Oct 2014 01:07:53 +0200 From: Luigi Rizzo To: Adrian Chadd , "freebsd-net@freebsd.org" , "Alexander V. Chernikov" , Elof Ofel , jfvogel@gmail.com Subject: bug confirmed: Re: individual queue blocking entire rx unit on ixgbe (Re: How do I balance bandwidth over several virtual NICs?) Message-ID: <20141001230753.GA13187@onelab2.iet.unipi.it> References: <20141001203223.GA12122@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141001203223.GA12122@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Oct 2014 23:02:51 -0000 On Wed, Oct 01, 2014 at 10:32:23PM +0200, Luigi Rizzo wrote: > On Wed, Oct 01, 2014 at 10:37:35AM -0700, Adrian Chadd wrote: > > Hi, > > > > Try this on -HEAD. There were some recent fixes to ixgbe that haven't > > been RFCed. > > I don't have a way to test this on HEAD. > > Do you know if there is any change that could be related ? > > On 10.1 beta 3 I noticed is that when I open a single queue on an ixgbe > (and with incoming traffic), the rx unit stalls no matter what the > previous state of dev.ix.*.fc (i.e. the DROP_EN bits) or QDE are. > > In this state, toggling DROP_EN has no effect, whereas something that seems > effective is setting the QDE bit(s) in the PFQDE register for all queues, > _after_ i open the device. > > >From the above my take is the following: > > - on NIC reset, the SRRCTL register starts at 0 including DROP_EN; > same goes for PFQDE.QDE > > - setting SRRCTL.DROP_EN must happen before the receive unit is started; > > - conversely, toggling PFQDE.QDE has effect even when the receive > unit has started > > - sysctl dev.ix.*.fc sets/clear DROP_EN but at the wrong time > (the right time seems to be the window between reset and start) > > I am going to run more tests to figure out. ok i can confirm that SRRCTL.DROP_EN behaves as i described above, and so it should be set in ixgbe_initialize_receive_units() . The patch below shows that DROP_EN is cleared when the NIC is reset, and sets it according to the flow control setting. To replicate exactly the logic for flow control we might even try to check whether there is more than 1 queue. Also the previous code that modifies DROP_EN can be probably removed because it is ineffective. cheers luigi --- /home/luigi/FreeBSD/R10/sys/dev/ixgbe/ixgbe.c 2014-08-21 01:29:41.0000 00000 +0200 +++ ixgbe.c 2014-10-02 00:38:00.000000000 +0200 @@ -4187,6 +4192,17 @@ ixgbe_initialize_receive_units(struct ad /* Set up the SRRCTL register */ srrctl = IXGBE_READ_REG(hw, IXGBE_SRRCTL(i)); +{ + printf("--- queue %d DROP_EN is %d\n", + i, (srrctl & IXGBE_SRRCTL_DROP_EN) ? 1 : 0); + if (adapter->hw.fc.requested_mode == ixgbe_fc_none) { + srrctl |= IXGBE_SRRCTL_DROP_EN; + } else { + srrctl &= ~IXGBE_SRRCTL_DROP_EN; + } + printf("--- queue %d DROP_EN becomes %d\n", + i, (srrctl & IXGBE_SRRCTL_DROP_EN) ? 1 : 0); +} srrctl &= ~IXGBE_SRRCTL_BSIZEHDR_MASK; srrctl &= ~IXGBE_SRRCTL_BSIZEPKT_MASK; srrctl |= bufsz; From owner-freebsd-net@FreeBSD.ORG Wed Oct 1 23:43:00 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF64EAA; Wed, 1 Oct 2014 23:43:00 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 23253F66; Wed, 1 Oct 2014 23:42:59 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hi2so2354727wib.2 for ; Wed, 01 Oct 2014 16:42:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=C+hWzG4UySqQhfCZKFDCUNALs+0VxZ793D7vj8IMRXc=; b=FC8mt2zYdIQAdIJN2OCrXg55D1WtvFhQl/ipwFK9hWY0JM+O/uXb7fe66nVz9Ta+Z+ pc6NFSz7tH5GslW+oKJGYehL8XZ4hbZeGzNWSv453VevZzrW1m/YS1Ee7qX332MlFdV+ SIDTM13NzrS3nHfsX9qD7J4EFbJlUWiwWLNXL7tjJNlAoMTLaRXtL5ox3crICQFIaY95 /uhsSBG+2b7Rnqpu2p8ymH103qoy8Y+e1AwLYOihRgKXD5kaWRC84dsULSLpFnRly6bL opLrpg045MFjqMP+8DiKF7UsFl8lWXHM1g03gtnUPW06yMgVBM383x64LMKn82Y/zUBi 5W0w== MIME-Version: 1.0 X-Received: by 10.194.177.226 with SMTP id ct2mr66138770wjc.20.1412206978491; Wed, 01 Oct 2014 16:42:58 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Wed, 1 Oct 2014 16:42:58 -0700 (PDT) In-Reply-To: <20141001203223.GA12122@onelab2.iet.unipi.it> References: <20141001203223.GA12122@onelab2.iet.unipi.it> Date: Wed, 1 Oct 2014 16:42:58 -0700 X-Google-Sender-Auth: uoCBSG_2AeebOxFk7XUYAWSBmSI Message-ID: Subject: Re: individual queue blocking entire rx unit on ixgbe (Re: How do I balance bandwidth over several virtual NICs?) From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" , Elof Ofel , "Alexander V. Chernikov" , Jack Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Oct 2014 23:43:00 -0000 Yeah, just grab the diffs that I committed to ixgbe and try it out. The flowdirector initialisation is buggy. :) -a From owner-freebsd-net@FreeBSD.ORG Wed Oct 1 23:43:40 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E38AC14B for ; Wed, 1 Oct 2014 23:43:40 +0000 (UTC) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C068CF76 for ; Wed, 1 Oct 2014 23:43:40 +0000 (UTC) Received: from [10.149.128.203] (unknown [166.205.66.120]) by oj.bangj.com (Postfix) with ESMTPA id 5D0F11451; Wed, 1 Oct 2014 19:34:03 -0400 (EDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2DA609BE-5704-463A-99BB-E64CB71931B2@bangj.com> X-Mailer: iPhone Mail (12A405) From: Tom Pusateri Subject: Re: UDP/IPv6 handling Date: Wed, 1 Oct 2014 19:34:04 -0400 To: Michael Tuexen Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Oct 2014 23:43:41 -0000 Lots of embedded devices (like Cisco IP Phones) send TFTP requests with 0 ch= ecksums.=20 Tom > On Oct 1, 2014, at 12:58 PM, Michael Tuexen wrote: >=20 > Dear all, >=20 > in udp6_input() we have the following code: >=20 > if (nxt =3D=3D IPPROTO_UDP && plen !=3D ulen) { > UDPSTAT_INC(udps_badlen); > goto badunlocked; > }=20 > /* > * Checksum extended UDP header and data. > */ > if (uh->uh_sum =3D=3D 0) { > if (ulen > plen || ulen < sizeof(struct udphdr)) { > UDPSTAT_INC(udps_nosum); > goto badunlocked; > } > } >=20 > I'm trying to understand the UDP code path... >=20 > So (ulen > plen) can't be true. I'm wondering why do we only check the ule= n is not too > short only in the case when the UDP checksum is zero. A zero checksum shou= ld also never happen. >=20 > I think we should check for ulen < sizeof(struct udphdr) in any case. >=20 > Opinions? >=20 > Best regards > Michael > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Oct 1 23:44:23 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E916A1E1; Wed, 1 Oct 2014 23:44:23 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id A7B13F85; Wed, 1 Oct 2014 23:44:23 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 03A8D7300A; Thu, 2 Oct 2014 01:49:27 +0200 (CEST) Date: Thu, 2 Oct 2014 01:49:27 +0200 From: Luigi Rizzo To: Adrian Chadd Subject: Re: individual queue blocking entire rx unit on ixgbe (Re: How do I balance bandwidth over several virtual NICs?) Message-ID: <20141001234926.GC13187@onelab2.iet.unipi.it> References: <20141001203223.GA12122@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "freebsd-net@freebsd.org" , Elof Ofel , "Alexander V. Chernikov" , Jack Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Oct 2014 23:44:24 -0000 On Wed, Oct 01, 2014 at 04:42:58PM -0700, Adrian Chadd wrote: > Yeah, just grab the diffs that I committed to ixgbe and try it out. > > The flowdirector initialisation is buggy. :) ok but i don't think it is related, see my previous email. luigi From owner-freebsd-net@FreeBSD.ORG Wed Oct 1 23:47:34 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 753822BF; Wed, 1 Oct 2014 23:47:34 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DC569FAF; Wed, 1 Oct 2014 23:47:33 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id bs8so2307991wib.0 for ; Wed, 01 Oct 2014 16:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HR/rZuDVCjqHi4Mwu50lHk156X5rWFPOPxomvX5HGt8=; b=w4O6hg30Mp8E3dKdLGAR2Zgt0ah9vVgVQeXbOfyI9Ka6lW/4fxKyJWRnYx0PPAGYiX 3OmS4Uy6PVg2Ngg/7BV/I6oNDjtU0GJ5Yx0a5uvrm3Uj9+MlIR1UgYj/z7/Rftu8JfZx 2QCrKut5J4gct9sHpopk4j7PrpWuWevPGzrnQSz7aEgmv6RSYpDPptneS4KB+UmS0MJN uIyPmI0bjUP+BfKDndACjorjQjtm6LMhNY2pNRvN7D6gO0sGWKSVO8S6rRDQvQ0lKLGc TWchHGQHS7RkgpBp2GpYZ057w5ISNV4Z4rQtigtVC6n/cpbf+VmvK41Q2aveBmKAJqCf W0Lw== MIME-Version: 1.0 X-Received: by 10.194.157.230 with SMTP id wp6mr50234852wjb.15.1412207252215; Wed, 01 Oct 2014 16:47:32 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Wed, 1 Oct 2014 16:47:32 -0700 (PDT) In-Reply-To: <20141001234926.GC13187@onelab2.iet.unipi.it> References: <20141001203223.GA12122@onelab2.iet.unipi.it> <20141001234926.GC13187@onelab2.iet.unipi.it> Date: Wed, 1 Oct 2014 16:47:32 -0700 X-Google-Sender-Auth: 3nUPS6UWp-zt8XhXxXQHUAkt1WI Message-ID: Subject: Re: individual queue blocking entire rx unit on ixgbe (Re: How do I balance bandwidth over several virtual NICs?) From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" , Elof Ofel , "Alexander V. Chernikov" , Jack Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Oct 2014 23:47:34 -0000 On 1 October 2014 16:49, Luigi Rizzo wrote: > On Wed, Oct 01, 2014 at 04:42:58PM -0700, Adrian Chadd wrote: >> Yeah, just grab the diffs that I committed to ixgbe and try it out. >> >> The flowdirector initialisation is buggy. :) > > ok but i don't think it is related, see my previous email. I saw - but the verisign people also saw queue stalls as well. So is setting DROP_EN unconditionally fixing it for you? -a From owner-freebsd-net@FreeBSD.ORG Wed Oct 1 23:48:08 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C172B355; Wed, 1 Oct 2014 23:48:08 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 7DF6BFBB; Wed, 1 Oct 2014 23:48:08 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 20E1D7300B; Thu, 2 Oct 2014 01:53:12 +0200 (CEST) Date: Thu, 2 Oct 2014 01:53:12 +0200 From: Luigi Rizzo To: Adrian Chadd Subject: Re: individual queue blocking entire rx unit on ixgbe (Re: How do I balance bandwidth over several virtual NICs?) Message-ID: <20141001235312.GA14593@onelab2.iet.unipi.it> References: <20141001203223.GA12122@onelab2.iet.unipi.it> <20141001234926.GC13187@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "freebsd-net@freebsd.org" , Elof Ofel , "Alexander V. Chernikov" , Jack Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Oct 2014 23:48:08 -0000 On Wed, Oct 01, 2014 at 04:47:32PM -0700, Adrian Chadd wrote: > On 1 October 2014 16:49, Luigi Rizzo wrote: > > On Wed, Oct 01, 2014 at 04:42:58PM -0700, Adrian Chadd wrote: > >> Yeah, just grab the diffs that I committed to ixgbe and try it out. > >> > >> The flowdirector initialisation is buggy. :) > > > > ok but i don't think it is related, see my previous email. > > I saw - but the verisign people also saw queue stalls as well. > > So is setting DROP_EN unconditionally fixing it for you? yes so it seems. From owner-freebsd-net@FreeBSD.ORG Wed Oct 1 23:53:50 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 116A8428; Wed, 1 Oct 2014 23:53:50 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 73C7DF1; Wed, 1 Oct 2014 23:53:49 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id n3so2276919wiv.11 for ; Wed, 01 Oct 2014 16:53:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4yH8cX+DmN6rHeCJLapCjAiUe20ulW/7vpXowvU5Gmw=; b=ForhODKcqpC7ibnjQ0n9iK07vd1Sng27eAomy4VRuQ5gpPfKEhB/QUP++pMCzMnpqB p1XgDsa02Zy7a5yuGlBDczu3KENGiRbyHn+2TmzVafn5Y1S4l6XeOAqBiwtG8DAzQzVD JpwK1ukzNNNvcYlB4aa12t/pM3gyGCtTgfl2c+4WbL+BBiSlh+h++xeN7F647D5OV8iU uyAMFD7vTWSJ9KoBlRYebpGT9Poi3XOwVbnT22ph9f7Kr47E/0Et2jJlbCqgn2mkgod2 Sp7tXogDnCU7Jlw9b21jUBBFd0YZX+rigiIOjQiHo1eTXsdc1U2EVYfarjZKAkYDNDy3 e2uA== MIME-Version: 1.0 X-Received: by 10.180.107.100 with SMTP id hb4mr397351wib.59.1412207627783; Wed, 01 Oct 2014 16:53:47 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Wed, 1 Oct 2014 16:53:47 -0700 (PDT) In-Reply-To: <20141001235312.GA14593@onelab2.iet.unipi.it> References: <20141001203223.GA12122@onelab2.iet.unipi.it> <20141001234926.GC13187@onelab2.iet.unipi.it> <20141001235312.GA14593@onelab2.iet.unipi.it> Date: Wed, 1 Oct 2014 16:53:47 -0700 X-Google-Sender-Auth: iZtP7aHMxEGuCVgIFRVeZXRnpm0 Message-ID: Subject: Re: individual queue blocking entire rx unit on ixgbe (Re: How do I balance bandwidth over several virtual NICs?) From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" , Elof Ofel , "Alexander V. Chernikov" , Jack Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Oct 2014 23:53:50 -0000 On 1 October 2014 16:53, Luigi Rizzo wrote: > On Wed, Oct 01, 2014 at 04:47:32PM -0700, Adrian Chadd wrote: >> On 1 October 2014 16:49, Luigi Rizzo wrote: >> > On Wed, Oct 01, 2014 at 04:42:58PM -0700, Adrian Chadd wrote: >> >> Yeah, just grab the diffs that I committed to ixgbe and try it out. >> >> >> >> The flowdirector initialisation is buggy. :) >> > >> > ok but i don't think it is related, see my previous email. >> >> I saw - but the verisign people also saw queue stalls as well. >> >> So is setting DROP_EN unconditionally fixing it for you? > > yes so it seems. Interesting. That's a pretty small window to get it wrong in. Would you file a PR about it? We'll try to get this fixed soon. (Same for igb..) Thanks! -a From owner-freebsd-net@FreeBSD.ORG Thu Oct 2 03:51:33 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00F4A1AE for ; Thu, 2 Oct 2014 03:51:32 +0000 (UTC) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C05C5C3B for ; Thu, 2 Oct 2014 03:51:32 +0000 (UTC) Received: by mail-ig0-f169.google.com with SMTP id uq10so1264422igb.4 for ; Wed, 01 Oct 2014 20:51:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=hpOkYu6ULHvkgqs702XMiYXyVc79+6l4xCcG5v4s+mc=; b=ZY8jLDyLLWTZdLXl77aA7v+zpk9ODKM1KRbb2k6V6kogT2+h8lyMU01CNra0H+zoFR 73R2NDBqNbC/Y+WiqS6LTbQxo0SEWda3xCOAGntJ0psfjhQysUmJg8/ESB7J1Q2HFUvw WZqNhaFTNM4SdWp10uDLhzCrJkMhz/++nMJ9nV2oQ2LpDMDejvQNEsKaS4ym6vxVB88G /TCx7RnMaw+z+7B9kKku6l0ZbgrhrxvXUhgl+95v2QBXQQF/WuBJogTN6wBSNlfgwSiC KjUqBkRNR28o6WVWeQcmF2XmNwj3vahMfW8Rk4trNO1dAtc5xxQD9LjCYnohOOS7aEeE W0Wg== X-Gm-Message-State: ALoCoQlKHPRQX9Z163MuSEeMYMNgGAGPNU3V5g4j0vjs8UEX+8uBvmoISFTyq6awoIabUWk//Av/ X-Received: by 10.42.227.10 with SMTP id iy10mr1695433icb.3.1412221886102; Wed, 01 Oct 2014 20:51:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.19.30 with HTTP; Wed, 1 Oct 2014 20:51:06 -0700 (PDT) X-Originating-IP: [72.177.8.109] In-Reply-To: References: From: Bryan Venteicher Date: Wed, 1 Oct 2014 22:51:06 -0500 Message-ID: Subject: Re: UDP/IPv6 handling To: Michael Tuexen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Oct 2014 03:51:33 -0000 On Wed, Oct 1, 2014 at 11:58 AM, Michael Tuexen < Michael.Tuexen@lurchi.franken.de> wrote: > Dear all, > > in udp6_input() we have the following code: > > if (nxt =3D=3D IPPROTO_UDP && plen !=3D ulen) { > UDPSTAT_INC(udps_badlen); > goto badunlocked; > } > /* > * Checksum extended UDP header and data. > */ > if (uh->uh_sum =3D=3D 0) { > if (ulen > plen || ulen < sizeof(struct udphdr)) { > UDPSTAT_INC(udps_nosum); > goto badunlocked; > } > } > > I'm trying to understand the UDP code path... > > =E2=80=8BI too was recently confused by this code. =E2=80=8BI pointed out o= ne issue to kevlo@ recently, but it still kind of seemed like the UDP-Lite was mismerged to IPv6. So (ulen > plen) can't be true. I'm wondering why do we only check the ulen > is not too > short only in the case when the UDP checksum is zero. A zero checksum > should also never happen. > > =E2=80=8BI hope to have a patch for =E2=80=8BRFC6935 [1] soon so a zero che= cksum may be allowed if the inp/udpcb is configured for it. I think we should check for ulen < sizeof(struct udphdr) in any case. > > =E2=80=8BI think previously, the checks in ip6_input(), IP6_EXTHDR_CHECK(),= and plen =3D=3D ulen made this unnecessary. I think we'd want to do it for UDP-= Lite if ulen was not initially zero. =E2=80=8B[1] - http://tools.ietf.org/html/rfc6935=E2=80=8B > Opinions? > > Best regards > Michael > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Oct 2 05:16:14 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26BA6E13 for ; Thu, 2 Oct 2014 05:16:14 +0000 (UTC) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EB8C0383 for ; Thu, 2 Oct 2014 05:16:13 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id fb1so1607842pad.11 for ; Wed, 01 Oct 2014 22:16:13 -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:in-reply-to:user-agent; bh=TCR8ETaBGIYwfxwW5txo2EPxppG6hXIdKO3QlMOIRZk=; b=Q36lJiU9g1OshQ87UFkbN2GBxuDnx8g3LMjxJxhxFd+hrESs3oRK0/bzSqX0nMH97W yZIbutyqYe/GS0Z4CSfc0P+8AI4KB72oQZk2BY9bije3U6VOeROI2Zs8NhhqtoRv1yG/ De9ATY98tW8wC+W2Ik9cMWAAc3qokFGob1Ij/R9lLNu23qAPcjkNA0eZbAAjAtC6avkc df+jUPBmL5lSC6m+wSM3bZWQZng+AOC0jk47CU0rbt3RIK1owLY0D1gfPRz1diQ2JPrq RrIMAZVBROHzR8UDsBJS52K31atET1O+HZ5+j+5VuPMJC86o9Zowi1atsTugKjPVDCOv FAvA== X-Received: by 10.66.146.134 with SMTP id tc6mr23807433pab.120.1412226973534; Wed, 01 Oct 2014 22:16:13 -0700 (PDT) Received: from pyunyh@gmail.com ([106.247.248.2]) by mx.google.com with ESMTPSA id ix1sm2381997pbc.60.2014.10.01.22.16.09 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 01 Oct 2014 22:16:12 -0700 (PDT) From: Yonghyeon PYUN X-Google-Original-From: "Yonghyeon PYUN" Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 02 Oct 2014 14:16:01 +0900 Date: Thu, 2 Oct 2014 14:16:01 +0900 To: Nils Beyer Subject: Re: [CFT] alc(4) QAC AR816x/AR817x ethernet controller support Message-ID: <20141002051601.GB964@michelle.fasterthan.com> Reply-To: pyunyh@gmail.com References: <20140930015741.GA2451@michelle.fasterthan.com> <20140930082053.4D9EFF8F@hub.freebsd.org> <20140930085228.GB969@michelle.fasterthan.com> <20140930093516.80A8943F@hub.freebsd.org> <20141001003954.GA2632@michelle.fasterthan.com> <20141001091521.9F867F96@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141001091521.9F867F96@hub.freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Oct 2014 05:16:14 -0000 On Wed, Oct 01, 2014 at 11:14:59AM +0200, Nils Beyer wrote: > Hi, > > Yonghyeon PYUN wrote: > > Default interrupt moderation policy is targeted to reduce latency > > so it will generate up to 10k interrupts/sec under high network > > load. If you want to reduce number of interrupts/sec, tune > > interrupt moderation sysctl variables mentioned in alc(4). > > Tried several values here: > > dev.alc.0.int_rx_mod={1000,10000,100000} > dev.alc.0.int_tx_mod={1000,10000,100000} > > but didn't notice any changes neither in CPU usage nor throughput during the > "iperf" test; "kernel{alc0 taskq}" stays at 70-75%. I've downed/upped the > interface "alc0" after every change. > You may see difference when H/W handles tiny grams(i.e. 64 bytes UDP frames). For bulk TCP/UDP transfers, alc(4) can easily saturate the link. > A simple iSCSI test using the native CTL interface works really well. A "fio" > test results in 100MB/s read and write. Double-checking using "netstat -I" > confirms gigabit-line speeds at around 120MB/s. > CPU usage at "kernel{alc0 taskq}" is as high as in the "iperf" test. So I think > that's a limitation of the AR8161 chip. > > > > Updated the diff to address link establishment issue. > > http://people.freebsd.org/~yongari/alc/pci.quirk.diff > > http://people.freebsd.org/~yongari/alc/alc.diff.20141001 > > Confirmed; with the anti-hibernation patch, link estalishment is now working > flawlessly. > > Thank you very much for your work... Thanks for your testing. Patch updated again to fix wrong lock assertion. http://people.freebsd.org/~yongari/alc/alc.diff.20141002 From owner-freebsd-net@FreeBSD.ORG Thu Oct 2 07:22:50 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB616BD3; Thu, 2 Oct 2014 07:22:50 +0000 (UTC) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3BFA32D5; Thu, 2 Oct 2014 07:22:50 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id b6so1740806lbj.17 for ; Thu, 02 Oct 2014 00:22:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8P41heY1rWywEr3a4aAQB+EFXJr8nKnSl60GYy3BEdY=; b=W9vtuzmy2CbgG8YumiuV6/a+mCacW4guF/k1KcWtfMu45B7q1Je9T2ZvsjSvrlDbwT eoGXYSiHRCz+AGCRfsAqUK9eQQJuCLnkoxg4E4P3MpCQc0p+392dfIfFWudhA+9NTnjU RzAwEWiSFseHCDSC6bHtCJsCKnE7Jc+ZuP1B8gAXmpt6Ui1+QFCpz7hVeJw5YhpaxNR7 DjxUj3ZKNa8cNYmJpD5IhEil7mDSO9gpQ8FlionhyoT/u9jVQYeO1x0nnsW4pJ+8KACL OSjWWIuJ+HD6KIoIf2eZPnryTYlOjhhAKQ/n/ID3lalSJGTD12SRwPZ7LbPgme5BBpDE zheQ== MIME-Version: 1.0 X-Received: by 10.152.9.200 with SMTP id c8mr62011697lab.76.1412234568233; Thu, 02 Oct 2014 00:22:48 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.25.28.146 with HTTP; Thu, 2 Oct 2014 00:22:48 -0700 (PDT) In-Reply-To: References: Date: Thu, 2 Oct 2014 09:22:48 +0200 X-Google-Sender-Auth: oyDNgABDZFObcn-PNfGtzqjzc7Q Message-ID: Subject: Re: [Bug 193053] ixgbe(4) IXGBE_LEGACY_TX + ALTQ path broken From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= To: bugzilla-noreply@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Oct 2014 07:22:51 -0000 In pfSense the driver has been modified to compile a hybrid mode. Meaning have activated both LEGACY and new transmit queue model. It works correctly and avoids the problems of recompiling with ALTQ. It also solves the problem on having performance impacts when ALTQ is not in use. There are even some drivers in the tree that do this by default already. >From my analysis there should not be an LEGACY define but just mask all of this behind ALTQ definition if needed. On Wed, Oct 1, 2014 at 8:28 PM, wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053 > > --- Comment #9 from ncrogers@gmail.com --- > Any chance we can get some kind of resolution on this before 10.1? It seems > like simply upgrading the ixgbe driver with the latest from Intel fixes the > problem. If that is not possible, the changes in the patch I posted are > still > working for me in production > > -- > You are receiving this mail because: > You are the assignee for the bug. > _______________________________________________ > 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" > -- Ermal From owner-freebsd-net@FreeBSD.ORG Thu Oct 2 07:23:10 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 383C6C68 for ; Thu, 2 Oct 2014 07:23:10 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EF10C2E1 for ; Thu, 2 Oct 2014 07:23:09 +0000 (UTC) Received: from [10.225.7.42] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id BD3B21C10467C; Thu, 2 Oct 2014 09:23:05 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: UDP/IPv6 handling From: Michael Tuexen In-Reply-To: <2DA609BE-5704-463A-99BB-E64CB71931B2@bangj.com> Date: Thu, 2 Oct 2014 09:23:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <09E7673E-F6FD-48FA-B264-E0D79F5C281C@lurchi.franken.de> References: <2DA609BE-5704-463A-99BB-E64CB71931B2@bangj.com> To: Tom Pusateri X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Oct 2014 07:23:10 -0000 On 02 Oct 2014, at 01:34, Tom Pusateri wrote: > Lots of embedded devices (like Cisco IP Phones) send TFTP requests = with 0 checksums.=20 I guess this uses UDP/IPv4, where FreeBSD supports UDP with zero = checksum. For UDP/IPv6 this doesn't work. Right after the cited code, the checksum = is always checked... Best regards Michael >=20 > Tom >=20 >=20 >=20 >> On Oct 1, 2014, at 12:58 PM, Michael Tuexen = wrote: >>=20 >> Dear all, >>=20 >> in udp6_input() we have the following code: >>=20 >> if (nxt =3D=3D IPPROTO_UDP && plen !=3D ulen) { >> UDPSTAT_INC(udps_badlen); >> goto badunlocked; >> }=20 >> /* >> * Checksum extended UDP header and data. >> */ >> if (uh->uh_sum =3D=3D 0) { >> if (ulen > plen || ulen < sizeof(struct udphdr)) { >> UDPSTAT_INC(udps_nosum); >> goto badunlocked; >> } >> } >>=20 >> I'm trying to understand the UDP code path... >>=20 >> So (ulen > plen) can't be true. I'm wondering why do we only check = the ulen is not too >> short only in the case when the UDP checksum is zero. A zero checksum = should also never happen. >>=20 >> I think we should check for ulen < sizeof(struct udphdr) in any case. >>=20 >> Opinions? >>=20 >> Best regards >> Michael >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to = "freebsd-net-unsubscribe@freebsd.org" >=20 From owner-freebsd-net@FreeBSD.ORG Thu Oct 2 07:32:38 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74C28F8C for ; Thu, 2 Oct 2014 07:32:38 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 360F33E8 for ; Thu, 2 Oct 2014 07:32:38 +0000 (UTC) Received: from [10.225.7.42] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id F024D1C0E9725; Thu, 2 Oct 2014 09:32:35 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: UDP/IPv6 handling From: Michael Tuexen In-Reply-To: Date: Thu, 2 Oct 2014 09:32:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6AF1921D-BAFB-4969-80EF-C1CE37446D65@lurchi.franken.de> References: To: Bryan Venteicher X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Oct 2014 07:32:38 -0000 On 02 Oct 2014, at 05:51, Bryan Venteicher = wrote: >=20 >=20 > On Wed, Oct 1, 2014 at 11:58 AM, Michael Tuexen = wrote: > Dear all, >=20 > in udp6_input() we have the following code: >=20 > if (nxt =3D=3D IPPROTO_UDP && plen !=3D ulen) { > UDPSTAT_INC(udps_badlen); > goto badunlocked; > } > /* > * Checksum extended UDP header and data. > */ > if (uh->uh_sum =3D=3D 0) { > if (ulen > plen || ulen < sizeof(struct udphdr)) { > UDPSTAT_INC(udps_nosum); > goto badunlocked; > } > } >=20 > I'm trying to understand the UDP code path... >=20 >=20 > =E2=80=8BI too was recently confused by this code. =E2=80=8BI pointed = out one issue to kevlo@ recently, but it still kind of seemed like the = UDP-Lite was mismerged to IPv6. I have a patch (to be committed soon which fixes UDPLite/IPv6). >=20 > So (ulen > plen) can't be true. I'm wondering why do we only check the = ulen is not too > short only in the case when the UDP checksum is zero. A zero checksum = should also never happen. Yepp. >=20 >=20 > =E2=80=8BI hope to have a patch for =E2=80=8BRFC6935 [1] soon so a = zero checksum may be allowed if the inp/udpcb is configured for it. Great. However, we need to check that ulen is at least sizeof(struct = udphdr) in any case. >=20 >=20 > I think we should check for ulen < sizeof(struct udphdr) in any case. >=20 >=20 > =E2=80=8BI think previously, the checks in ip6_input(), = IP6_EXTHDR_CHECK(), and plen =3D=3D ulen made this unnecessary. I think = we'd want to do it for UDP-Lite if ulen was not initially zero. But IP6_EXTHDR_CHECK doesn't check any fields in the packet. So it can = happen that plen =3D=3D ulen and ulen < sizeof(struct udphdr)... Best regards Michael > =E2=80=8B[1] - http://tools.ietf.org/html/rfc6935=E2=80=8B > =20 > Opinions? >=20 > Best regards > Michael > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20 From owner-freebsd-net@FreeBSD.ORG Thu Oct 2 08:22:08 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA9B1238; Thu, 2 Oct 2014 08:22:08 +0000 (UTC) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 836AEB8F; Thu, 2 Oct 2014 08:22:08 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id le20so1046863vcb.40 for ; Thu, 02 Oct 2014 01:22: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=2xvLvOIOh+ydVW5aw5hKsnpxswHGUzTKWucyjPVoO6g=; b=1A9CAEFkPFPL9eE02l1St2WA9eizjdh3PYZvxPGTfNKgiJe9y/i9zhtxYi4n5walWw qKz19oVK1OHJycNXhhebUobl0Wj7qK+yYcLgKplUTXKKM1jcAv61yVGOUXWpBJxAE/bQ +EZ0ekqpv7cxwmtNcghHx5MNkUl8UAGvc9L7rRCGkCfEqZYd7aS7QqBFYZozsmisDROO acnkvYyemCA6CL31LqY7U1MulkmpddTMWiayukA6unNICfHd3oeHN6YyFXlOnEpfEjzk +L+dMwWIltcP3baG2sXM+jzXWIlsdLdzLDhB+ir434loGD8X98bbjHBgylCEc2RZv2hf m3vQ== MIME-Version: 1.0 X-Received: by 10.52.156.100 with SMTP id wd4mr19355960vdb.39.1412238127449; Thu, 02 Oct 2014 01:22:07 -0700 (PDT) Received: by 10.220.150.146 with HTTP; Thu, 2 Oct 2014 01:22:07 -0700 (PDT) In-Reply-To: References: Date: Thu, 2 Oct 2014 01:22:07 -0700 Message-ID: Subject: Re: [Bug 193053] ixgbe(4) IXGBE_LEGACY_TX + ALTQ path broken From: Jack Vogel To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net , bugzilla-noreply@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Oct 2014 08:22:09 -0000 LEGACY is not there just because of ALTQ, but rather because there have been significant customers of Intel that use the driver in OS versions older than 8 that do not have the required interface. Jack... going back to my sabbatical now :) On Thu, Oct 2, 2014 at 12:22 AM, Ermal Lu=E7i wrote: > In pfSense the driver has been modified to compile a hybrid mode. > Meaning have activated both LEGACY and new transmit queue model. > > It works correctly and avoids the problems of recompiling with ALTQ. > It also solves the problem on having performance impacts when ALTQ is no= t > in use. > > There are even some drivers in the tree that do this by default already. > > From my analysis there should not be an LEGACY define but just mask all o= f > this behind ALTQ definition if needed. > > On Wed, Oct 1, 2014 at 8:28 PM, wrote: > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193053 > > > > --- Comment #9 from ncrogers@gmail.com --- > > Any chance we can get some kind of resolution on this before 10.1? It > seems > > like simply upgrading the ixgbe driver with the latest from Intel fixes > the > > problem. If that is not possible, the changes in the patch I posted are > > still > > working for me in production > > > > -- > > You are receiving this mail because: > > You are the assignee for the bug. > > _______________________________________________ > > 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" > > > > > > -- > Ermal > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Oct 2 14:46:25 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 821F7C48 for ; Thu, 2 Oct 2014 14:46:25 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F5CBCFE for ; Thu, 2 Oct 2014 14:46:24 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id d1so4260955wiv.2 for ; Thu, 02 Oct 2014 07:46:23 -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:content-type; bh=Xdawn46MB452gNOib4u+Z+WiU7cB4tUYJA6/IXeepJc=; b=a8xIai5pwq6WUvXhpke8MJQmRXXOQ9nymOD0nztFUCwzzHP1OZMRpg5uEuffCY68TV i+g3whhET4HHaKhpCBfbwrY980/bxBojRkGe1CQPqRRRkPr3Um+sDLc4dMwo+9fpoSTs zH+9akSV5YI2JF1+L3vIbHXCFeOq7+F1m6MfraWyzrwVvi2u4IB6UMW8HpB4qzvZg2fk oEJ7CwlO57lUtJy19Ms6LNArwmy4VoF7IUAs9QiYUM8NzRdBFqyyrcMrDoveqHj3+6O8 OjAt2+ZGB906GJKjhcJn6rrstgWwRqRA8T7gy57lYyhV0fi5+c6EwcsJP/3ovK7ozgq6 mNMw== MIME-Version: 1.0 X-Received: by 10.194.133.135 with SMTP id pc7mr62484968wjb.54.1412261183300; Thu, 02 Oct 2014 07:46:23 -0700 (PDT) Received: by 10.194.190.78 with HTTP; Thu, 2 Oct 2014 07:46:23 -0700 (PDT) Date: Thu, 2 Oct 2014 22:46:23 +0800 Message-ID: Subject: Understanding netstat -ibnhW From: Ben Woods To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Oct 2014 14:46:25 -0000 In the FreeBSD forum post below, I explain having difficulty reading the output of netstat -ibnhW. In short, I am trying to determine the network usage from a network interface, but the one interface is listed once for each subnet on the NIC. http://forums.freebsd.org/viewtopic.php?f=7&t=48226 There does not seem to be much guidance on how to read this output either in the netstat(1) manpage or in the FreeBSD handbook. Anyone think this warrants a doc update? -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-net@FreeBSD.ORG Thu Oct 2 16:43:22 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85AD5254; Thu, 2 Oct 2014 16:43:22 +0000 (UTC) Received: from relaygateway01.edpnet.net (relaygateway01.edpnet.net [212.71.1.210]) by mx1.freebsd.org (Postfix) with ESMTP id AA126DD8; Thu, 2 Oct 2014 16:43:20 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsGAOp/LVRNbXB9/2dsb2JhbABggw5TWYMCx1oMiFkXAXuECwIgM18TDgIRBRQRJRKIQgmnQ49FhlmTJYFTBZYphAeDAgGVc4IggUU7LwGCSQEBAQ X-IPAS-Result: AlsGAOp/LVRNbXB9/2dsb2JhbABggw5TWYMCx1oMiFkXAXuECwIgM18TDgIRBRQRJRKIQgmnQ49FhlmTJYFTBZYphAeDAgGVc4IggUU7LwGCSQEBAQ X-IronPort-AV: E=Sophos;i="5.04,639,1406584800"; d="scan'208";a="277637104" Received: from 77.109.112.125.adsl.dyn.edpnet.net (HELO mordor.lan) ([77.109.112.125]) by relaygateway01.edpnet.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Oct 2014 18:09:32 +0200 Date: Thu, 2 Oct 2014 18:42:02 +0200 From: Julien Cigar To: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: [jcigar@ulb.ac.be: Listen queue overflow: 8 already in queue awaiting acceptance] Message-ID: <20141002164202.GI29361@mordor.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LZ7ZmEAmJ6juC7Oo" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Oct 2014 16:43:22 -0000 --LZ7ZmEAmJ6juC7Oo Content-Type: multipart/mixed; boundary="VKLB3BcClAS4nArB" Content-Disposition: inline --VKLB3BcClAS4nArB Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable sorry for cross-posting, I'm forwarding this as it seems that part of the problem is also related to: https://lists.freebsd.org/pipermail/freebsd-net/2014-September/039664.html I also wonder if something has been fixed in -STABLE in this area .. (please keep me in CC as I'm not subscribed on freebsd-net@ an freebsd-stable@) --=20 Julien Cigar Belgian Biodiversity Platform (http://www.biodiversity.be) PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0 No trees were killed in the creation of this message. However, many electrons were terribly inconvenienced. --VKLB3BcClAS4nArB Content-Type: message/rfc822 Content-Disposition: inline Return-Path: X-Original-To: mage@localhost Delivered-To: mage@localhost.lan Received: from mordor.lan (localhost [127.0.0.1]) by slug.uni.cx (Postfix) with ESMTP id 016576813F for ; Thu, 2 Oct 2014 11:58:22 +0200 (CEST) Received: from pop.ulb.ac.be [164.15.128.18] by mordor.lan with POP3 (fetchmail-6.3.26) for (single-drop); Thu, 02 Oct 2014 11:58:22 +0200 (CEST) Received: from mach.vub.ac.be (mach.vub.ac.be [134.184.129.3]) by mcs1.vub.ac.be (Cyrus v2.3.16) with LMTPA; Thu, 02 Oct 2014 11:52:40 +0200 X-Sieve: CMU Sieve 2.3 Received: from mxin.ulb.ac.be (mxin.ulb.ac.be [164.15.128.112]) by mach.vub.ac.be (Postfix) with ESMTP id B61D01978C5 for ; Thu, 2 Oct 2014 11:52:40 +0200 (CEST) X-SenderBaseScore: 5.6 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0CANIfLVQICLJ0nGdsb2JhbABggmt2WYMCxz4bBodMA4EPFgEBEAEBAQEBBg0JCRQshAsCICMKLAMBAgYCKxMKBAICAwELBWGIOgIBpm+PRoZZkEOCYoFTBZYphwkBmVhqgkoBAQE X-IronPort-AV: E=Sophos;i="5.04,638,1406584800"; d="scan'208";a="455374174" Received: from mx2.freebsd.org ([8.8.178.116]) by mxin.ulb.ac.be with ESMTP; 02 Oct 2014 11:52:39 +0200 Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.freebsd.org (Postfix) with ESMTPS id 08579159A; Thu, 2 Oct 2014 09:52:26 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by hub.freebsd.org (Postfix) with ESMTP id E8011AED; Thu, 2 Oct 2014 09:52:25 +0000 (UTC) Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C37D5A6D for ; Thu, 2 Oct 2014 09:52:21 +0000 (UTC) Received: from relaygateway02.edpnet.net (relaygateway02.edpnet.net [212.71.1.211]) by mx1.freebsd.org (Postfix) with ESMTP id 5FA607A5 for ; Thu, 2 Oct 2014 09:52:20 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkGAFofLVRNbXB9/2dsb2JhbABggw5TWYMCx1+IXRcBe4QtM18TDgIRBSWIeZcyjzuPR4ZZkEOCYoFTBZYphwkBlXODZTsvgkoBAQE X-IPAS-Result: AlkGAFofLVRNbXB9/2dsb2JhbABggw5TWYMCx1+IXRcBe4QtM18TDgIRBSWIeZcyjzuPR4ZZkEOCYoFTBZYphwkBlXODZTsvgkoBAQE X-IronPort-AV: E=Sophos;i="5.04,638,1406584800"; d="scan'208";a="267829497" Received: from 77.109.112.125.adsl.dyn.edpnet.net (HELO mordor.lan) ([77.109.112.125]) by relaygateway02.edpnet.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Oct 2014 11:17:10 +0200 Date: Thu, 2 Oct 2014 11:52:06 +0200 From: Julien Cigar To: freebsd-questions@freebsd.org Subject: Listen queue overflow: 8 already in queue awaiting acceptance Message-ID: <20141002095206.GG29361@mordor.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="U7PH6YjyT5379uVx" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: owner-freebsd-questions@freebsd.org Sender: owner-freebsd-questions@freebsd.org --U7PH6YjyT5379uVx Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, I'm running 10-RELEASE on a HP Proliant DL160 Gen8 and I'm seeing the following in my kernel logs: sonewconn: pcb 0xfffff8010e561310: Listen queue overflow: 8 already in queue awaiting acceptance I already raised kern.ipc.soacceptqueue to 1024 and netstat -naA | grep "fffff8010e561310" returns nothing Any idea what could it be ..? I've put some statistics here https://dpaste.de/t8kJ/raw The machine is running Apache 2.4 (with accf_http/accf_data loaded), PF, some webapps (ruby on rails, php-fpm, python, ...), .. Thanks, Julien --=20 Julien Cigar Belgian Biodiversity Platform (http://www.biodiversity.be) PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0 No trees were killed in the creation of this message. However, many electrons were terribly inconvenienced. --U7PH6YjyT5379uVx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJULSBGAAoJEAi2KiTKQR5pFvwP/ipOiw8G9dUcwDu4IpXLgkLj VaQJHSQqGL9f6wbAYGYWwv3FtP46u46CixFBNbxa6jqscRiaFwIn2tlQxWhMQf0x iNEDmOsxIhRvO6YQcrEUJTogBnzXL8ZBwsXHWqNaTMD85SrD7sjIja3klAdpfW66 aXMuvoyOLUSNH0XP9okmshxSE+CDoiQN8au74B8ZkLdh6Oq1cr2fqZMBMVXegBML Hf+ijKwn5zydsxZCEZyqP/8e35n6HruzM728HbY8MdNYY4/Wa2WocFTk9okmM9sY msVRoFLPfnoeV0BzOBR4GFD4D8f6yI7u3vz6MtWV3Qz3xI7I2uXrzkE05d+zb5+U /X4N2jVNbXFVy3gzEhKVlWDew/Kw82L247ddOaHrJB+5JSOK+n4iM3dFqV/ISfIR AqlSPDPrvDvdzQZtsRrj9Jh0tFFNKcpdFQDdklzbr5xjPmBLJfppBWMBe+rJ7MCG 38Nbf900C0EY1kuEmH3XR9jFBgT7pJwa+6rfWCnU4FSouGTwz9gw1u//du7VUnuZ f8aXSx/D0cgdWiR8fA1FravBpzv7qKrAaLJGiMm+23Fkk3IPOcKvTQYzKK0iX4ix 0MyaWxqEVKhGYy17D2fr7axOMEVYkJ4PyRjhzpoo/D3mY0s2GxlWM5Jrmwm7BiNF uJ3TrJZzXm8bj4gCRzfy =pP5L -----END PGP SIGNATURE----- --U7PH6YjyT5379uVx-- --VKLB3BcClAS4nArB-- --LZ7ZmEAmJ6juC7Oo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJULYBaAAoJEAi2KiTKQR5p534QAJ+xFgYx469m4ZUBmfov6iw1 gu3UMQ/VxQhfSdMJXT0XXfiSRTiX+LY5kjmIGdu3RRUruhyGqPbJ70gOkJ6E/bie 0fK+njuNi6WIGGSFrkIa7G/9vdFEujaEbFFgSyqXj2FHP6D4W+tGCjtM/CrLvw1L u0tkmi6QNj4i+F9ObqjNbG0+uTU16EBq67aveAoy3G+9H1ijYzlyyMNDEXe/e4/5 B8vhVLtg/ZxV3R17Vbu8QqizOWyreQUxe8wvD+exdxW5OrOURybh4LJfye+6nFvb qyVnNAfYBGc/1lLWtYo2jdm42OmQV9GGi/8Zq1tHAhhQZt2cmnqitTTQ25vhrYFo 5i6XDjCIM6nUsiO/iCzsDGY4Un9ExcqKP1Jr/J+i0asA8X11SRm7sVCWGFJ87isV 0GTszwVDRgVBz04e0exr5jOk+VJ/ynCzkHzO3lESHxbdY4Wgv/5g77YQPqOI5hj/ nSy1fdSbLeaMLLVU+WNVQRhesFRVKpnusOdcuLgCeg75fdc9nK/B0PxSZWHQ7egl 8P7dEWHNrjCqfS3wo/1Ezktu+cpyhi/IcsfuY0IJ592w2CUF19eO7LZXyXLHNIV8 PLxBznZhysuc4cKZC1Br+2Gv2NXH5/Af++4H+8h4Sov9BhID05GbMzWRdrDElTRZ GvhAMQC9EbLFiqQHv06Y =28oN -----END PGP SIGNATURE----- --LZ7ZmEAmJ6juC7Oo-- From owner-freebsd-net@FreeBSD.ORG Thu Oct 2 17:21:34 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D0752495; Thu, 2 Oct 2014 17:21:34 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 45F6425E; Thu, 2 Oct 2014 17:21:34 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id m15so3800915wgh.4 for ; Thu, 02 Oct 2014 10:21:32 -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=dJD28nKSgygTd4rae4RU/W6RKVXnaslIEYpDPAFJ7Vk=; b=LY6nuc7VQYI839r42DtkAnUD8fPX/tXNPPs7ZMHqWBP9NCOT2LBac9Tgo1zBKqk0zR V+T2gEB/pBP8Qmd1n9tFmrI7gKF/+99SDzuOlKjlpbEqGrN/JO1uS5WSNRKHISStjbP1 mJgXWcPYMhdgecqXE6uIAd69wOE4JO/R/4NWWSo73lwp6zYiTYgvYQ8R55qlS+E63hAI KoVJe7hk6zbhCY0KIultK2KIyCX8YIOQ7UNciJrFJOFz0nITeq96YXxd6A3Kg/E0LRfy KGANCnahHxUIg1YH6PjF4EwyqPk/1hscjDtNF7z1jycwGHSNiKcVmoJr+MZr/mchaU/2 eZDA== MIME-Version: 1.0 X-Received: by 10.194.246.2 with SMTP id xs2mr187959wjc.33.1412270492522; Thu, 02 Oct 2014 10:21:32 -0700 (PDT) Received: by 10.216.254.74 with HTTP; Thu, 2 Oct 2014 10:21:32 -0700 (PDT) In-Reply-To: <20141002164202.GI29361@mordor.lan> References: <20141002164202.GI29361@mordor.lan> Date: Thu, 2 Oct 2014 13:21:32 -0400 Message-ID: Subject: Re: [jcigar@ulb.ac.be: Listen queue overflow: 8 already in queue awaiting acceptance] From: Brandon Allbery To: Julien Cigar Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net@freebsd.org, freebsd-stable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Oct 2014 17:21:35 -0000 On Thu, Oct 2, 2014 at 12:42 PM, Julien Cigar wrote: > sonewconn: pcb 0xfffff8010e561310: Listen queue overflow: 8 already in > queue awaiting acceptance > My immediate reaction is to find out which program is listening on that socket, and that it doesn't have listen(s, 8); in its code somewhere. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-net@FreeBSD.ORG Thu Oct 2 17:24:15 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF5D5629; Thu, 2 Oct 2014 17:24:14 +0000 (UTC) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 90A6034B; Thu, 2 Oct 2014 17:24:14 +0000 (UTC) Received: by mail-qc0-f170.google.com with SMTP id m20so2582880qcx.29 for ; Thu, 02 Oct 2014 10:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hbPfbYv182WNeqA40SilypbPh9HdU5Y9htXUOksYRuE=; b=tRZmcJ/ZPb6GAkI4ko0cThdG7pDQ4JKFtR9eA8QfifgJWIzR5NkXoow9wYy0S8Zb+l ymtQnUsoo1dvtKg7Fj+6lEQTfgtu3RhzAIcabYgBIaUNfjBanka20VwNlfYR8Dc8NxzY zgxk1zBtsr9aoXkGnslsclLoPZ279hPOfrc+d2fpwnW/gkVTBzHeFNZ/E+5cu6BBdAAU nC2z/lOcX2WpQ7blHQ+FULkpN6hoU7Fj4D0ddSmEgqZsUdfQ3C4jGMVudtuEvrfd7z/F eZmAk+eKL10wQREOa5WN2wOINo8/cdTja9ubLGUM228NSK6oPecnxtt+VbR/36SzEZxg m8qA== MIME-Version: 1.0 X-Received: by 10.224.20.9 with SMTP id d9mr299887qab.7.1412270653481; Thu, 02 Oct 2014 10:24:13 -0700 (PDT) Sender: hiren.panchasara@gmail.com Received: by 10.96.168.194 with HTTP; Thu, 2 Oct 2014 10:24:13 -0700 (PDT) In-Reply-To: <20141002164202.GI29361@mordor.lan> References: <20141002164202.GI29361@mordor.lan> Date: Thu, 2 Oct 2014 10:24:13 -0700 X-Google-Sender-Auth: BOeCzcnWRO3BKmx3I14mXOEAKyA Message-ID: Subject: Re: [jcigar@ulb.ac.be: Listen queue overflow: 8 already in queue awaiting acceptance] From: hiren panchasara To: Julien Cigar Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" , FreeBSD Stable Mailing List X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Oct 2014 17:24:15 -0000 On Thu, Oct 2, 2014 at 9:42 AM, Julien Cigar wrote: > sorry for cross-posting, I'm forwarding this as it seems that part of > the problem is also related to: > https://lists.freebsd.org/pipermail/freebsd-net/2014-September/039664.html Umm, this looks like a different problem than the subject of this email. > > I also wonder if something has been fixed in -STABLE in this area .. > > (please keep me in CC as I'm not subscribed on freebsd-net@ an > freebsd-stable@) > > -- > Julien Cigar > Belgian Biodiversity Platform (http://www.biodiversity.be) > PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0 > No trees were killed in the creation of this message. > However, many electrons were terribly inconvenienced. > > > ---------- Forwarded message ---------- > From: Julien Cigar > To: freebsd-questions@freebsd.org > Cc: > Date: Thu, 2 Oct 2014 11:52:06 +0200 > Subject: Listen queue overflow: 8 already in queue awaiting acceptance > Hello, > > I'm running 10-RELEASE on a HP Proliant DL160 Gen8 and I'm seeing the > following in my kernel logs: > sonewconn: pcb 0xfffff8010e561310: Listen queue overflow: 8 already in > queue awaiting acceptance This usually means the application is not keeping up with the incoming connections. > > I already raised kern.ipc.soacceptqueue to 1024 and netstat -naA | grep > "fffff8010e561310" returns nothing This is the usual way of finding the culprit process. If this doesn't return anything, it probably means that it is a short-lived process. Here is an example of what you could do: sonewconn: pcb 0xfffff8008f40cb10: Listen queue overflow: 1 already in queue awaiting acceptance >From kgdb, (kgdb) p ((struct inpcb *)0xfffff8008f40cb10)->inp_inc $3 = {inc_flags = 0 '\0', inc_len = 0 '\0', inc_fibnum = 0, inc_ie = {ie_fport = 0, ie_lport = 10295, ie_dependfaddr = { ie46_foreign = {ia46_pad32 = {0, 0, 0}, ia46_addr4 = {s_addr = 0}}, ie6_foreign = {__u6_addr = { __u6_addr8 = '\0' , __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}}, ie_dependladdr = {ie46_local = {ia46_pad32 = {0, 0, 0}, ia46_addr4 = {s_addr = 0}}, ie6_local = {__u6_addr = { __u6_addr8 = '\0' , __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}}}} Here, ie_lport = 10295 which is in n/w byte order and converting it to host byte order, 10295 -> 0x2837 and swapping them gives us 0x3728 which is 14120. Now, use sockstat to find out what process is on that port: $ sockstat -l | grep 14120 cheers, Hiren From owner-freebsd-net@FreeBSD.ORG Thu Oct 2 18:20:03 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1CEE7FE; Thu, 2 Oct 2014 18:20:03 +0000 (UTC) Received: from relaygateway02.edpnet.net (relaygateway02.edpnet.net [212.71.1.211]) by mx1.freebsd.org (Postfix) with ESMTP id 1E750BB4; Thu, 2 Oct 2014 18:20:02 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoGADSWLVRNbXB9/2dsb2JhbABggw5TWIMCx2kMh0sCgQwXAXuEAwEBAQQBAiAELyMQCxEDAQIBCRMOAgIPBRQRFg4TiEIJp2ePO4Y6ARePRBEBPxEHBoJxgVQFhiuQA4JBgUmDAgGBLINBkQ6CIIFFOy8BgQ6BOwEBAQ X-IPAS-Result: AmoGADSWLVRNbXB9/2dsb2JhbABggw5TWIMCx2kMh0sCgQwXAXuEAwEBAQQBAiAELyMQCxEDAQIBCRMOAgIPBRQRFg4TiEIJp2ePO4Y6ARePRBEBPxEHBoJxgVQFhiuQA4JBgUmDAgGBLINBkQ6CIIFFOy8BgQ6BOwEBAQ X-IronPort-AV: E=Sophos;i="5.04,640,1406584800"; d="scan'208";a="267975572" Received: from 77.109.112.125.adsl.dyn.edpnet.net (HELO mordor.lan) ([77.109.112.125]) by relaygateway02.edpnet.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Oct 2014 19:45:00 +0200 Date: Thu, 2 Oct 2014 20:19:58 +0200 From: Julien Cigar To: hiren panchasara Subject: Re: [jcigar@ulb.ac.be: Listen queue overflow: 8 already in queue awaiting acceptance] Message-ID: <20141002181958.GJ29361@mordor.lan> References: <20141002164202.GI29361@mordor.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MqkwUViToTQK+HjE" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-net@freebsd.org" , FreeBSD Stable Mailing List X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Oct 2014 18:20:03 -0000 --MqkwUViToTQK+HjE Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 02, 2014 at 10:24:13AM -0700, hiren panchasara wrote: > On Thu, Oct 2, 2014 at 9:42 AM, Julien Cigar wrote: > > sorry for cross-posting, I'm forwarding this as it seems that part of > > the problem is also related to: > > https://lists.freebsd.org/pipermail/freebsd-net/2014-September/039664.h= tml >=20 > Umm, this looks like a different problem than the subject of this email. yes and no, seems the same hardware (HP and igb) and I have also some "requests for mbufs denied" (https://dpaste.de/t8kJ/raw) without any reasons. I should add that the box hanged a week ago and I had to do a hard reboot, I have the feeling that it's somewhat related to this problem .. > > > > I also wonder if something has been fixed in -STABLE in this area .. > > > > (please keep me in CC as I'm not subscribed on freebsd-net@ an > > freebsd-stable@) > > > > -- > > Julien Cigar > > Belgian Biodiversity Platform (http://www.biodiversity.be) > > PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0 > > No trees were killed in the creation of this message. > > However, many electrons were terribly inconvenienced. > > > > > > ---------- Forwarded message ---------- > > From: Julien Cigar > > To: freebsd-questions@freebsd.org > > Cc: > > Date: Thu, 2 Oct 2014 11:52:06 +0200 > > Subject: Listen queue overflow: 8 already in queue awaiting acceptance > > Hello, > > > > I'm running 10-RELEASE on a HP Proliant DL160 Gen8 and I'm seeing the > > following in my kernel logs: > > sonewconn: pcb 0xfffff8010e561310: Listen queue overflow: 8 already in > > queue awaiting acceptance >=20 > This usually means the application is not keeping up with the incoming > connections. > > > > I already raised kern.ipc.soacceptqueue to 1024 and netstat -naA | grep > > "fffff8010e561310" returns nothing >=20 > This is the usual way of finding the culprit process. If this doesn't > return anything, it probably means that it is a short-lived process. >=20 > Here is an example of what you could do: >=20 > sonewconn: pcb 0xfffff8008f40cb10: Listen queue overflow: 1 already in qu= eue > awaiting acceptance >=20 > From kgdb, > (kgdb) p ((struct inpcb *)0xfffff8008f40cb10)->inp_inc > $3 =3D {inc_flags =3D 0 '\0', inc_len =3D 0 '\0', inc_fibnum =3D 0, inc_i= e =3D {ie_fport > =3D 0, ie_lport =3D 10295, ie_dependfaddr =3D { > ie46_foreign =3D {ia46_pad32 =3D {0, 0, 0}, ia46_addr4 =3D {s_addr = =3D 0}}, > ie6_foreign =3D {__u6_addr =3D { > __u6_addr8 =3D '\0' , __u6_addr16 =3D {0, 0, = 0, 0, 0, > 0, 0, 0}, __u6_addr32 =3D {0, 0, 0, 0}}}}, > ie_dependladdr =3D {ie46_local =3D {ia46_pad32 =3D {0, 0, 0}, ia46_ad= dr4 =3D > {s_addr =3D 0}}, ie6_local =3D {__u6_addr =3D { > __u6_addr8 =3D '\0' , __u6_addr16 =3D {0, 0, = 0, 0, 0, > 0, 0, 0}, __u6_addr32 =3D {0, 0, 0, 0}}}}}} >=20 > Here, ie_lport =3D 10295 which is in n/w byte order and converting it to = host > byte order, 10295 -> 0x2837 and swapping them gives us 0x3728 which is 14= 120. >=20 > Now, use sockstat to find out what process is on that port: >=20 > $ sockstat -l | grep 14120 >=20 > cheers, > Hiren --=20 Julien Cigar Belgian Biodiversity Platform (http://www.biodiversity.be) PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0 No trees were killed in the creation of this message. However, many electrons were terribly inconvenienced. --MqkwUViToTQK+HjE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJULZdOAAoJEAi2KiTKQR5ppMsQAMoXy4Cp/wtNLhg6eB69f6Pc tt8x0f5rHZOzusOZbcwrejzmviE18bMJV9TaVeAlKXcAKHYuE5SzbnDfI9BZbXJh 42IVHjhRohQR8i8jYSuYCHd8d6t5KT417/ArhxrcKGcWgllReNS4rNYa3S0dROS0 MT8HWc/Aw1Vj0p0cfr4GtdmdNW+bE5OZZ/ohPElsJ3Q2NpWBDVB3VtcuayYXuog1 fYXh8A2MRQFsPT0vU2rgjI3HsyhfwDQJ8i0KR5whz0EqfACgNMn6kJO3z3qI85zl DvHVJpidrlZ19p7+2W0tU3E7fzuE+o1oQ4P7WAMzn3QBibLSuF5ruVsJCt1JXBZB yuvBaycMDlN3C2za51KsMUdQZGP6El2zhfE1kIlda7RoidLfii49ndyBiRN8eZ3S IzWxWGjIjJuYeZGfnT5PrU7p3MscYkf9l0o6Qn8nYZZG4PefK2xo0xzkkIfmKhJB hF144vMY7PVlcblXlaV+kBHVSfPeXUkkICvaEMMB1pfV13Z3I6ns9Jhzg+fnWrMA LSeM/6eH9HtxuF6fk1GVD3R3EbsQG58c+zN+2S0gyEjDzjgxj/ZTUB1AUZ68a/TQ 82+i7CfePx6bcm9urFZ7lqf9uVGl9wx7NzfPkP8ThpdsS7WQ/qrAMhZ1InxjWv6j AAQ/n0t+UpH2fKFInP+r =xvC2 -----END PGP SIGNATURE----- --MqkwUViToTQK+HjE-- From owner-freebsd-net@FreeBSD.ORG Thu Oct 2 19:02:43 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 191AC18B; Thu, 2 Oct 2014 19:02:43 +0000 (UTC) Received: from relaygateway01.edpnet.net (relaygateway01.edpnet.net [212.71.1.210]) by mx1.freebsd.org (Postfix) with ESMTP id 7C84712E; Thu, 2 Oct 2014 19:02:42 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgGAL2gLVRNbXB9/2dsb2JhbABggw5TWIMCx2+HUQKBDBcBe4QEAQEEIzMjEAsYCRMOAgIPBQ0YJBOIKgMVqBKOWQ1XhlKNdoIwB4J3gVQFli6EfYIPAYFnjUSGUIIggUU7L4JKAQEB X-IPAS-Result: AmgGAL2gLVRNbXB9/2dsb2JhbABggw5TWIMCx2+HUQKBDBcBe4QEAQEEIzMjEAsYCRMOAgIPBQ0YJBOIKgMVqBKOWQ1XhlKNdoIwB4J3gVQFli6EfYIPAYFnjUSGUIIggUU7L4JKAQEB X-IronPort-AV: E=Sophos;i="5.04,640,1406584800"; d="scan'208";a="277669379" Received: from 77.109.112.125.adsl.dyn.edpnet.net (HELO mordor.lan) ([77.109.112.125]) by relaygateway01.edpnet.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Oct 2014 20:30:07 +0200 Date: Thu, 2 Oct 2014 21:02:38 +0200 From: Julien Cigar To: Brandon Allbery Subject: Re: [jcigar@ulb.ac.be: Listen queue overflow: 8 already in queue awaiting acceptance] Message-ID: <20141002190237.GK29361@mordor.lan> References: <20141002164202.GI29361@mordor.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fBycuDTqZgS1bANG" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-net@freebsd.org, freebsd-stable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Oct 2014 19:02:43 -0000 --fBycuDTqZgS1bANG Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 02, 2014 at 01:21:32PM -0400, Brandon Allbery wrote: > On Thu, Oct 2, 2014 at 12:42 PM, Julien Cigar wrote: >=20 > > sonewconn: pcb 0xfffff8010e561310: Listen queue overflow: 8 already in > > queue awaiting acceptance > > >=20 > My immediate reaction is to find out which program is listening on that > socket, and that it doesn't have >=20 > listen(s, 8); >=20 > in its code somewhere. I tried, but, apparently, the socket is only present a fraction of seconds in netstat -naA output .. so an attempt of netstat -naA | grep "fffff8010e561310" returns nothing (note that it's not always the same socket: sonewconn: pcb 0xfffff8010e561310: Listen queue overflow: 8 already in queue awaiting acceptance sonewconn: pcb 0xfffff80b34faec40: Listen queue overflow: 8 already in queue awaiting acceptance etc >=20 > --=20 > brandon s allbery kf8nh sine nomine associa= tes > allbery.b@gmail.com ballbery@sinenomine.= net > unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.= net --=20 Julien Cigar Belgian Biodiversity Platform (http://www.biodiversity.be) PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0 No trees were killed in the creation of this message. However, many electrons were terribly inconvenienced. --fBycuDTqZgS1bANG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJULaFNAAoJEAi2KiTKQR5pOZoQAI5lxwvZ+vLNjDnSc6OyXebk liolYYnfDmA5Lb4+JZNVlvH8Q3UEY8+Ea1q3oNEmRW9/KUGo9Itx0gP1QjC2JhAK QKq/i8PtMNt56tlDmC/FQ7iNSzMehQvMqYvLX2T4Im3rkCtZ44kHzMDWxDJ10o6N EveckIkMo6JBnO6x1nhwdN32F9WMTBx5KaKOZmJlpXA7h+mIF7BEbbYe9shatcEl eH/hDcFTIyexs3ZKMEqcRNnqB6/rZIizGdLy+KxnYsL4R/gSWwdgsyhcUMcMLIy0 v2L2p97sM25Rhwbe7Cr7a1MLlztFMh3HK1rWmlnZ9yKOOzb9aupp06R/z+qlXHF3 OUGg6vkh5yMv2LOjoIapLKb3c+LJ5BqzQ6aIo3et9TVCstLjC5qIAJwFPsNdSw6H FqUKMYgyfw+0o2lEcxnwseSGBamKR7jmobT+NLjjgOoG9c5DCewt7Yrgktmmf57a QDJjjieDfS90dDhlU6oaYE+WVRzgyEwCCTPx8Y/XqwSuBzIhKciw4+EQDhzRkUXj Xbbe3Wa8LcgHYleJ2KOIXocv4yFXKyP+PrQXTmymvcAMZfFymb4SddjOwqexpy// ZoMiRpPCcvrn0pY8nl5SAiixMx2i3i3bCBrmy8c3n/qGyqD1XQ11s3K7lH6dVVia dfethTMgXOEeqJDrPK7V =AiHC -----END PGP SIGNATURE----- --fBycuDTqZgS1bANG-- From owner-freebsd-net@FreeBSD.ORG Thu Oct 2 22:07:19 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 146FABDC; Thu, 2 Oct 2014 22:07:19 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 5F88599B; Thu, 2 Oct 2014 22:07:18 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 084B67300A; Fri, 3 Oct 2014 00:12:23 +0200 (CEST) Date: Fri, 3 Oct 2014 00:12:23 +0200 From: Luigi Rizzo To: current@freebsd.org, delphij@freebsd.org, net@freebsd.org Subject: adding netmap support to libpcap in FreeBSD Message-ID: <20141002221223.GA37059@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Oct 2014 22:07:19 -0000 I want to bring netmap support into our libpcap. The patch is attached, and as you can see changes are trivial, with the new methods contained in a new file pcap-netmap.c I would love to upstream this to the libpcap project (I even have the necessary configure* patches, see code.google.com/p/netmap-libpcap), but I don't see that happening soon: when I tried last winter there was hardly any interest, and then a bikeshed on the absence of a findalldevs method (which i cannot provide as the set would be infinite, unlike my patience :) So for the time being I plan to put the new source file pcap-netmap.c into lib/libpcap instead of contrib/libpcap . Let me know if you have objections. cheers luigi Index: contrib/libpcap/inet.c =================================================================== --- contrib/libpcap/inet.c (revision 272410) +++ contrib/libpcap/inet.c (working copy) @@ -737,6 +737,10 @@ #ifdef PCAP_SUPPORT_USB || strstr(device, "usbmon") != NULL #endif +#ifdef PCAP_SUPPORT_NETMAP + || !strncmp(device, "netmap:", 7) + || !strncmp(device, "vale", 4) +#endif #ifdef HAVE_SNF_API || strstr(device, "snf") != NULL #endif Index: contrib/libpcap/pcap.c =================================================================== --- contrib/libpcap/pcap.c (revision 272410) +++ contrib/libpcap/pcap.c (working copy) @@ -106,6 +106,10 @@ #include "pcap-netfilter-linux.h" #endif +#ifdef PCAP_SUPPORT_NETMAP +pcap_t* pcap_netmap_create(const char *device, char *ebuf, int *is_ours); +#endif + int pcap_not_initialized(pcap_t *pcap) { @@ -301,6 +305,9 @@ int (*findalldevs_op)(pcap_if_t **, char *); pcap_t *(*create_op)(const char *, char *, int *); } capture_source_types[] = { +#ifdef PCAP_SUPPORT_NETMAP + { NULL, pcap_netmap_create }, +#endif #ifdef HAVE_DAG_API { dag_findalldevs, dag_create }, #endif Index: lib/libpcap/Makefile =================================================================== --- lib/libpcap/Makefile (revision 272410) +++ lib/libpcap/Makefile (working copy) @@ -7,6 +7,7 @@ LIB= pcap SRCS= grammar.y tokdefs.h version.h pcap-bpf.c \ + pcap-netmap.c \ pcap.c pcap-common.c inet.c fad-getad.c gencode.c optimize.c nametoaddr.c \ etherent.c savefile.c bpf_filter.c bpf_image.c bpf_dump.c \ scanner.l sf-pcap.c sf-pcap-ng.c version.c Index: lib/libpcap/config.h =================================================================== --- lib/libpcap/config.h (revision 272410) +++ lib/libpcap/config.h (working copy) @@ -271,6 +271,9 @@ /* target host supports USB sniffing */ /* #undef PCAP_SUPPORT_USB */ +/* target host supports netmap */ +#define PCAP_SUPPORT_NETMAP 1 + /* include ACN support */ /* #undef SITA */ Index: lib/libpcap/pcap-netmap.c =================================================================== --- /dev/null 2014-10-02 23:33:00.000000000 +0200 +++ lib/libpcap/pcap-netmap.c 2014-10-02 23:37:33.000000000 +0200 @@ -0,0 +1,265 @@ +/* + * Copyright (C) 2014 Luigi Rizzo. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``S IS''AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif + +#include +#include +#include +#include +#include +#include +#include +#include + +#define NETMAP_WITH_LIBS +#include + +#include "pcap-int.h" + +/* + * This code is meant to build also on older versions of libpcap. + * + * older libpcap miss p->priv, use p->md.device instead (and allocate). + * Also opt.timeout was in md.timeout before. + * Use #define PCAP_IF_UP to discriminate + */ +#ifdef PCAP_IF_UP +#define NM_PRIV(p) ((struct pcap_netmap *)(p->priv)) +#define the_timeout opt.timeout +#else +#define HAVE_NO_PRIV +#define NM_PRIV(p) ((struct pcap_netmap *)(p->md.device)) +#define SET_PRIV(p, x) p->md.device = (void *)x +#define the_timeout md.timeout +#endif + +#if defined (linux) +/* On FreeBSD we use IFF_PPROMISC which is in ifr_flagshigh. + * remap to IFF_PROMISC on linux + */ +#define IFF_PPROMISC IFF_PROMISC +#define ifr_flagshigh ifr_flags +#endif /* linux */ + +struct pcap_netmap { + struct nm_desc *d; /* pointer returned by nm_open() */ + pcap_handler cb; /* callback and argument */ + u_char *cb_arg; + int must_clear_promisc; /* flag */ + uint64_t rx_pkts; /* # of pkts received before the filter */ +}; + +static int +pcap_netmap_stats(pcap_t *p, struct pcap_stat *ps) +{ + struct pcap_netmap *pn = NM_PRIV(p); + + ps->ps_recv = pn->rx_pkts; + ps->ps_drop = 0; + ps->ps_ifdrop = 0; + return 0; +} + +static void +pcap_netmap_filter(u_char *arg, struct pcap_pkthdr *h, const u_char *buf) +{ + pcap_t *p = (pcap_t *)arg; + struct pcap_netmap *pn = NM_PRIV(p); + + ++pn->rx_pkts; + if (bpf_filter(p->fcode.bf_insns, buf, h->len, h->caplen)) + pn->cb(pn->cb_arg, h, buf); +} + +static int +pcap_netmap_dispatch(pcap_t *p, int cnt, pcap_handler cb, u_char *user) +{ + int ret; + struct pcap_netmap *pn = NM_PRIV(p); + struct nm_desc *d = pn->d; + struct pollfd pfd = { .fd = p->fd, .events = POLLIN, .revents = 0 }; + + pn->cb = cb; + pn->cb_arg = user; + + for (;;) { + if (p->break_loop) { + p->break_loop = 0; + return PCAP_ERROR_BREAK; + } + /* nm_dispatch won't run forever */ + + ret = nm_dispatch((void *)d, cnt, (void *)pcap_netmap_filter, (void *)p); + if (ret != 0) + break; + errno = 0; + ret = poll(&pfd, 1, p->the_timeout); + } + return ret; +} + +/* XXX need to check the NIOCTXSYNC/poll */ +static int +pcap_netmap_inject(pcap_t *p, const void *buf, size_t size) +{ + struct nm_desc *d = NM_PRIV(p)->d; + + return nm_inject(d, buf, size); +} + +static int +pcap_netmap_ioctl(pcap_t *p, u_long what, uint32_t *if_flags) +{ + struct pcap_netmap *pn = NM_PRIV(p); + struct nm_desc *d = pn->d; + struct ifreq ifr; + int error, fd = d->fd; + +#ifdef linux + fd = socket(AF_INET, SOCK_DGRAM, 0); + if (fd < 0) { + fprintf(stderr, "Error: cannot get device control socket.\n"); + return -1; + } +#endif /* linux */ + bzero(&ifr, sizeof(ifr)); + strncpy(ifr.ifr_name, d->req.nr_name, sizeof(ifr.ifr_name)); + switch (what) { + case SIOCSIFFLAGS: + ifr.ifr_flags = *if_flags; + ifr.ifr_flagshigh = *if_flags >> 16; + break; + } + error = ioctl(fd, what, &ifr); + if (error) + return -1; + switch (what) { + case SIOCGIFFLAGS: + *if_flags = ifr.ifr_flags | (ifr.ifr_flagshigh << 16); + } + return 0; +} + +static void +pcap_netmap_close(pcap_t *p) +{ + struct pcap_netmap *pn = NM_PRIV(p); + struct nm_desc *d = pn->d; + uint32_t if_flags = 0; + + if (pn->must_clear_promisc) { + pcap_netmap_ioctl(p, SIOCGIFFLAGS, &if_flags); /* fetch flags */ + if (if_flags & IFF_PPROMISC) { + if_flags &= ~IFF_PPROMISC; + pcap_netmap_ioctl(p, SIOCSIFFLAGS, &if_flags); + } + } + nm_close(d); +#ifdef HAVE_NO_PRIV + free(pn); + SET_PRIV(p, NULL); // unnecessary +#endif + pcap_cleanup_live_common(p); +} + +static int +pcap_netmap_activate(pcap_t *p) +{ + struct pcap_netmap *pn = NM_PRIV(p); + struct nm_desc *d = nm_open(p->opt.source, NULL, 0, NULL); + uint32_t if_flags = 0; + + if (d == NULL) { + snprintf(p->errbuf, PCAP_ERRBUF_SIZE, + "netmap open: cannot access %s: %s\n", + p->opt.source, pcap_strerror(errno)); +#ifdef HAVE_NO_PRIV + free(pn); + SET_PRIV(p, NULL); // unnecessary +#endif + pcap_cleanup_live_common(p); + return (PCAP_ERROR); + } + if (0) + fprintf(stderr, "%s device %s priv %p fd %d ports %d..%d\n", + __FUNCTION__, p->opt.source, d, d->fd, + d->first_rx_ring, d->last_rx_ring); + pn->d = d; + p->fd = d->fd; + if (p->opt.promisc && !(d->req.nr_ringid & NETMAP_SW_RING)) { + pcap_netmap_ioctl(p, SIOCGIFFLAGS, &if_flags); /* fetch flags */ + if (!(if_flags & IFF_PPROMISC)) { + pn->must_clear_promisc = 1; + if_flags |= IFF_PPROMISC; + pcap_netmap_ioctl(p, SIOCSIFFLAGS, &if_flags); + } + } + p->linktype = DLT_EN10MB; + p->selectable_fd = p->fd; + p->read_op = pcap_netmap_dispatch; + p->inject_op = pcap_netmap_inject, + p->setfilter_op = install_bpf_program; + p->setdirection_op = NULL; + p->set_datalink_op = NULL; + p->getnonblock_op = pcap_getnonblock_fd; + p->setnonblock_op = pcap_setnonblock_fd; + p->stats_op = pcap_netmap_stats; + p->cleanup_op = pcap_netmap_close; + + return (0); +} + +pcap_t * +pcap_netmap_create(const char *device, char *ebuf, int *is_ours) +{ + pcap_t *p; + + *is_ours = (!strncmp(device, "netmap:", 7) || !strncmp(device, "vale", 4)); + if (! *is_ours) + return NULL; +#ifdef HAVE_NO_PRIV + { + void *pn = calloc(1, sizeof(struct pcap_netmap)); + if (pn == NULL) + return NULL; + p = pcap_create_common(device, ebuf); + if (p == NULL) { + free(pn); + return NULL; + } + SET_PRIV(p, pn); + } +#else + p = pcap_create_common(device, ebuf, sizeof (struct pcap_netmap)); + if (p == NULL) + return (NULL); +#endif + p->activate_op = pcap_netmap_activate; + return (p); +} From owner-freebsd-net@FreeBSD.ORG Thu Oct 2 23:36:50 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88B2448D; Thu, 2 Oct 2014 23:36:50 +0000 (UTC) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 34E18288; Thu, 2 Oct 2014 23:36:50 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id cm18so107958qab.20 for ; Thu, 02 Oct 2014 16:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Oe1Ek2mnS7PnSYpyeDX0MYGLCCJJKzuRBggy5uOV82k=; b=UB3YfKZy7eNPdwc+D+UohqxpG5DxAkh1J+jUhchNMehkAFHIgMlzhJvrt3MN2DUJKh /w4QjYP/koXEhjqVmmqnsfGcKl9hh0M9uyAM2OtIbFXI4XPtVKXyS6IHNnsWW2ljUgJe pGx7tLzqdqagboi4IYokSCO+XBS6qT1YyHuQy+YF4QEOZeORQgDa1trE/CysxL28EcQj rSHkflEqF2FT5XQWphGTzodUzxaNnreaOHux7zv6myK0sNCD2AKVCF/NDRt2Vf6lLJ/9 RL0iVbgE0cd8USR7eAFoa/TZ3E/fUHUW/ZMZToxbIiqZOPjyzuoaAQ7cjoRQMrG5RtwL cUjg== MIME-Version: 1.0 X-Received: by 10.140.104.13 with SMTP id z13mr65355qge.81.1412293009142; Thu, 02 Oct 2014 16:36:49 -0700 (PDT) Sender: hiren.panchasara@gmail.com Received: by 10.96.168.194 with HTTP; Thu, 2 Oct 2014 16:36:49 -0700 (PDT) In-Reply-To: <20141002181958.GJ29361@mordor.lan> References: <20141002164202.GI29361@mordor.lan> <20141002181958.GJ29361@mordor.lan> Date: Thu, 2 Oct 2014 16:36:49 -0700 X-Google-Sender-Auth: E1Lx0_PGPFmF8p7ZhiYoY_t_59Y Message-ID: Subject: Re: [jcigar@ulb.ac.be: Listen queue overflow: 8 already in queue awaiting acceptance] From: hiren panchasara To: Julien Cigar Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" , FreeBSD Stable Mailing List X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Oct 2014 23:36:50 -0000 On Thu, Oct 2, 2014 at 11:19 AM, Julien Cigar wrote: > On Thu, Oct 02, 2014 at 10:24:13AM -0700, hiren panchasara wrote: >> On Thu, Oct 2, 2014 at 9:42 AM, Julien Cigar wrote: >> > sorry for cross-posting, I'm forwarding this as it seems that part of >> > the problem is also related to: >> > https://lists.freebsd.org/pipermail/freebsd-net/2014-September/039664.html >> >> Umm, this looks like a different problem than the subject of this email. > > yes and no, seems the same hardware (HP and igb) and I have also some > "requests for mbufs denied" (https://dpaste.de/t8kJ/raw) without any > reasons. I should add that the box hanged a week ago and I had to do a > hard reboot, I have the feeling that it's somewhat related to this > problem .. > I suggest you try to debug these 2 problems separately. Did you get a chance to look at kgdb to find the culprit process as I suggested below? cheers, Hiren >> > >> > I also wonder if something has been fixed in -STABLE in this area .. >> > >> > (please keep me in CC as I'm not subscribed on freebsd-net@ an >> > freebsd-stable@) >> > >> > -- >> > Julien Cigar >> > Belgian Biodiversity Platform (http://www.biodiversity.be) >> > PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0 >> > No trees were killed in the creation of this message. >> > However, many electrons were terribly inconvenienced. >> > >> > >> > ---------- Forwarded message ---------- >> > From: Julien Cigar >> > To: freebsd-questions@freebsd.org >> > Cc: >> > Date: Thu, 2 Oct 2014 11:52:06 +0200 >> > Subject: Listen queue overflow: 8 already in queue awaiting acceptance >> > Hello, >> > >> > I'm running 10-RELEASE on a HP Proliant DL160 Gen8 and I'm seeing the >> > following in my kernel logs: >> > sonewconn: pcb 0xfffff8010e561310: Listen queue overflow: 8 already in >> > queue awaiting acceptance >> >> This usually means the application is not keeping up with the incoming >> connections. >> > >> > I already raised kern.ipc.soacceptqueue to 1024 and netstat -naA | grep >> > "fffff8010e561310" returns nothing >> >> This is the usual way of finding the culprit process. If this doesn't >> return anything, it probably means that it is a short-lived process. >> >> Here is an example of what you could do: >> >> sonewconn: pcb 0xfffff8008f40cb10: Listen queue overflow: 1 already in queue >> awaiting acceptance >> >> From kgdb, >> (kgdb) p ((struct inpcb *)0xfffff8008f40cb10)->inp_inc >> $3 = {inc_flags = 0 '\0', inc_len = 0 '\0', inc_fibnum = 0, inc_ie = {ie_fport >> = 0, ie_lport = 10295, ie_dependfaddr = { >> ie46_foreign = {ia46_pad32 = {0, 0, 0}, ia46_addr4 = {s_addr = 0}}, >> ie6_foreign = {__u6_addr = { >> __u6_addr8 = '\0' , __u6_addr16 = {0, 0, 0, 0, 0, >> 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}}, >> ie_dependladdr = {ie46_local = {ia46_pad32 = {0, 0, 0}, ia46_addr4 = >> {s_addr = 0}}, ie6_local = {__u6_addr = { >> __u6_addr8 = '\0' , __u6_addr16 = {0, 0, 0, 0, 0, >> 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}}}} >> >> Here, ie_lport = 10295 which is in n/w byte order and converting it to host >> byte order, 10295 -> 0x2837 and swapping them gives us 0x3728 which is 14120. >> >> Now, use sockstat to find out what process is on that port: >> >> $ sockstat -l | grep 14120 >> >> cheers, >> Hiren > > -- > Julien Cigar > Belgian Biodiversity Platform (http://www.biodiversity.be) > PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0 > No trees were killed in the creation of this message. > However, many electrons were terribly inconvenienced. From owner-freebsd-net@FreeBSD.ORG Fri Oct 3 00:40:39 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA6DEC04 for ; Fri, 3 Oct 2014 00:40:39 +0000 (UTC) Received: from stargate.chelsio.com (99-65-72-228.uvs.sntcca.sbcglobal.net [99.65.72.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9A4C99CF for ; Fri, 3 Oct 2014 00:40:38 +0000 (UTC) Received: from nice.asicdesigners.com (nice.asicdesigners.com [10.192.160.7]) by stargate.chelsio.com (8.13.8/8.13.8) with ESMTP id s930eVMa017807 for ; Thu, 2 Oct 2014 17:40:31 -0700 Received: from NICE.asicdesigners.com ([fe80::51b2:ba95:9d72:babc]) by nice.asicdesigners.com ([fe80::51b2:ba95:9d72:babc%15]) with mapi id 14.02.0247.003; Thu, 2 Oct 2014 17:40:31 -0700 From: Hariprasad S To: "freebsd-net@freebsd.org" Subject: Detaching the slave from the lagg interface which has vlan on top of it, hits an panic Thread-Topic: Detaching the slave from the lagg interface which has vlan on top of it, hits an panic Thread-Index: Ac/eojBrX73E5zuoT86BWbsKBFP7+Q== Date: Fri, 3 Oct 2014 00:40:30 +0000 Message-ID: <26E3F92EC670BD429DB5CB319D773C137A8878@nice.asicdesigners.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.171.221] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Oct 2014 00:40:39 -0000 HI, Detaching the slave from the lagg interface which has vlan on top of it, hi= ts an panic. Kernel used: FreeBSD HEAD r272051 Is anyone aware of this issue? Steps to reproduce: 1) Created a lagg interface (lagg0) # ifconfig lagg0 create 2) Attach slaves to the lag interface # ifconfig lagg0 laggport cxl0 laggport cxl1 # ifconfig lagg0 up 3)Created a vlan interface over lagg0(lagg0.6) # ifconfig vlan10 create # ifconfig vlan 10 1.1.1.1/24 vlan 10 vlandev lagg0 # ifconfig vlan0 up 4) Ping the peer interface # ping 1.1.1.2 5)>Detached the active slave from lagg0. # ifconfig lagg0 -laggport cxl0 ------------------------------------------------------- Unread portion of the kernel message buffer: lock order reversal: (sleepable after non-sleepable) 1st 0xfffff800095d8408 if_lagg rmlock (if_lagg rmlock) @ /usr/src/sys/modul= es/if_lagg/../../net/if_lagg.c:1139 2nd 0xffffffff81aa7228 vlan_global (vlan_global) @ /usr/src/sys/net/if_vlan= .c:542 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0123668= 5e0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0123668690 witness_checkorder() at witness_checkorder+0xdc2/frame 0xfffffe0123668720 _sx_xlock() at _sx_xlock+0x75/frame 0xfffffe0123668760 vlan_iflladdr() at vlan_iflladdr+0x36/frame 0xfffffe0123668790 lagg_lladdr() at lagg_lladdr+0xee/frame 0xfffffe01236687c0 lagg_port_destroy() at lagg_port_destroy+0x1cd/frame 0xfffffe0123668810 lagg_ioctl() at lagg_ioctl+0xa23/frame 0xfffffe01236688f0 in_control() at in_control+0x30b/frame 0xfffffe0123668970 ifioctl() at ifioctl+0xba8/frame 0xfffffe0123668a30 kern_ioctl() at kern_ioctl+0x22b/frame 0xfffffe0123668a90 sys_ioctl() at sys_ioctl+0x13c/frame 0xfffffe0123668ae0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe0123668bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0123668bf0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip =3D 0x8011ced2a, rsp =3D 0x= 7fffffffe218, rbp =3D 0x7fffffffe290 --- panic: rm_rlock: wlock already held for if_lagg rmlock @ /usr/src/sys/modul= es/if_lagg/../../net/if_lagg.c:1325 cpuid =3D 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0123668= 320 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe01236683d0 vpanic() at vpanic+0x189/frame 0xfffffe0123668450 kassert_panic() at kassert_panic+0x198/frame 0xfffffe01236684e0 _rm_rlock_debug() at _rm_rlock_debug+0x1c3/frame 0xfffffe0123668520 lagg_transmit() at lagg_transmit+0x4d/frame 0xfffffe01236685a0 vlan_transmit() at vlan_transmit+0x14f/frame 0xfffffe01236685f0 ether_output() at ether_output+0x5b1/frame 0xfffffe0123668660 arprequest() at arprequest+0x287/frame 0xfffffe01236686d0 arp_ifinit() at arp_ifinit+0x59/frame 0xfffffe0123668700 if_setlladdr() at if_setlladdr+0x1fc/frame 0xfffffe0123668760 vlan_iflladdr() at vlan_iflladdr+0xa0/frame 0xfffffe0123668790 lagg_lladdr() at lagg_lladdr+0xee/frame 0xfffffe01236687c0 lagg_port_destroy() at lagg_port_destroy+0x1cd/frame 0xfffffe0123668810 lagg_ioctl() at lagg_ioctl+0xa23/frame 0xfffffe01236688f0 in_control() at in_control+0x30b/frame 0xfffffe0123668970 ifioctl() at ifioctl+0xba8/frame 0xfffffe0123668a30 kern_ioctl() at kern_ioctl+0x22b/frame 0xfffffe0123668a90 sys_ioctl() at sys_ioctl+0x13c/frame 0xfffffe0123668ae0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe0123668bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0123668bf0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip =3D 0x8011ced2a, rsp =3D 0x= 7fffffffe218, rbp =3D 0x7fffffffe290 --- KDB: enter: panic Thanks, Hariprasad From owner-freebsd-net@FreeBSD.ORG Fri Oct 3 01:40:23 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0A42CF2; Fri, 3 Oct 2014 01:40:23 +0000 (UTC) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5BD77FA1; Fri, 3 Oct 2014 01:40:23 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id x12so310913wgg.32 for ; Thu, 02 Oct 2014 18:40:21 -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=v1y17cnqfgc3OIBQQL+Gdp3gJcItKMWaHQuekQmu8bw=; b=ZWO1sdNIKBf9NSvve7w5xu2tYK0hJ081PxHt4c62ABG1H2D4O5sq0K3z7qAPhwAQ/m KcIbOpOyKXxqhVUcU3174L03hwQDXQNjBuHunoTe5zjoF1c0IhUizBR6CQYlS8eHyNE7 9XE6MxGYfe6UZqbPLme5ApRt5Om/rS2kFShis3N64tCAnGRqu/J+P8qdP3hjqIbmtp4r Wm43qqkS5NPOMbS6sCSm6ebvneSabR1WFlOx4gRLfLCJtbTpZH5cESCiCAc9SeMKQk9f hjCdjr7uP/tNB44x6eSb7kGBGBdLdanjewsaftMZva0uZgVYxoL+derQODICg5Ad20Jq FhEA== MIME-Version: 1.0 X-Received: by 10.181.11.133 with SMTP id ei5mr8708877wid.9.1412300421641; Thu, 02 Oct 2014 18:40:21 -0700 (PDT) Received: by 10.217.67.201 with HTTP; Thu, 2 Oct 2014 18:40:21 -0700 (PDT) In-Reply-To: <1577813.IPE4JfnhZd@ralph.baldwin.cx> References: <1410203348.1343.1.camel@bruno> <1410203965.1343.3.camel@bruno> <540E04AA.80806@vangyzen.net> <1577813.IPE4JfnhZd@ralph.baldwin.cx> Date: Thu, 2 Oct 2014 18:40:21 -0700 Message-ID: Subject: Re: ixgbe(4) spin lock held too long From: Jason Wolfe To: John Baldwin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net@freebsd.org, Eric van Gyzen X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Oct 2014 01:40:24 -0000 On Wed, Sep 10, 2014 at 8:24 AM, John Baldwin wrote: > On Monday, September 08, 2014 03:34:02 PM Eric van Gyzen wrote: > > On 09/08/2014 15:19, Sean Bruno wrote: > > > On Mon, 2014-09-08 at 12:09 -0700, Sean Bruno wrote: > > >> This sort of looks like the hardware failed to respond to us in time? > > >> Too busy? > > >> > > >> sean > > > > > > This seems to be affecting my 10/stable machines from 15Aug2014. > > > > > > Not a lot of churn in the code so I don't think this is new. The > > > afflicted machines, quite a few by my count, appear to have not been > > > super busy (pushing about 200 Mb/s). > > > > > > sean > > > > > >> panic: spin lock held too long > > >> > > >> GNU gdb 6.1.1 [FreeBSD] > > >> Copyright 2004 Free Software Foundation, Inc. > > >> GDB is free software, covered by the GNU General Public License, and > you > > >> are > > >> welcome to change it and/or distribute copies of it under certain > > >> conditions. > > >> Type "show copying" to see the conditions. > > >> There is absolutely no warranty for GDB. Type "show warranty" for > > >> details. > > >> This GDB was configured as "amd64-marcel-freebsd"... > > >> > > >> Unread portion of the kernel message buffer: > > >> spin lock 0xffffffff812a0400 (callout) held by 0xfffff800151fe000 (tid > > >> 100003) too long > > > > TID 100003 is usually a kernel idle thread, which would seem to indicate > > a dangling lock. Can you enable WITNESS (without WITNESS_SKIPSPIN) on > > this box? > > Also, do 'tid 100003' and 'bt' in kgdb to see what the thread holding the > lock > was doing. > > -- > John Baldwin Sorry for the delay, I've been hoping to catch a crash on one of our machines running the WITNESS kernel. Our luck seems to be in short supply, the machines running sans WITNESS crash in the same manner at a rate of 2/3 a day. I may have to grow the pool to catch this, but in the meantime here is the bt/tid. (kgdb) bt 1000003 #0 0xffffffff80ac39b8 in cpustop_handler () at /usr/src/sys/amd64/amd64/mp_machdep.c:1432 #1 0xffffffff80ac397f in ipi_nmi_handler () at /usr/src/sys/amd64/amd64/mp_machdep.c:1417 #2 0xffffffff80ad2d5a in trap (frame=0xffffffff81242830) at /usr/src/sys/amd64/amd64/trap.c:190 #3 0xffffffff80ab93c3 in nmi_calltrap () at /usr/src/sys/amd64/amd64/exception.S:505 #4 0xffffffff80734066 in callout_process (now=3278964590047193) at /usr/src/sys/kern/kern_timeout.c:487 (kgdb) tid 100003 [Switching to thread 40 (Thread 100003)]#0 0xffffffff80ac39b8 in cpustop_handler () at /usr/src/sys/amd64/amd64/mp_machdep.c:1432 1432 savectx(&stoppcbs[cpu]); From owner-freebsd-net@FreeBSD.ORG Fri Oct 3 08:01:56 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94CA969A; Fri, 3 Oct 2014 08:01:56 +0000 (UTC) Received: from relaygateway01.edpnet.net (relaygateway01.edpnet.net [212.71.1.210]) by mx1.freebsd.org (Postfix) with ESMTP id BD8FF6E8; Fri, 3 Oct 2014 08:01:54 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIGAB5XLlRNbXB9/2dsb2JhbABfgw5TWIMCx2wMh0sCgQYXAXuEAwEBAQMBAQIgBC8jEAsRAwECAQkTDgICDwUUERYOE4g2DAmoR48zhjoBF49EEQE/EQcGgnGBVAWGK5AFgkGBSYMCAYEsg0GRDoIggUU7LwGBDoE7AQEB X-IPAS-Result: AqIGAB5XLlRNbXB9/2dsb2JhbABfgw5TWIMCx2wMh0sCgQYXAXuEAwEBAQMBAQIgBC8jEAsRAwECAQkTDgICDwUUERYOE4g2DAmoR48zhjoBF49EEQE/EQcGgnGBVAWGK5AFgkGBSYMCAYEsg0GRDoIggUU7LwGBDoE7AQEB X-IronPort-AV: E=Sophos;i="5.04,645,1406584800"; d="scan'208";a="277900906" Received: from 77.109.112.125.adsl.dyn.edpnet.net (HELO mordor.lan) ([77.109.112.125]) by relaygateway01.edpnet.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Oct 2014 09:29:17 +0200 Date: Fri, 3 Oct 2014 10:01:50 +0200 From: Julien Cigar To: hiren panchasara Subject: Re: [jcigar@ulb.ac.be: Listen queue overflow: 8 already in queue awaiting acceptance] Message-ID: <20141003080150.GL29361@mordor.lan> References: <20141002164202.GI29361@mordor.lan> <20141002181958.GJ29361@mordor.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rBvYE4HrSVE32kP+" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-net@freebsd.org" , FreeBSD Stable Mailing List X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Oct 2014 08:01:56 -0000 --rBvYE4HrSVE32kP+ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 02, 2014 at 04:36:49PM -0700, hiren panchasara wrote: > On Thu, Oct 2, 2014 at 11:19 AM, Julien Cigar wrote: > > On Thu, Oct 02, 2014 at 10:24:13AM -0700, hiren panchasara wrote: > >> On Thu, Oct 2, 2014 at 9:42 AM, Julien Cigar wrote: > >> > sorry for cross-posting, I'm forwarding this as it seems that part of > >> > the problem is also related to: > >> > https://lists.freebsd.org/pipermail/freebsd-net/2014-September/03966= 4.html > >> > >> Umm, this looks like a different problem than the subject of this emai= l. > > > > yes and no, seems the same hardware (HP and igb) and I have also some > > "requests for mbufs denied" (https://dpaste.de/t8kJ/raw) without any > > reasons. I should add that the box hanged a week ago and I had to do a > > hard reboot, I have the feeling that it's somewhat related to this > > problem .. > > > I suggest you try to debug these 2 problems separately. Did you get a > chance to look at kgdb to find the culprit process as I suggested > below? I tried what you suggested, but I get a "No struct type named inpcb" Any idea ? :) >=20 > cheers, > Hiren > >> > > >> > I also wonder if something has been fixed in -STABLE in this area .. > >> > > >> > (please keep me in CC as I'm not subscribed on freebsd-net@ an > >> > freebsd-stable@) > >> > > >> > -- > >> > Julien Cigar > >> > Belgian Biodiversity Platform (http://www.biodiversity.be) > >> > PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0 > >> > No trees were killed in the creation of this message. > >> > However, many electrons were terribly inconvenienced. > >> > > >> > > >> > ---------- Forwarded message ---------- > >> > From: Julien Cigar > >> > To: freebsd-questions@freebsd.org > >> > Cc: > >> > Date: Thu, 2 Oct 2014 11:52:06 +0200 > >> > Subject: Listen queue overflow: 8 already in queue awaiting acceptan= ce > >> > Hello, > >> > > >> > I'm running 10-RELEASE on a HP Proliant DL160 Gen8 and I'm seeing the > >> > following in my kernel logs: > >> > sonewconn: pcb 0xfffff8010e561310: Listen queue overflow: 8 already = in > >> > queue awaiting acceptance > >> > >> This usually means the application is not keeping up with the incoming > >> connections. > >> > > >> > I already raised kern.ipc.soacceptqueue to 1024 and netstat -naA | = grep > >> > "fffff8010e561310" returns nothing > >> > >> This is the usual way of finding the culprit process. If this doesn't > >> return anything, it probably means that it is a short-lived process. > >> > >> Here is an example of what you could do: > >> > >> sonewconn: pcb 0xfffff8008f40cb10: Listen queue overflow: 1 already in= queue > >> awaiting acceptance > >> > >> From kgdb, > >> (kgdb) p ((struct inpcb *)0xfffff8008f40cb10)->inp_inc > >> $3 =3D {inc_flags =3D 0 '\0', inc_len =3D 0 '\0', inc_fibnum =3D 0, in= c_ie =3D {ie_fport > >> =3D 0, ie_lport =3D 10295, ie_dependfaddr =3D { > >> ie46_foreign =3D {ia46_pad32 =3D {0, 0, 0}, ia46_addr4 =3D {s_ad= dr =3D 0}}, > >> ie6_foreign =3D {__u6_addr =3D { > >> __u6_addr8 =3D '\0' , __u6_addr16 =3D {0, = 0, 0, 0, 0, > >> 0, 0, 0}, __u6_addr32 =3D {0, 0, 0, 0}}}}, > >> ie_dependladdr =3D {ie46_local =3D {ia46_pad32 =3D {0, 0, 0}, ia46= _addr4 =3D > >> {s_addr =3D 0}}, ie6_local =3D {__u6_addr =3D { > >> __u6_addr8 =3D '\0' , __u6_addr16 =3D {0, = 0, 0, 0, 0, > >> 0, 0, 0}, __u6_addr32 =3D {0, 0, 0, 0}}}}}} > >> > >> Here, ie_lport =3D 10295 which is in n/w byte order and converting it = to host > >> byte order, 10295 -> 0x2837 and swapping them gives us 0x3728 which is= 14120. > >> > >> Now, use sockstat to find out what process is on that port: > >> > >> $ sockstat -l | grep 14120 > >> > >> cheers, > >> Hiren > > > > -- > > Julien Cigar > > Belgian Biodiversity Platform (http://www.biodiversity.be) > > PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0 > > No trees were killed in the creation of this message. > > However, many electrons were terribly inconvenienced. --=20 Julien Cigar Belgian Biodiversity Platform (http://www.biodiversity.be) PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0 No trees were killed in the creation of this message. However, many electrons were terribly inconvenienced. --rBvYE4HrSVE32kP+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJULlfuAAoJEAi2KiTKQR5pFawP/3iWom25X33Tl/4aELt/ouph TkfTbXa50/tZmD3MwAHFLBsOHzp2eAy8r16gHDo/enduBEPsmi8FpANJL7uStH1g +/PEWrYz9/PTD/6en92JETGcYiYkMwZog1PljBoUscZcK/aGvOrNmPSFqniexUBP /1qRvDW5uCnIGHIOTZ2NZoBxFXeYBTiGc5ovE+n5K5b8GLalbqr6h+q2slbmC2Bt fwrLhSBAlscz/fqrLD/i8tZZHaQ5ZAaJUG6dFDiUk8eTqNwPQ7+SZJX6erN2ceAH zrUJhIEr3B6cr3UNlCCa/qCpbb6LqrMfRX6Hcx1IOU48P1qHVjJ9QW6xSYCAd3ky L8CNlAx95Qqbde8cUAEUa2AhtrJs7Aa0C7AItsxpfgBAPLNCnbRCeUw3JECFzIec jzcvkl8TolE0ut7SRqG7yE35D+37AzBsAZRT2kFuv7XODzd8+NsxcNNmd2waUM2D SM9fa1MFqffJ2arioXe6AJ4kASCwK7fB57d+sQI2/AJkfakSvwfh285+2uR+LNes ADLmHkl1uR47L6sTC906gwxnE6wyS10TjLGO6TwFCs15BiFtqS3VyRy9WGVzUmpo y874H893zIOuWTm1qtyPw+ylHDpV0U8htkO1DcvqXpeH8RePYDZHU+VgrWUo5JtJ I6G6D715ydd+cwwx3TBJ =CFZe -----END PGP SIGNATURE----- --rBvYE4HrSVE32kP+-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 3 08:17:09 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48E9FB52 for ; Fri, 3 Oct 2014 08:17:09 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C026A877 for ; Fri, 3 Oct 2014 08:17:08 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id s938H3Tw095972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Oct 2014 12:17:03 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id s938H3XV095971; Fri, 3 Oct 2014 12:17:03 +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, 3 Oct 2014 12:17:03 +0400 From: Gleb Smirnoff To: Hariprasad S Subject: Re: Detaching the slave from the lagg interface which has vlan on top of it, hits an panic Message-ID: <20141003081703.GA73266@FreeBSD.org> References: <26E3F92EC670BD429DB5CB319D773C137A8878@nice.asicdesigners.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26E3F92EC670BD429DB5CB319D773C137A8878@nice.asicdesigners.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Oct 2014 08:17:09 -0000 On Fri, Oct 03, 2014 at 12:40:30AM +0000, Hariprasad S wrote: H> HI, H> H> Detaching the slave from the lagg interface which has vlan on top of it, hits an panic. H> Kernel used: FreeBSD HEAD r272051 H> H> Is anyone aware of this issue? Yes, melifaro@ demonstrated it recently. No fix available yet, however. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Oct 3 09:53:29 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 207FD12B; Fri, 3 Oct 2014 09:53:29 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AF70E30C; Fri, 3 Oct 2014 09:53:28 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XZvYu-0004c0-Lo; Fri, 03 Oct 2014 09:37:52 +0400 Message-ID: <542E71D3.6000500@FreeBSD.org> Date: Fri, 03 Oct 2014 13:52:19 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Hariprasad S , "freebsd-net@freebsd.org" Subject: Re: Detaching the slave from the lagg interface which has vlan on top of it, hits an panic References: <26E3F92EC670BD429DB5CB319D773C137A8878@nice.asicdesigners.com> In-Reply-To: <26E3F92EC670BD429DB5CB319D773C137A8878@nice.asicdesigners.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Oct 2014 09:53:29 -0000 On 03.10.2014 04:40, Hariprasad S wrote: > HI, > > Detaching the slave from the lagg interface which has vlan on top of it, hits an panic. > Kernel used: FreeBSD HEAD r272051 > > Is anyone aware of this issue? Yes. What is happening here: We acquire lagg WLOCK to set new link layer address (due to "master" interface change). We propagate this change to vlans on top if lagg (or to lagg itself). Then we need to send gratuitous ARP for each UP interface, so we have to acquire lagg read lock to actually transmit this frame.. We can fix this particular case, but I think it should be done more generic way via introducing one or more netisr(9) slow path queues and making sure "every" locally-originated packet is queued instead of being transmitted directly. Previous proposal: https://lists.freebsd.org/pipermail/freebsd-hackers/2014-January/044121.html It looks like we should return to the discussion. > > Steps to reproduce: > 1) Created a lagg interface (lagg0) > # ifconfig lagg0 create > > 2) Attach slaves to the lag interface > # ifconfig lagg0 laggport cxl0 laggport cxl1 > # ifconfig lagg0 up > > 3)Created a vlan interface over lagg0(lagg0.6) > # ifconfig vlan10 create > # ifconfig vlan 10 1.1.1.1/24 vlan 10 vlandev lagg0 > # ifconfig vlan0 up > > 4) Ping the peer interface > # ping 1.1.1.2 > > 5)>Detached the active slave from lagg0. > # ifconfig lagg0 -laggport cxl0 > > ------------------------------------------------------- > Unread portion of the kernel message buffer: > lock order reversal: (sleepable after non-sleepable) > 1st 0xfffff800095d8408 if_lagg rmlock (if_lagg rmlock) @ /usr/src/sys/modules/if_lagg/../../net/if_lagg.c:1139 > 2nd 0xffffffff81aa7228 vlan_global (vlan_global) @ /usr/src/sys/net/if_vlan.c:542 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe01236685e0 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0123668690 > witness_checkorder() at witness_checkorder+0xdc2/frame 0xfffffe0123668720 > _sx_xlock() at _sx_xlock+0x75/frame 0xfffffe0123668760 > vlan_iflladdr() at vlan_iflladdr+0x36/frame 0xfffffe0123668790 > lagg_lladdr() at lagg_lladdr+0xee/frame 0xfffffe01236687c0 > lagg_port_destroy() at lagg_port_destroy+0x1cd/frame 0xfffffe0123668810 > lagg_ioctl() at lagg_ioctl+0xa23/frame 0xfffffe01236688f0 > in_control() at in_control+0x30b/frame 0xfffffe0123668970 > ifioctl() at ifioctl+0xba8/frame 0xfffffe0123668a30 > kern_ioctl() at kern_ioctl+0x22b/frame 0xfffffe0123668a90 > sys_ioctl() at sys_ioctl+0x13c/frame 0xfffffe0123668ae0 > amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe0123668bf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0123668bf0 > --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011ced2a, rsp = 0x7fffffffe218, rbp = 0x7fffffffe290 --- > panic: rm_rlock: wlock already held for if_lagg rmlock @ /usr/src/sys/modules/if_lagg/../../net/if_lagg.c:1325 > cpuid = 1 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0123668320 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe01236683d0 > vpanic() at vpanic+0x189/frame 0xfffffe0123668450 > kassert_panic() at kassert_panic+0x198/frame 0xfffffe01236684e0 > _rm_rlock_debug() at _rm_rlock_debug+0x1c3/frame 0xfffffe0123668520 > lagg_transmit() at lagg_transmit+0x4d/frame 0xfffffe01236685a0 > vlan_transmit() at vlan_transmit+0x14f/frame 0xfffffe01236685f0 > ether_output() at ether_output+0x5b1/frame 0xfffffe0123668660 > arprequest() at arprequest+0x287/frame 0xfffffe01236686d0 > arp_ifinit() at arp_ifinit+0x59/frame 0xfffffe0123668700 > if_setlladdr() at if_setlladdr+0x1fc/frame 0xfffffe0123668760 > vlan_iflladdr() at vlan_iflladdr+0xa0/frame 0xfffffe0123668790 > lagg_lladdr() at lagg_lladdr+0xee/frame 0xfffffe01236687c0 > lagg_port_destroy() at lagg_port_destroy+0x1cd/frame 0xfffffe0123668810 > lagg_ioctl() at lagg_ioctl+0xa23/frame 0xfffffe01236688f0 > in_control() at in_control+0x30b/frame 0xfffffe0123668970 > ifioctl() at ifioctl+0xba8/frame 0xfffffe0123668a30 > kern_ioctl() at kern_ioctl+0x22b/frame 0xfffffe0123668a90 > sys_ioctl() at sys_ioctl+0x13c/frame 0xfffffe0123668ae0 > amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe0123668bf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0123668bf0 > --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011ced2a, rsp = 0x7fffffffe218, rbp = 0x7fffffffe290 --- > KDB: enter: panic > > > Thanks, > Hariprasad > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Oct 3 10:05:54 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA382593; Fri, 3 Oct 2014 10:05:54 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D2935F5; Fri, 3 Oct 2014 10:05:53 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id s93A456c096566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Oct 2014 14:04:05 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id s93A45Fn096565; Fri, 3 Oct 2014 14:04:05 +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, 3 Oct 2014 14:04:05 +0400 From: Gleb Smirnoff To: "Alexander V. Chernikov" Subject: Re: Detaching the slave from the lagg interface which has vlan on top of it, hits an panic Message-ID: <20141003100405.GB73266@glebius.int.ru> References: <26E3F92EC670BD429DB5CB319D773C137A8878@nice.asicdesigners.com> <542E71D3.6000500@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <542E71D3.6000500@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-net@freebsd.org" , Hariprasad S X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Oct 2014 10:05:54 -0000 On Fri, Oct 03, 2014 at 01:52:19PM +0400, Alexander V. Chernikov wrote: A> On 03.10.2014 04:40, Hariprasad S wrote: A> > HI, A> > A> > Detaching the slave from the lagg interface which has vlan on top of it, hits an panic. A> > Kernel used: FreeBSD HEAD r272051 A> > A> > Is anyone aware of this issue? A> Yes. What is happening here: A> We acquire lagg WLOCK to set new link layer address (due to "master" A> interface change). A> We propagate this change to vlans on top if lagg (or to lagg itself). A> Then we need to send gratuitous ARP for each UP interface, so we have to A> acquire lagg read lock to actually transmit this frame.. A> A> We can fix this particular case, but I think it should be done more A> generic way via introducing one or more netisr(9) slow path queues A> and making sure "every" locally-originated packet is queued instead of A> being transmitted directly. A> A> Previous proposal: A> https://lists.freebsd.org/pipermail/freebsd-hackers/2014-January/044121.html A> It looks like we should return to the discussion. I agree with Alexander here. However, he is quite aggresive on the question which packets should qualify for slow path :) Well, this is a matter to discuss, but the overall mechanism is needed. And gratuitous ARPs are definitely qualified for that. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Oct 3 13:17:02 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 441F79BA for ; Fri, 3 Oct 2014 13:17:02 +0000 (UTC) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6BB25BAD for ; Fri, 3 Oct 2014 13:17:00 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id ge10so1019141lab.10 for ; Fri, 03 Oct 2014 06:16:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=B1eFBJdDDThIEVdYkxdEiOh8QmeNUIj48gSb0GoGm58=; b=LZwbdHHvBTEN3Q4x+J2JCOdVbgFeNkhXYtbNx+COm4OJdqtwLWGUXIy4xUvipTRNBJ 6PskEHlxIWPJClxwmN5OYbdyPrRU69cOIuSWAZbbIcO6IvdXvvbgGDVw3Ta4cvfibRhZ J8chcRmK55DW2UT1Igv01lkEQavDUjdcLGanYoVuW67ebrJ6sHUSMkNhyfYU021YVj56 0h1e9JwsYcELFMsHVvxRtgN4yBQaKJeE3fu/bl19byrqA6wKNGXtDwrRJZMLJvZsUek2 VDMCBqp4Mbb9FCoFabIlF/HHgtSb1cO6aPvbomChygD0In0o5pa6VB/WorBcRIa6TpMV KgMg== X-Gm-Message-State: ALoCoQm0aMM3Bkncb0e0lJssitdErUU+cYWS+K6oHD0mgq1+exz0R9XFBFsBnxPiMX1LW8JlfOc0 X-Received: by 10.112.166.35 with SMTP id zd3mr5571896lbb.3.1412342213008; Fri, 03 Oct 2014 06:16:53 -0700 (PDT) Received: from FRI2JCHARBON-M1.local ([217.30.88.7]) by mx.google.com with ESMTPSA id u6sm2686307lag.19.2014.10.03.06.16.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Oct 2014 06:16:52 -0700 (PDT) Message-ID: <542EA1C9.6080907@freebsd.org> Date: Fri, 03 Oct 2014 15:16:57 +0200 From: Julien Charbon User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: TCP stack lock contention with short-lived connections References: <537F39DF.1090900@verisign.com> In-Reply-To: <537F39DF.1090900@verisign.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IArnHQlKn5sngVOmi6i0lvig0oDVojeVN" Cc: "De La Gueronniere, Marc" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Oct 2014 13:17:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IArnHQlKn5sngVOmi6i0lvig0oDVojeVN Content-Type: multipart/mixed; boundary="------------090402000607020404040507" This is a multi-part message in MIME format. --------------090402000607020404040507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, On 23/05/14 14:06, Julien Charbon wrote: > On 27/02/14 11:32, Julien Charbon wrote: >> On 07/11/13 14:55, Julien Charbon wrote: >>> On Mon, 04 Nov 2013 22:21:04 +0100, Julien Charbon >>> wrote: >>>> I have put technical and how-to-repeat details in below PR: >>>> >>>> kern/183659: TCP stack lock contention with short-lived connections >>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D183659 >>>> >>>> We are currently working on this performance improvement effort; = it >>>> will impact only the TCP locking strategy not the TCP stack logic >>>> itself. We will share on freebsd-net the patches we made for >>>> reviewing and improvement propositions; anyway this change might al= so >>>> require enough eyeballs to avoid tricky race conditions introduction= >>>> in TCP stack. As usual, first a follow-up on TCP short-lived connections improvement progress: Thanks to jhb (committer) and adrian, hiren, jhb, Mike Bentkofsky (reviewers) the SYN reception optimization has been pushed in HEAD: "In tcp_input(), don't acquire the pcbinfo global write lock for SYN packets targeting a listening socket" http://svnweb.freebsd.org/base?view=3Drevision&revision=3D271119 Next, two related patches are remaining: - The first one is actually a race condition fix, thanks to Marc for spotting it. This race has been introduced with our first TCP timewait change: http://svnweb.freebsd.org/base?view=3Drevision&revision=3D264321 The proposed fix is currently under review (see also joined patch): https://reviews.freebsd.org/D826 Note: The original change has not been MFC'ed, thus this race condition is only in HEAD. - The second one being (see also joined patch): https://github.com/verisign/freebsd/commit/f4c11c6b678195515bbab8bb2825fa= 5222ed3a58 Nothing new here (just read previous emails in this thread for details). The patch just becomes easier to read with time. As we didn't find any issues with it, following a proposition from Marc we are going to start a specific code review process: #1 Write down all the current INP_INFO_WLOCK locking rules, especially all the non-obvious ones #2 Check that all these rules are still respected with the proposed improvement It will permit an in depth code review, and to get all pcbinfo/inpcb related locking rules well described. -- Julien --------------090402000607020404040507 Content-Type: text/plain; charset=UTF-8; name="fix-tcptw-race.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="fix-tcptw-race.patch" =46rom 91a1a400f50aad0e2304d655a78286d9285efbc5 Mon Sep 17 00:00:00 2001 From: Julien Charbon Date: Thu, 4 Sep 2014 09:40:21 +0200 Subject: [PATCH] [tcp-scale] Fix a race condition in TCP timewait between= tcp_tw_2msl_reuse() and tcp_tw_2msl_scan() that drives (at least) timewa= it timeout cancellation. Also simplify implementation by holding inpcb reference and removing tw_pcbref() and tw_pcbrele(). --- sys/netinet/tcp_timewait.c | 133 ++++++++++++++++++++++++++++-----------= ------ sys/netinet/tcp_usrreq.c | 15 +++++ sys/netinet/tcp_var.h | 1 - 3 files changed, 99 insertions(+), 50 deletions(-) diff --git a/sys/netinet/tcp_timewait.c b/sys/netinet/tcp_timewait.c index 33555d9..9c17655 100644 --- a/sys/netinet/tcp_timewait.c +++ b/sys/netinet/tcp_timewait.c @@ -49,7 +49,6 @@ __FBSDID("$FreeBSD$"); #include #include #include -#include =20 #include =20 @@ -101,6 +100,11 @@ static int maxtcptw; * currently in the TIME_WAIT state. The queue pointers, including the * queue pointers in each tcptw structure, are protected using the globa= l * timewait lock, which must be held over queue iteration and modificati= on. + * + * Rules on tcptw usage: + * - a inpcb is always freed _after_ its tcptw + * - a tcptw relies on its inpcb reference counting for memory stabilit= y + * - a tcptw is valid only under its inpcb locked */ static VNET_DEFINE(TAILQ_HEAD(, tcptw), twq_2msl); #define V_twq_2msl VNET(twq_2msl) @@ -124,32 +128,6 @@ static void tcp_tw_2msl_reset(struct tcptw *, int); static void tcp_tw_2msl_stop(struct tcptw *, int); static int tcp_twrespond(struct tcptw *, int); =20 -/* - * tw_pcbref() bumps the reference count on an tw in order to maintain - * stability of an tw pointer despite the tw lock being released. - */ -static void -tw_pcbref(struct tcptw *tw) -{ - - KASSERT(tw->tw_refcount > 0, ("%s: refcount 0", __func__)); - refcount_acquire(&tw->tw_refcount); -} - -/* - * Drop a refcount on an tw elevated using tw_pcbref(). - */ -static int -tw_pcbrele(struct tcptw *tw) -{ - - KASSERT(tw->tw_refcount > 0, ("%s: refcount 0", __func__)); - if (!refcount_release(&tw->tw_refcount)) - return (0); - uma_zfree(V_tcptw_zone, tw); - return (1); -} - static int tcptw_auto_size(void) { @@ -289,7 +267,11 @@ tcp_twstart(struct tcpcb *tp) } } tw->tw_inpcb =3D inp; - refcount_init(&tw->tw_refcount, 1); + /* + * The tcptw will hold a reference on its inpcb until tcp_twclose + * is called + */ + in_pcbref(inp); /* Reference from tw */ =20 /* * Recover last window size sent. @@ -479,7 +461,6 @@ tcp_twclose(struct tcptw *tw, int reuse) INP_INFO_WLOCK_ASSERT(&V_tcbinfo); /* in_pcbfree() */ INP_WLOCK_ASSERT(inp); =20 - tw->tw_inpcb =3D NULL; tcp_tw_2msl_stop(tw, reuse); inp->inp_ppcb =3D NULL; in_pcbdrop(inp); @@ -509,8 +490,13 @@ tcp_twclose(struct tcptw *tw, int reuse) */ INP_WUNLOCK(inp); } - } else + } else { + /* + * The socket has been already cleaned-up for us, only free the + * inpcb. + */ in_pcbfree(inp); + } TCPSTAT_INC(tcps_closed); } =20 @@ -641,36 +627,70 @@ tcp_tw_2msl_reset(struct tcptw *tw, int rearm) static void tcp_tw_2msl_stop(struct tcptw *tw, int reuse) { + struct ucred *cred; + struct inpcb *inp; + int released; =20 INP_INFO_WLOCK_ASSERT(&V_tcbinfo); =20 TW_WLOCK(V_tw_lock); + inp =3D tw->tw_inpcb; + tw->tw_inpcb =3D NULL; + TAILQ_REMOVE(&V_twq_2msl, tw, tw_2msl); - crfree(tw->tw_cred); + cred =3D tw->tw_cred; tw->tw_cred =3D NULL; TW_WUNLOCK(V_tw_lock); =20 + if (cred !=3D NULL) + crfree(cred); + + released =3D in_pcbrele_wlocked(inp); + KASSERT(!released, ("%s: inp should not be released here", __func__)); + if (!reuse) - tw_pcbrele(tw); + uma_zfree(V_tcptw_zone, tw); } =20 struct tcptw * tcp_tw_2msl_reuse(void) { struct tcptw *tw; + struct inpcb *inp; =20 INP_INFO_WLOCK_ASSERT(&V_tcbinfo); =20 - TW_WLOCK(V_tw_lock); - tw =3D TAILQ_FIRST(&V_twq_2msl); - if (tw =3D=3D NULL) { - TW_WUNLOCK(V_tw_lock); - return NULL; - } - TW_WUNLOCK(V_tw_lock); + for (;;) { + TW_RLOCK(V_tw_lock); + tw =3D TAILQ_FIRST(&V_twq_2msl); + if (tw =3D=3D NULL) { + TW_RUNLOCK(V_tw_lock); + break; + } + KASSERT(tw->tw_inpcb !=3D NULL, ("%s: tw->tw_inpcb =3D=3D NULL", + __func__)); =20 - INP_WLOCK(tw->tw_inpcb); - tcp_twclose(tw, 1); + inp =3D tw->tw_inpcb; + in_pcbref(inp); + TW_RUNLOCK(V_tw_lock); + + INP_WLOCK(inp); + tw =3D intotw(inp); + if (in_pcbrele_wlocked(inp)) { + KASSERT(tw =3D=3D NULL, ("%s: held last inp reference but " + "tw not NULL", __func__)); + continue; + } + + if (tw =3D=3D NULL) { + /* tcp_twclose() has already been called */ + INP_WUNLOCK(inp); + continue; + } + + tcp_twclose(tw, 1); + break; + } =20 return (tw); } @@ -679,6 +699,7 @@ void tcp_tw_2msl_scan(void) { struct tcptw *tw; + struct inpcb *inp; =20 for (;;) { TW_RLOCK(V_tw_lock); @@ -687,24 +708,38 @@ tcp_tw_2msl_scan(void) TW_RUNLOCK(V_tw_lock); break; } - tw_pcbref(tw); + KASSERT(tw->tw_inpcb !=3D NULL, ("%s: tw->tw_inpcb =3D=3D NULL", + __func__)); + + inp =3D tw->tw_inpcb; + in_pcbref(inp); TW_RUNLOCK(V_tw_lock); =20 - /* Close timewait state */ if (INP_INFO_TRY_WLOCK(&V_tcbinfo)) { - if (tw_pcbrele(tw)) { + + INP_WLOCK(inp); + tw =3D intotw(inp); + if (in_pcbrele_wlocked(inp)) { + KASSERT(tw =3D=3D NULL, ("%s: held last inp " + "reference but tw not NULL", __func__)); + INP_INFO_WUNLOCK(&V_tcbinfo); + continue; + } + + if (tw =3D=3D NULL) { + /* tcp_twclose() has already been called */ + INP_WUNLOCK(inp); INP_INFO_WUNLOCK(&V_tcbinfo); continue; } =20 - KASSERT(tw->tw_inpcb !=3D NULL, - ("%s: tw->tw_inpcb =3D=3D NULL", __func__)); - INP_WLOCK(tw->tw_inpcb); tcp_twclose(tw, 0); INP_INFO_WUNLOCK(&V_tcbinfo); } else { - /* INP_INFO lock is busy; continue later. */ - tw_pcbrele(tw); + /* INP_INFO lock is busy, continue later. */ + INP_WLOCK(inp); + if (!in_pcbrele_wlocked(inp)) + INP_WUNLOCK(inp); break; } } diff --git a/sys/netinet/tcp_usrreq.c b/sys/netinet/tcp_usrreq.c index 22a160c..908afa2 100644 --- a/sys/netinet/tcp_usrreq.c +++ b/sys/netinet/tcp_usrreq.c @@ -183,6 +183,21 @@ tcp_detach(struct socket *so, struct inpcb *inp) * present until timewait ends. * * XXXRW: Would it be cleaner to free the tcptw here? + * + * Astute question indeed, from twtcp perspective there are + * three cases to consider: + * + * #1 tcp_detach is called at tcptw creation time by + * tcp_twstart, then do not discard the newly created tcptw + * and leave inpcb present until timewait ends + * #2 tcp_detach is called at timewait end (or reuse) by + * tcp_twclose, then the tcptw has already been discarded + * and inpcb is freed here + * #3 tcp_detach is called() after timewait ends (or reuse) + * (e.g. by soclose), then tcptw has already been discarded + * and inpcb is freed here + * + * In all three cases the tcptw should not be freed here. */ if (inp->inp_flags & INP_DROPPED) { KASSERT(tp =3D=3D NULL, ("tcp_detach: INP_TIMEWAIT && " diff --git a/sys/netinet/tcp_var.h b/sys/netinet/tcp_var.h index c2298fc..93e1b62 100644 --- a/sys/netinet/tcp_var.h +++ b/sys/netinet/tcp_var.h @@ -349,7 +349,6 @@ struct tcptw { u_int t_starttime; int tw_time; TAILQ_ENTRY(tcptw) tw_2msl; - u_int tw_refcount; /* refcount */ }; =20 #define intotcpcb(ip) ((struct tcpcb *)(ip)->inp_ppcb) --------------090402000607020404040507 Content-Type: text/plain; charset=UTF-8; name="tcp-scale-pcbinfo.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="tcp-scale-pcbinfo.patch" =46rom f4c11c6b678195515bbab8bb2825fa5222ed3a58 Mon Sep 17 00:00:00 2001 From: Julien Charbon Date: Fri, 28 Mar 2014 15:36:52 +0100 Subject: [PATCH] [tcp-scale] Introduce the INP_LIST global mutex for protecting pcbinfo global structures. Then use INP_INFO_RLOCK in critic= al paths to increase TCP processing parallelism, and use INP_INFO_WLOCK in = full INPs iteration loops. Julien's review: - Fix INP_INFO_WLOCK assertions - Fixing comments - Rebased on svn path=3D/head/; revision=3D272099 --- sys/dev/cxgb/ulp/tom/cxgb_cpl_io.c | 28 +++++----- sys/dev/cxgb/ulp/tom/cxgb_listen.c | 14 ++--- sys/dev/cxgbe/tom/t4_connect.c | 4 +- sys/dev/cxgbe/tom/t4_cpl_io.c | 20 +++---- sys/dev/cxgbe/tom/t4_listen.c | 10 ++-- sys/netinet/in_pcb.c | 43 ++++++++++++--- sys/netinet/in_pcb.h | 73 ++++++++++++++++++------- sys/netinet/tcp_input.c | 108 ++++++++++++++++++-------------= ------ sys/netinet/tcp_subr.c | 40 +++++++------- sys/netinet/tcp_syncache.c | 4 +- sys/netinet/tcp_timer.c | 40 +++++++------- sys/netinet/tcp_timewait.c | 24 ++++----- sys/netinet/tcp_usrreq.c | 40 +++++++------- sys/netinet/toecore.c | 6 +-- sys/netinet6/in6_pcb.c | 4 +- 15 files changed, 261 insertions(+), 197 deletions(-) diff --git a/sys/dev/cxgb/ulp/tom/cxgb_cpl_io.c b/sys/dev/cxgb/ulp/tom/cx= gb_cpl_io.c index a86bf72..f28c83d 100644 --- a/sys/dev/cxgb/ulp/tom/cxgb_cpl_io.c +++ b/sys/dev/cxgb/ulp/tom/cxgb_cpl_io.c @@ -639,7 +639,7 @@ t3_send_fin(struct toedev *tod, struct tcpcb *tp) unsigned int tid =3D toep->tp_tid; #endif =20 - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); INP_WLOCK_ASSERT(inp); =20 CTR4(KTR_CXGB, "%s: tid %d, toep %p, flags %x", __func__, tid, toep, @@ -925,12 +925,12 @@ do_act_open_rpl(struct sge_qset *qs, struct rsp_des= c *r, struct mbuf *m) =20 rc =3D act_open_rpl_status_to_errno(s); if (rc !=3D EAGAIN) - INP_INFO_WLOCK(&V_tcbinfo); + INP_INFO_RLOCK(&V_tcbinfo); INP_WLOCK(inp); toe_connect_failed(tod, inp, rc); toepcb_release(toep); /* unlocks inp */ if (rc !=3D EAGAIN) - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); =20 m_freem(m); return (0); @@ -1061,7 +1061,7 @@ send_reset(struct toepcb *toep) struct adapter *sc =3D tod->tod_softc; struct mbuf *m; =20 - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); INP_WLOCK_ASSERT(inp); =20 CTR4(KTR_CXGB, "%s: tid %d, toep %p (%x)", __func__, tid, toep, @@ -1172,12 +1172,12 @@ do_rx_data(struct sge_qset *qs, struct rsp_desc *= r, struct mbuf *m) SOCKBUF_UNLOCK(so_rcv); INP_WUNLOCK(inp); =20 - INP_INFO_WLOCK(&V_tcbinfo); + INP_INFO_RLOCK(&V_tcbinfo); INP_WLOCK(inp); tp =3D tcp_drop(tp, ECONNRESET); if (tp) INP_WUNLOCK(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); =20 m_freem(m); return (0); @@ -1222,7 +1222,7 @@ do_peer_close(struct sge_qset *qs, struct rsp_desc = *r, struct mbuf *m) struct tcpcb *tp; struct socket *so; =20 - INP_INFO_WLOCK(&V_tcbinfo); + INP_INFO_RLOCK(&V_tcbinfo); INP_WLOCK(inp); tp =3D intotcpcb(inp); =20 @@ -1250,7 +1250,7 @@ do_peer_close(struct sge_qset *qs, struct rsp_desc = *r, struct mbuf *m) case TCPS_FIN_WAIT_2: tcp_twstart(tp); INP_UNLOCK_ASSERT(inp); /* safe, we have a ref on the inp */ - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); =20 INP_WLOCK(inp); toepcb_release(toep); /* no more CPLs expected */ @@ -1264,7 +1264,7 @@ do_peer_close(struct sge_qset *qs, struct rsp_desc = *r, struct mbuf *m) =20 done: INP_WUNLOCK(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); =20 m_freem(m); return (0); @@ -1285,7 +1285,7 @@ do_close_con_rpl(struct sge_qset *qs, struct rsp_de= sc *r, struct mbuf *m) struct tcpcb *tp; struct socket *so; =20 - INP_INFO_WLOCK(&V_tcbinfo); + INP_INFO_RLOCK(&V_tcbinfo); INP_WLOCK(inp); tp =3D intotcpcb(inp); =20 @@ -1303,7 +1303,7 @@ do_close_con_rpl(struct sge_qset *qs, struct rsp_de= sc *r, struct mbuf *m) tcp_twstart(tp); release: INP_UNLOCK_ASSERT(inp); /* safe, we have a ref on the inp */ - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); =20 INP_WLOCK(inp); toepcb_release(toep); /* no more CPLs expected */ @@ -1328,7 +1328,7 @@ do_close_con_rpl(struct sge_qset *qs, struct rsp_de= sc *r, struct mbuf *m) =20 done: INP_WUNLOCK(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); =20 m_freem(m); return (0); @@ -1489,7 +1489,7 @@ do_abort_req(struct sge_qset *qs, struct rsp_desc *= r, struct mbuf *m) return (do_abort_req_synqe(qs, r, m)); =20 inp =3D toep->tp_inp; - INP_INFO_WLOCK(&V_tcbinfo); /* for tcp_close */ + INP_INFO_RLOCK(&V_tcbinfo); /* for tcp_close */ INP_WLOCK(inp); =20 tp =3D intotcpcb(inp); @@ -1523,7 +1523,7 @@ do_abort_req(struct sge_qset *qs, struct rsp_desc *= r, struct mbuf *m) INP_WLOCK(inp); /* re-acquire */ toepcb_release(toep); /* no more CPLs expected */ } - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); =20 send_abort_rpl(tod, tid, qset); m_freem(m); diff --git a/sys/dev/cxgb/ulp/tom/cxgb_listen.c b/sys/dev/cxgb/ulp/tom/cx= gb_listen.c index 94a219b..631899d 100644 --- a/sys/dev/cxgb/ulp/tom/cxgb_listen.c +++ b/sys/dev/cxgb/ulp/tom/cxgb_listen.c @@ -554,11 +554,11 @@ do_pass_accept_req(struct sge_qset *qs, struct rsp_= desc *r, struct mbuf *m) REJECT_PASS_ACCEPT(); /* no l2te, or ifp mismatch */ } =20 - INP_INFO_WLOCK(&V_tcbinfo); + INP_INFO_RLOCK(&V_tcbinfo); =20 /* Don't offload if the 4-tuple is already in use */ if (toe_4tuple_check(&inc, &th, ifp) !=3D 0) { - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); REJECT_PASS_ACCEPT(); } =20 @@ -571,7 +571,7 @@ do_pass_accept_req(struct sge_qset *qs, struct rsp_de= sc *r, struct mbuf *m) * resources tied to this listen context. */ INP_WUNLOCK(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); REJECT_PASS_ACCEPT(); } so =3D inp->inp_socket; @@ -713,7 +713,7 @@ do_pass_establish(struct sge_qset *qs, struct rsp_des= c *r, struct mbuf *m) KASSERT(qs->idx =3D=3D synqe->qset, ("%s qset mismatch %d %d", __func__, qs->idx, synqe->qset)); =20 - INP_INFO_WLOCK(&V_tcbinfo); /* for syncache_expand */ + INP_INFO_RLOCK(&V_tcbinfo); /* for syncache_expand */ INP_WLOCK(inp); =20 if (__predict_false(inp->inp_flags & INP_DROPPED)) { @@ -727,7 +727,7 @@ do_pass_establish(struct sge_qset *qs, struct rsp_des= c *r, struct mbuf *m) ("%s: listen socket dropped but tid %u not aborted.", __func__, tid)); INP_WUNLOCK(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); m_freem(m); return (0); } @@ -743,7 +743,7 @@ do_pass_establish(struct sge_qset *qs, struct rsp_des= c *r, struct mbuf *m) reset: t3_send_reset_synqe(tod, synqe); INP_WUNLOCK(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); m_freem(m); return (0); } @@ -775,7 +775,7 @@ do_pass_establish(struct sge_qset *qs, struct rsp_des= c *r, struct mbuf *m) inp =3D release_lctx(td, lctx); if (inp) INP_WUNLOCK(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); release_synqe(synqe); =20 m_freem(m); diff --git a/sys/dev/cxgbe/tom/t4_connect.c b/sys/dev/cxgbe/tom/t4_connec= t.c index 9973fa5..718f62a 100644 --- a/sys/dev/cxgbe/tom/t4_connect.c +++ b/sys/dev/cxgbe/tom/t4_connect.c @@ -208,12 +208,12 @@ do_act_open_rpl(struct sge_iq *iq, const struct rss= _header *rss, =20 rc =3D act_open_rpl_status_to_errno(status); if (rc !=3D EAGAIN) - INP_INFO_WLOCK(&V_tcbinfo); + INP_INFO_RLOCK(&V_tcbinfo); INP_WLOCK(inp); toe_connect_failed(tod, inp, rc); final_cpl_received(toep); /* unlocks inp */ if (rc !=3D EAGAIN) - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); =20 return (0); } diff --git a/sys/dev/cxgbe/tom/t4_cpl_io.c b/sys/dev/cxgbe/tom/t4_cpl_io.= c index f18e0c7..f0e9b0a 100644 --- a/sys/dev/cxgbe/tom/t4_cpl_io.c +++ b/sys/dev/cxgbe/tom/t4_cpl_io.c @@ -1059,7 +1059,7 @@ do_peer_close(struct sge_iq *iq, const struct rss_h= eader *rss, struct mbuf *m) =20 KASSERT(toep->tid =3D=3D tid, ("%s: toep tid mismatch", __func__)); =20 - INP_INFO_WLOCK(&V_tcbinfo); + INP_INFO_RLOCK(&V_tcbinfo); INP_WLOCK(inp); tp =3D intotcpcb(inp); =20 @@ -1113,7 +1113,7 @@ do_peer_close(struct sge_iq *iq, const struct rss_h= eader *rss, struct mbuf *m) case TCPS_FIN_WAIT_2: tcp_twstart(tp); INP_UNLOCK_ASSERT(inp); /* safe, we have a ref on the inp */ - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); =20 INP_WLOCK(inp); final_cpl_received(toep); @@ -1125,7 +1125,7 @@ do_peer_close(struct sge_iq *iq, const struct rss_h= eader *rss, struct mbuf *m) } done: INP_WUNLOCK(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); return (0); } =20 @@ -1152,7 +1152,7 @@ do_close_con_rpl(struct sge_iq *iq, const struct rs= s_header *rss, KASSERT(m =3D=3D NULL, ("%s: wasn't expecting payload", __func__)); KASSERT(toep->tid =3D=3D tid, ("%s: toep tid mismatch", __func__)); =20 - INP_INFO_WLOCK(&V_tcbinfo); + INP_INFO_RLOCK(&V_tcbinfo); INP_WLOCK(inp); tp =3D intotcpcb(inp); =20 @@ -1170,7 +1170,7 @@ do_close_con_rpl(struct sge_iq *iq, const struct rs= s_header *rss, tcp_twstart(tp); release: INP_UNLOCK_ASSERT(inp); /* safe, we have a ref on the inp */ - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); =20 INP_WLOCK(inp); final_cpl_received(toep); /* no more CPLs expected */ @@ -1194,7 +1194,7 @@ do_close_con_rpl(struct sge_iq *iq, const struct rs= s_header *rss, } done: INP_WUNLOCK(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); return (0); } =20 @@ -1353,7 +1353,7 @@ do_abort_req(struct sge_iq *iq, const struct rss_he= ader *rss, struct mbuf *m) } =20 inp =3D toep->inp; - INP_INFO_WLOCK(&V_tcbinfo); /* for tcp_close */ + INP_INFO_RLOCK(&V_tcbinfo); /* for tcp_close */ INP_WLOCK(inp); =20 tp =3D intotcpcb(inp); @@ -1387,7 +1387,7 @@ do_abort_req(struct sge_iq *iq, const struct rss_he= ader *rss, struct mbuf *m) =20 final_cpl_received(toep); done: - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); send_abort_rpl(sc, ofld_txq, tid, CPL_ABORT_NO_RST); return (0); } @@ -1501,12 +1501,12 @@ do_rx_data(struct sge_iq *iq, const struct rss_he= ader *rss, struct mbuf *m) SOCKBUF_UNLOCK(sb); INP_WUNLOCK(inp); =20 - INP_INFO_WLOCK(&V_tcbinfo); + INP_INFO_RLOCK(&V_tcbinfo); INP_WLOCK(inp); tp =3D tcp_drop(tp, ECONNRESET); if (tp) INP_WUNLOCK(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); =20 return (0); } diff --git a/sys/dev/cxgbe/tom/t4_listen.c b/sys/dev/cxgbe/tom/t4_listen.= c index 4380c9e..0faac12 100644 --- a/sys/dev/cxgbe/tom/t4_listen.c +++ b/sys/dev/cxgbe/tom/t4_listen.c @@ -1311,15 +1311,15 @@ do_pass_accept_req(struct sge_iq *iq, const struc= t rss_header *rss, REJECT_PASS_ACCEPT(); rpl =3D wrtod(wr); =20 - INP_INFO_WLOCK(&V_tcbinfo); /* for 4-tuple check */ + INP_INFO_RLOCK(&V_tcbinfo); /* for 4-tuple check */ =20 /* Don't offload if the 4-tuple is already in use */ if (toe_4tuple_check(&inc, &th, ifp) !=3D 0) { - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); free(wr, M_CXGBE); REJECT_PASS_ACCEPT(); } - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); =20 inp =3D lctx->inp; /* listening socket, not owned by TOE */ INP_WLOCK(inp); @@ -1511,7 +1511,7 @@ do_pass_establish(struct sge_iq *iq, const struct r= ss_header *rss, KASSERT(synqe->flags & TPF_SYNQE, ("%s: tid %u (ctx %p) not a synqe", __func__, tid, synqe)); =20 - INP_INFO_WLOCK(&V_tcbinfo); /* for syncache_expand */ + INP_INFO_RLOCK(&V_tcbinfo); /* for syncache_expand */ INP_WLOCK(inp); =20 CTR6(KTR_CXGBE, @@ -1609,7 +1609,7 @@ do_pass_establish(struct sge_iq *iq, const struct r= ss_header *rss, inp =3D release_lctx(sc, lctx); if (inp !=3D NULL) INP_WUNLOCK(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); release_synqe(synqe); =20 return (0); diff --git a/sys/netinet/in_pcb.c b/sys/netinet/in_pcb.c index a0a1b30..b91c5ad 100644 --- a/sys/netinet/in_pcb.c +++ b/sys/netinet/in_pcb.c @@ -218,6 +218,7 @@ in_pcbinfo_init(struct inpcbinfo *pcbinfo, const char= *name, =20 INP_INFO_LOCK_INIT(pcbinfo, name); INP_HASH_LOCK_INIT(pcbinfo, "pcbinfohash"); /* XXXRW: argument? */ + INP_LIST_LOCK_INIT(pcbinfo, "pcbinfolist"); #ifdef VIMAGE pcbinfo->ipi_vnet =3D curvnet; #endif @@ -256,6 +257,7 @@ in_pcbinfo_destroy(struct inpcbinfo *pcbinfo) in_pcbgroup_destroy(pcbinfo); #endif uma_zdestroy(pcbinfo->ipi_zone); + INP_LIST_LOCK_DESTROY(pcbinfo); INP_HASH_LOCK_DESTROY(pcbinfo); INP_INFO_LOCK_DESTROY(pcbinfo); } @@ -270,7 +272,14 @@ in_pcballoc(struct socket *so, struct inpcbinfo *pcb= info) struct inpcb *inp; int error; =20 - INP_INFO_WLOCK_ASSERT(pcbinfo); +#ifdef INVARIANTS + if (pcbinfo =3D=3D &V_tcbinfo) { + INP_INFO_RLOCK_ASSERT(pcbinfo); + } else { + INP_INFO_WLOCK_ASSERT(pcbinfo); + } +#endif + error =3D 0; inp =3D uma_zalloc(pcbinfo->ipi_zone, M_NOWAIT); if (inp =3D=3D NULL) @@ -302,6 +311,8 @@ in_pcballoc(struct socket *so, struct inpcbinfo *pcbi= nfo) inp->inp_flags |=3D IN6P_IPV6_V6ONLY; } #endif + INP_WLOCK(inp); + INP_LIST_WLOCK(pcbinfo); LIST_INSERT_HEAD(pcbinfo->ipi_listhead, inp, inp_list); pcbinfo->ipi_count++; so->so_pcb =3D (caddr_t)inp; @@ -309,9 +320,9 @@ in_pcballoc(struct socket *so, struct inpcbinfo *pcbi= nfo) if (V_ip6_auto_flowlabel) inp->inp_flags |=3D IN6P_AUTOFLOWLABEL; #endif - INP_WLOCK(inp); inp->inp_gencnt =3D ++pcbinfo->ipi_gencnt; refcount_init(&inp->inp_refcount, 1); /* Reference from inpcbinfo */ + INP_LIST_WUNLOCK(pcbinfo); #if defined(IPSEC) || defined(MAC) out: if (error !=3D 0) { @@ -1239,7 +1250,13 @@ in_pcbfree(struct inpcb *inp) =20 KASSERT(inp->inp_socket =3D=3D NULL, ("%s: inp_socket !=3D NULL", __fun= c__)); =20 - INP_INFO_WLOCK_ASSERT(pcbinfo); +#ifdef INVARIANTS + if (pcbinfo =3D=3D &V_tcbinfo) { + INP_INFO_RLOCK_ASSERT(pcbinfo); + } else { + INP_INFO_WLOCK_ASSERT(pcbinfo); + } +#endif INP_WLOCK_ASSERT(inp); =20 /* XXXRW: Do as much as possible here. */ @@ -1247,8 +1264,10 @@ in_pcbfree(struct inpcb *inp) if (inp->inp_sp !=3D NULL) ipsec_delete_pcbpolicy(inp); #endif + INP_LIST_WLOCK(pcbinfo); inp->inp_gencnt =3D ++pcbinfo->ipi_gencnt; in_pcbremlists(inp); + INP_LIST_WUNLOCK(pcbinfo); #ifdef INET6 if (inp->inp_vflag & INP_IPV6PROTO) { ip6_freepcbopts(inp->in6p_outputopts); @@ -1405,7 +1424,7 @@ in_pcbpurgeif0(struct inpcbinfo *pcbinfo, struct if= net *ifp) struct ip_moptions *imo; int i, gap; =20 - INP_INFO_RLOCK(pcbinfo); + INP_INFO_WLOCK(pcbinfo); LIST_FOREACH(inp, pcbinfo->ipi_listhead, inp_list) { INP_WLOCK(inp); imo =3D inp->inp_moptions; @@ -1435,7 +1454,7 @@ in_pcbpurgeif0(struct inpcbinfo *pcbinfo, struct if= net *ifp) } INP_WUNLOCK(inp); } - INP_INFO_RUNLOCK(pcbinfo); + INP_INFO_WUNLOCK(pcbinfo); } =20 /* @@ -2171,8 +2190,16 @@ in_pcbremlists(struct inpcb *inp) { struct inpcbinfo *pcbinfo =3D inp->inp_pcbinfo; =20 - INP_INFO_WLOCK_ASSERT(pcbinfo); +#ifdef INVARIANTS + if (pcbinfo =3D=3D &V_tcbinfo) { + INP_INFO_RLOCK_ASSERT(pcbinfo); + } else { + INP_INFO_WLOCK_ASSERT(pcbinfo); + } +#endif + INP_WLOCK_ASSERT(inp); + INP_LIST_WLOCK_ASSERT(pcbinfo); =20 inp->inp_gencnt =3D ++pcbinfo->ipi_gencnt; if (inp->inp_flags & INP_INHASHLIST) { @@ -2317,13 +2344,13 @@ inp_apply_all(void (*func)(struct inpcb *, void *= ), void *arg) { struct inpcb *inp; =20 - INP_INFO_RLOCK(&V_tcbinfo); + INP_INFO_WLOCK(&V_tcbinfo); LIST_FOREACH(inp, V_tcbinfo.ipi_listhead, inp_list) { INP_WLOCK(inp); func(inp, arg); INP_WUNLOCK(inp); } - INP_INFO_RUNLOCK(&V_tcbinfo); + INP_INFO_WUNLOCK(&V_tcbinfo); } =20 struct socket * diff --git a/sys/netinet/in_pcb.h b/sys/netinet/in_pcb.h index 185bcfb..661d7b8 100644 --- a/sys/netinet/in_pcb.h +++ b/sys/netinet/in_pcb.h @@ -134,19 +134,20 @@ struct icmp6_filter; * and IPv6 sockets. In the case of TCP, further per-connection state i= s * hung off of inp_ppcb most of the time. Almost all fields of struct i= npcb * are static after creation or protected by a per-inpcb rwlock, inp_loc= k. A - * few fields also require the global pcbinfo lock for the inpcb to be h= eld, - * when modified, such as the global connection lists and hashes, as wel= l as - * binding information (which affects which hash a connection is on). T= his - * model means that connections can be looked up without holding the - * per-connection lock, which is important for performance when attempti= ng to - * find the connection for a packet given its IP and port tuple. Writin= g to - * these fields that write locks be held on both the inpcb and global lo= cks. + * few fields also require the global pcblist lock for the inpcb to be h= eld, + * when modified, such as the global connection lists. This model means= that + * connections can be looked up without holding the per-connection lock,= which + * is important for performance when attempting to find the connection f= or a + * packet given its IP and port tuple. Writing to these fields that wri= te + * locks be held on both the inpcb and global locks. * * Key: * (c) - Constant after initialization * (g) - Protected by the pcbgroup lock * (i) - Protected by the inpcb lock * (p) - Protected by the pcbinfo lock for the inpcb + * (l) - Protected by the pcblist lock for the inpcb + * (h) - Protected by the pcbhash lock for the inpcb * (s) - Protected by another subsystem's locks * (x) - Undefined locking * @@ -163,13 +164,13 @@ struct icmp6_filter; * The inp_vflag field is overloaded, and would otherwise ideally be (c)= =2E */ struct inpcb { - LIST_ENTRY(inpcb) inp_hash; /* (i/p) hash list */ + LIST_ENTRY(inpcb) inp_hash; /* (i/h) hash list */ LIST_ENTRY(inpcb) inp_pcbgrouphash; /* (g/i) hash list */ - LIST_ENTRY(inpcb) inp_list; /* (i/p) list for all PCBs for proto */ + LIST_ENTRY(inpcb) inp_list; /* (i/l) list for all PCBs for proto */ void *inp_ppcb; /* (i) pointer to per-protocol pcb */ struct inpcbinfo *inp_pcbinfo; /* (c) PCB list info */ struct inpcbgroup *inp_pcbgroup; /* (g/i) PCB group list */ - LIST_ENTRY(inpcb) inp_pcbgroup_wild; /* (g/i/p) group wildcard entry */= + LIST_ENTRY(inpcb) inp_pcbgroup_wild; /* (g/i/h) group wildcard entry */= struct socket *inp_socket; /* (i) back pointer to socket */ struct ucred *inp_cred; /* (c) cache of socket cred */ u_int32_t inp_flow; /* (i) IPv6 flow information */ @@ -188,7 +189,7 @@ struct inpcb { * general use */ =20 /* Local and foreign ports, local and foreign addr. */ - struct in_conninfo inp_inc; /* (i/p) list for PCB's local port */ + struct in_conninfo inp_inc; /* (i) list for PCB's local port */ =20 /* MAC and IPSEC policy information. */ struct label *inp_label; /* (i) MAC label */ @@ -213,8 +214,8 @@ struct inpcb { int inp6_cksum; short inp6_hops; } inp_depend6; - LIST_ENTRY(inpcb) inp_portlist; /* (i/p) */ - struct inpcbport *inp_phd; /* (i/p) head of this list */ + LIST_ENTRY(inpcb) inp_portlist; /* (i/h) */ + struct inpcbport *inp_phd; /* (i/h) head of this list */ #define inp_zero_size offsetof(struct inpcb, inp_gencnt) inp_gen_t inp_gencnt; /* (c) generation count */ struct llentry *inp_lle; /* cached L2 information */ @@ -279,16 +280,24 @@ struct inpcbport { * Global data structure for each high-level protocol (UDP, TCP, ...) in= both * IPv4 and IPv6. Holds inpcb lists and information for managing them. * - * Each pcbinfo is protected by two locks: ipi_lock and ipi_hash_lock, - * the former covering mutable global fields (such as the global pcb lis= t), - * and the latter covering the hashed lookup tables. The lock order is:= + * Each pcbinfo is protected by three locks: ipi_lock, ipi_hash_lock and= + * ipi_list_lock: + * - ipi_lock covering the global pcb list stability during loop iterat= ion, + * - ipi_hash_lock covering the hashed lookup tables, + * - ipi_list_lock covering mutable global fields (such as the global + * pcb list) * - * ipi_lock (before) inpcb locks (before) {ipi_hash_lock, pcbgroup lo= cks} + * The lock order is: + * + * ipi_lock (before) + * inpcb locks (before) + * {ipi_hash_lock, ipi_list_lock, pcbgroup locks} * * Locking key: * * (c) Constant or nearly constant after initialisation * (g) Locked by ipi_lock + * (l) Locked by ipi_list_lock * (h) Read using either ipi_hash_lock or inpcb lock; write requires bot= h * (p) Protected by one or more pcbgroup locks * (x) Synchronisation properties poorly defined @@ -302,14 +311,14 @@ struct inpcbinfo { /* * Global list of inpcbs on the protocol. */ - struct inpcbhead *ipi_listhead; /* (g) */ - u_int ipi_count; /* (g) */ + struct inpcbhead *ipi_listhead; /* (g/l) */ + u_int ipi_count; /* (g/l) */ =20 /* * Generation count -- incremented each time a connection is allocated * or freed. */ - u_quad_t ipi_gencnt; /* (g) */ + u_quad_t ipi_gencnt; /* (g/l) */ =20 /* * Fields associated with port lookup and allocation. @@ -367,6 +376,11 @@ struct inpcbinfo { * general use 2 */ void *ipi_pspare[2]; + + /* + * Global lock protecting global inpcb list, inpcb count, etc. + */ + struct rwlock ipi_list_lock; }; =20 #ifdef _KERNEL @@ -466,6 +480,25 @@ short inp_so_options(const struct inpcb *inp); #define INP_INFO_WLOCK_ASSERT(ipi) rw_assert(&(ipi)->ipi_lock, RA_WLOCKE= D) #define INP_INFO_UNLOCK_ASSERT(ipi) rw_assert(&(ipi)->ipi_lock, RA_UNLOC= KED) =20 +#define INP_LIST_LOCK_INIT(ipi, d) \ + rw_init_flags(&(ipi)->ipi_list_lock, (d), 0) +#define INP_LIST_LOCK_DESTROY(ipi) rw_destroy(&(ipi)->ipi_list_lock) +#define INP_LIST_RLOCK(ipi) rw_rlock(&(ipi)->ipi_list_lock) +#define INP_LIST_WLOCK(ipi) rw_wlock(&(ipi)->ipi_list_lock) +#define INP_LIST_TRY_RLOCK(ipi) rw_try_rlock(&(ipi)->ipi_list_lock) +#define INP_LIST_TRY_WLOCK(ipi) rw_try_wlock(&(ipi)->ipi_list_lock) +#define INP_LIST_TRY_UPGRADE(ipi) rw_try_upgrade(&(ipi)->ipi_list_= lock) +#define INP_LIST_RUNLOCK(ipi) rw_runlock(&(ipi)->ipi_list_lock) +#define INP_LIST_WUNLOCK(ipi) rw_wunlock(&(ipi)->ipi_list_lock) +#define INP_LIST_LOCK_ASSERT(ipi) \ + rw_assert(&(ipi)->ipi_list_lock, RA_LOCKED) +#define INP_LIST_RLOCK_ASSERT(ipi) \ + rw_assert(&(ipi)->ipi_list_lock, RA_RLOCKED) +#define INP_LIST_WLOCK_ASSERT(ipi) \ + rw_assert(&(ipi)->ipi_list_lock, RA_WLOCKED) +#define INP_LIST_UNLOCK_ASSERT(ipi) \ + rw_assert(&(ipi)->ipi_list_lock, RA_UNLOCKED) + #define INP_HASH_LOCK_INIT(ipi, d) \ rw_init_flags(&(ipi)->ipi_hash_lock, (d), 0) #define INP_HASH_LOCK_DESTROY(ipi) rw_destroy(&(ipi)->ipi_hash_lock) diff --git a/sys/netinet/tcp_input.c b/sys/netinet/tcp_input.c index e338b1e..8090303 100644 --- a/sys/netinet/tcp_input.c +++ b/sys/netinet/tcp_input.c @@ -571,7 +571,7 @@ tcp_input(struct mbuf **mp, int *offp, int proto) char *s =3D NULL; /* address and port logging */ int ti_locked; #define TI_UNLOCKED 1 -#define TI_WLOCKED 2 +#define TI_RLOCKED 2 =20 #ifdef TCPDEBUG /* @@ -760,8 +760,8 @@ tcp_input(struct mbuf **mp, int *offp, int proto) * connection in TIMEWAIT and SYNs not targeting a listening socket. */ if ((thflags & (TH_FIN | TH_RST)) !=3D 0) { - INP_INFO_WLOCK(&V_tcbinfo); - ti_locked =3D TI_WLOCKED; + INP_INFO_RLOCK(&V_tcbinfo); + ti_locked =3D TI_RLOCKED; } else ti_locked =3D TI_UNLOCKED; =20 @@ -783,8 +783,8 @@ tcp_input(struct mbuf **mp, int *offp, int proto) =20 findpcb: #ifdef INVARIANTS - if (ti_locked =3D=3D TI_WLOCKED) { - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + if (ti_locked =3D=3D TI_RLOCKED) { + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); } else { INP_INFO_UNLOCK_ASSERT(&V_tcbinfo); } @@ -936,20 +936,20 @@ tcp_input(struct mbuf **mp, int *offp, int proto) relocked: if (inp->inp_flags & INP_TIMEWAIT) { if (ti_locked =3D=3D TI_UNLOCKED) { - if (INP_INFO_TRY_WLOCK(&V_tcbinfo) =3D=3D 0) { + if (INP_INFO_TRY_RLOCK(&V_tcbinfo) =3D=3D 0) { in_pcbref(inp); INP_WUNLOCK(inp); - INP_INFO_WLOCK(&V_tcbinfo); - ti_locked =3D TI_WLOCKED; + INP_INFO_RLOCK(&V_tcbinfo); + ti_locked =3D TI_RLOCKED; INP_WLOCK(inp); if (in_pcbrele_wlocked(inp)) { inp =3D NULL; goto findpcb; } } else - ti_locked =3D TI_WLOCKED; + ti_locked =3D TI_RLOCKED; } - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); =20 if (thflags & TH_SYN) tcp_dooptions(&to, optp, optlen, TO_SYN); @@ -958,7 +958,7 @@ tcp_input(struct mbuf **mp, int *offp, int proto) */ if (tcp_twcheck(inp, &to, th, m, tlen)) goto findpcb; - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); return (IPPROTO_DONE); } /* @@ -989,16 +989,16 @@ tcp_input(struct mbuf **mp, int *offp, int proto) */ #ifdef INVARIANTS if ((thflags & (TH_FIN | TH_RST)) !=3D 0) - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); #endif if (!((tp->t_state =3D=3D TCPS_ESTABLISHED && (thflags & TH_SYN) =3D=3D= 0) || (tp->t_state =3D=3D TCPS_LISTEN && (thflags & TH_SYN)))) { if (ti_locked =3D=3D TI_UNLOCKED) { - if (INP_INFO_TRY_WLOCK(&V_tcbinfo) =3D=3D 0) { + if (INP_INFO_TRY_RLOCK(&V_tcbinfo) =3D=3D 0) { in_pcbref(inp); INP_WUNLOCK(inp); - INP_INFO_WLOCK(&V_tcbinfo); - ti_locked =3D TI_WLOCKED; + INP_INFO_RLOCK(&V_tcbinfo); + ti_locked =3D TI_RLOCKED; INP_WLOCK(inp); if (in_pcbrele_wlocked(inp)) { inp =3D NULL; @@ -1006,9 +1006,9 @@ tcp_input(struct mbuf **mp, int *offp, int proto) } goto relocked; } else - ti_locked =3D TI_WLOCKED; + ti_locked =3D TI_RLOCKED; } - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); } =20 #ifdef MAC @@ -1063,7 +1063,7 @@ tcp_input(struct mbuf **mp, int *offp, int proto) */ if ((thflags & (TH_RST|TH_ACK|TH_SYN)) =3D=3D TH_ACK) { =20 - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); /* * Parse the TCP options here because * syncookies need access to the reflected @@ -1346,8 +1346,8 @@ tcp_input(struct mbuf **mp, int *offp, int proto) * Entry added to syncache and mbuf consumed. * Only the listen socket is unlocked by syncache_add(). */ - if (ti_locked =3D=3D TI_WLOCKED) { - INP_INFO_WUNLOCK(&V_tcbinfo); + if (ti_locked =3D=3D TI_RLOCKED) { + INP_INFO_RUNLOCK(&V_tcbinfo); ti_locked =3D TI_UNLOCKED; } INP_INFO_UNLOCK_ASSERT(&V_tcbinfo); @@ -1396,8 +1396,8 @@ tcp_input(struct mbuf **mp, int *offp, int proto) dropwithreset: TCP_PROBE5(receive, NULL, tp, mtod(m, const char *), tp, th); =20 - if (ti_locked =3D=3D TI_WLOCKED) { - INP_INFO_WUNLOCK(&V_tcbinfo); + if (ti_locked =3D=3D TI_RLOCKED) { + INP_INFO_RUNLOCK(&V_tcbinfo); ti_locked =3D TI_UNLOCKED; } #ifdef INVARIANTS @@ -1420,8 +1420,8 @@ tcp_input(struct mbuf **mp, int *offp, int proto) if (m !=3D NULL) TCP_PROBE5(receive, NULL, tp, mtod(m, const char *), tp, th); =20 - if (ti_locked =3D=3D TI_WLOCKED) { - INP_INFO_WUNLOCK(&V_tcbinfo); + if (ti_locked =3D=3D TI_RLOCKED) { + INP_INFO_RUNLOCK(&V_tcbinfo); ti_locked =3D TI_UNLOCKED; } #ifdef INVARIANTS @@ -1478,13 +1478,13 @@ tcp_do_segment(struct mbuf *m, struct tcphdr *th,= struct socket *so, */ if ((thflags & (TH_SYN | TH_FIN | TH_RST)) !=3D 0 || tp->t_state !=3D TCPS_ESTABLISHED) { - KASSERT(ti_locked =3D=3D TI_WLOCKED, ("%s ti_locked %d for " + KASSERT(ti_locked =3D=3D TI_RLOCKED, ("%s ti_locked %d for " "SYN/FIN/RST/!EST", __func__, ti_locked)); - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); } else { #ifdef INVARIANTS - if (ti_locked =3D=3D TI_WLOCKED) - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + if (ti_locked =3D=3D TI_RLOCKED) + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); else { KASSERT(ti_locked =3D=3D TI_UNLOCKED, ("%s: EST " "ti_locked: %d", __func__, ti_locked)); @@ -1652,8 +1652,8 @@ tcp_do_segment(struct mbuf *m, struct tcphdr *th, s= truct socket *so, /* * This is a pure ack for outstanding data. */ - if (ti_locked =3D=3D TI_WLOCKED) - INP_INFO_WUNLOCK(&V_tcbinfo); + if (ti_locked =3D=3D TI_RLOCKED) + INP_INFO_RUNLOCK(&V_tcbinfo); ti_locked =3D TI_UNLOCKED; =20 TCPSTAT_INC(tcps_predack); @@ -1756,8 +1756,8 @@ tcp_do_segment(struct mbuf *m, struct tcphdr *th, s= truct socket *so, * nothing on the reassembly queue and we have enough * buffer space to take it. */ - if (ti_locked =3D=3D TI_WLOCKED) - INP_INFO_WUNLOCK(&V_tcbinfo); + if (ti_locked =3D=3D TI_RLOCKED) + INP_INFO_RUNLOCK(&V_tcbinfo); ti_locked =3D TI_UNLOCKED; =20 /* Clean receiver SACK report if present */ @@ -1992,9 +1992,9 @@ tcp_do_segment(struct mbuf *m, struct tcphdr *th, s= truct socket *so, tcp_state_change(tp, TCPS_SYN_RECEIVED); } =20 - KASSERT(ti_locked =3D=3D TI_WLOCKED, ("%s: trimthenstep6: " + KASSERT(ti_locked =3D=3D TI_RLOCKED, ("%s: trimthenstep6: " "ti_locked %d", __func__, ti_locked)); - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); INP_WLOCK_ASSERT(tp->t_inpcb); =20 /* @@ -2067,8 +2067,8 @@ tcp_do_segment(struct mbuf *m, struct tcphdr *th, s= truct socket *so, SEQ_LT(th->th_seq, tp->last_ack_sent + tp->rcv_wnd)) || (tp->rcv_wnd =3D=3D 0 && tp->last_ack_sent =3D=3D th->th_seq)) { =20 - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); - KASSERT(ti_locked =3D=3D TI_WLOCKED, + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); + KASSERT(ti_locked =3D=3D TI_RLOCKED, ("%s: TH_RST ti_locked %d, th %p tp %p", __func__, ti_locked, th, tp)); KASSERT(tp->t_state !=3D TCPS_SYN_SENT, @@ -2111,9 +2111,9 @@ tcp_do_segment(struct mbuf *m, struct tcphdr *th, s= truct socket *so, * Send challenge ACK for any SYN in synchronized state. */ if ((thflags & TH_SYN) && tp->t_state !=3D TCPS_SYN_SENT) { - KASSERT(ti_locked =3D=3D TI_WLOCKED, + KASSERT(ti_locked =3D=3D TI_RLOCKED, ("tcp_do_segment: TH_SYN ti_locked %d", ti_locked)); - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); =20 TCPSTAT_INC(tcps_badsyn); if (V_tcp_insecure_syn && @@ -2226,9 +2226,9 @@ tcp_do_segment(struct mbuf *m, struct tcphdr *th, s= truct socket *so, */ if ((so->so_state & SS_NOFDREF) && tp->t_state > TCPS_CLOSE_WAIT && tlen) { - KASSERT(ti_locked =3D=3D TI_WLOCKED, ("%s: SS_NOFDEREF && " + KASSERT(ti_locked =3D=3D TI_RLOCKED, ("%s: SS_NOFDEREF && " "CLOSE_WAIT && tlen ti_locked %d", __func__, ti_locked)); - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); =20 if ((s =3D tcp_log_addrs(inc, th, NULL, NULL))) { log(LOG_DEBUG, "%s; %s: %s: Received %d bytes of data " @@ -2729,9 +2729,9 @@ tcp_do_segment(struct mbuf *m, struct tcphdr *th, s= truct socket *so, */ case TCPS_CLOSING: if (ourfinisacked) { - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); tcp_twstart(tp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); m_freem(m); return; } @@ -2745,7 +2745,7 @@ tcp_do_segment(struct mbuf *m, struct tcphdr *th, s= truct socket *so, */ case TCPS_LAST_ACK: if (ourfinisacked) { - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); tp =3D tcp_close(tp); goto drop; } @@ -2959,18 +2959,18 @@ tcp_do_segment(struct mbuf *m, struct tcphdr *th,= struct socket *so, * standard timers. */ case TCPS_FIN_WAIT_2: - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); - KASSERT(ti_locked =3D=3D TI_WLOCKED, ("%s: dodata " + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); + KASSERT(ti_locked =3D=3D TI_RLOCKED, ("%s: dodata " "TCP_FIN_WAIT_2 ti_locked: %d", __func__, ti_locked)); =20 tcp_twstart(tp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); return; } } - if (ti_locked =3D=3D TI_WLOCKED) - INP_INFO_WUNLOCK(&V_tcbinfo); + if (ti_locked =3D=3D TI_RLOCKED) + INP_INFO_RUNLOCK(&V_tcbinfo); ti_locked =3D TI_UNLOCKED; =20 #ifdef TCPDEBUG @@ -3025,8 +3025,8 @@ tcp_do_segment(struct mbuf *m, struct tcphdr *th, s= truct socket *so, tcp_trace(TA_DROP, ostate, tp, (void *)tcp_saveipgen, &tcp_savetcp, 0); #endif - if (ti_locked =3D=3D TI_WLOCKED) - INP_INFO_WUNLOCK(&V_tcbinfo); + if (ti_locked =3D=3D TI_RLOCKED) + INP_INFO_RUNLOCK(&V_tcbinfo); ti_locked =3D TI_UNLOCKED; =20 tp->t_flags |=3D TF_ACKNOW; @@ -3036,8 +3036,8 @@ tcp_do_segment(struct mbuf *m, struct tcphdr *th, s= truct socket *so, return; =20 dropwithreset: - if (ti_locked =3D=3D TI_WLOCKED) - INP_INFO_WUNLOCK(&V_tcbinfo); + if (ti_locked =3D=3D TI_RLOCKED) + INP_INFO_RUNLOCK(&V_tcbinfo); ti_locked =3D TI_UNLOCKED; =20 if (tp !=3D NULL) { @@ -3048,8 +3048,8 @@ tcp_do_segment(struct mbuf *m, struct tcphdr *th, s= truct socket *so, return; =20 drop: - if (ti_locked =3D=3D TI_WLOCKED) { - INP_INFO_WUNLOCK(&V_tcbinfo); + if (ti_locked =3D=3D TI_RLOCKED) { + INP_INFO_RUNLOCK(&V_tcbinfo); ti_locked =3D TI_UNLOCKED; } #ifdef INVARIANTS diff --git a/sys/netinet/tcp_subr.c b/sys/netinet/tcp_subr.c index 7adda33..ff2153e 100644 --- a/sys/netinet/tcp_subr.c +++ b/sys/netinet/tcp_subr.c @@ -849,11 +849,11 @@ tcp_ccalgounload(struct cc_algo *unload_algo) VNET_LIST_RLOCK(); VNET_FOREACH(vnet_iter) { CURVNET_SET(vnet_iter); - INP_INFO_RLOCK(&V_tcbinfo); + INP_INFO_WLOCK(&V_tcbinfo); /* * New connections already part way through being initialised * with the CC algo we're removing will not race with this code - * because the INP_INFO_WLOCK is held during initialisation. We + * because the INP_INFO_RLOCK is held during initialisation. We * therefore don't enter the loop below until the connection * list has stabilised. */ @@ -879,7 +879,7 @@ tcp_ccalgounload(struct cc_algo *unload_algo) } INP_WUNLOCK(inp); } - INP_INFO_RUNLOCK(&V_tcbinfo); + INP_INFO_WUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); } VNET_LIST_RUNLOCK(); @@ -897,7 +897,7 @@ tcp_drop(struct tcpcb *tp, int errno) { struct socket *so =3D tp->t_inpcb->inp_socket; =20 - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); INP_WLOCK_ASSERT(tp->t_inpcb); =20 if (TCPS_HAVERCVDSYN(tp->t_state)) { @@ -1033,7 +1033,7 @@ tcp_close(struct tcpcb *tp) struct inpcb *inp =3D tp->t_inpcb; struct socket *so; =20 - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); INP_WLOCK_ASSERT(inp); =20 #ifdef TCP_OFFLOAD @@ -1081,7 +1081,7 @@ tcp_drain(void) * where we're really low on mbufs, this is potentially * useful. */ - INP_INFO_RLOCK(&V_tcbinfo); + INP_INFO_WLOCK(&V_tcbinfo); LIST_FOREACH(inpb, V_tcbinfo.ipi_listhead, inp_list) { if (inpb->inp_flags & INP_TIMEWAIT) continue; @@ -1092,7 +1092,7 @@ tcp_drain(void) } INP_WUNLOCK(inpb); } - INP_INFO_RUNLOCK(&V_tcbinfo); + INP_INFO_WUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); } VNET_LIST_RUNLOCK_NOSLEEP(); @@ -1176,8 +1176,10 @@ tcp_pcblist(SYSCTL_HANDLER_ARGS) * OK, now we're committed to doing something. */ INP_INFO_RLOCK(&V_tcbinfo); + INP_LIST_RLOCK(&V_tcbinfo); gencnt =3D V_tcbinfo.ipi_gencnt; n =3D V_tcbinfo.ipi_count; + INP_LIST_RUNLOCK(&V_tcbinfo); INP_INFO_RUNLOCK(&V_tcbinfo); =20 m =3D syncache_pcbcount(); @@ -1203,7 +1205,7 @@ tcp_pcblist(SYSCTL_HANDLER_ARGS) if (inp_list =3D=3D NULL) return (ENOMEM); =20 - INP_INFO_RLOCK(&V_tcbinfo); + INP_INFO_WLOCK(&V_tcbinfo); for (inp =3D LIST_FIRST(V_tcbinfo.ipi_listhead), i =3D 0; inp !=3D NULL && i < n; inp =3D LIST_NEXT(inp, inp_list)) { INP_WLOCK(inp); @@ -1228,7 +1230,7 @@ tcp_pcblist(SYSCTL_HANDLER_ARGS) } INP_WUNLOCK(inp); } - INP_INFO_RUNLOCK(&V_tcbinfo); + INP_INFO_WUNLOCK(&V_tcbinfo); n =3D i; =20 error =3D 0; @@ -1266,14 +1268,14 @@ tcp_pcblist(SYSCTL_HANDLER_ARGS) } else INP_RUNLOCK(inp); } - INP_INFO_WLOCK(&V_tcbinfo); + INP_INFO_RLOCK(&V_tcbinfo); for (i =3D 0; i < n; i++) { inp =3D inp_list[i]; INP_RLOCK(inp); if (!in_pcbrele_rlocked(inp)) INP_RUNLOCK(inp); } - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); =20 if (!error) { /* @@ -1284,9 +1286,11 @@ tcp_pcblist(SYSCTL_HANDLER_ARGS) * might be necessary to retry. */ INP_INFO_RLOCK(&V_tcbinfo); + INP_LIST_RLOCK(&V_tcbinfo); xig.xig_gen =3D V_tcbinfo.ipi_gencnt; xig.xig_sogen =3D so_gencnt; xig.xig_count =3D V_tcbinfo.ipi_count + pcb_count; + INP_LIST_RUNLOCK(&V_tcbinfo); INP_INFO_RUNLOCK(&V_tcbinfo); error =3D SYSCTL_OUT(req, &xig, sizeof xig); } @@ -1448,7 +1452,7 @@ tcp_ctlinput(int cmd, struct sockaddr *sa, void *vi= p) - offsetof(struct icmp, icmp_ip)); th =3D (struct tcphdr *)((caddr_t)ip + (ip->ip_hl << 2)); - INP_INFO_WLOCK(&V_tcbinfo); + INP_INFO_RLOCK(&V_tcbinfo); inp =3D in_pcblookup(&V_tcbinfo, faddr, th->th_dport, ip->ip_src, th->th_sport, INPLOOKUP_WLOCKPCB, NULL); if (inp !=3D NULL) { @@ -1508,7 +1512,7 @@ tcp_ctlinput(int cmd, struct sockaddr *sa, void *vi= p) inc.inc_laddr =3D ip->ip_src; syncache_unreach(&inc, th); } - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); } else in_pcbnotifyall(&V_tcbinfo, faddr, inetctlerrmap[cmd], notify); } @@ -1581,9 +1585,9 @@ tcp6_ctlinput(int cmd, struct sockaddr *sa, void *d= ) inc.inc6_faddr =3D ((struct sockaddr_in6 *)sa)->sin6_addr; inc.inc6_laddr =3D ip6cp->ip6c_src->sin6_addr; inc.inc_flags |=3D INC_ISIPV6; - INP_INFO_WLOCK(&V_tcbinfo); + INP_INFO_RLOCK(&V_tcbinfo); syncache_unreach(&inc, &th); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); } else in6_pcbnotify(&V_tcbinfo, sa, 0, (const struct sockaddr *)sa6_src, 0, cmd, NULL, notify); @@ -1716,7 +1720,7 @@ tcp_drop_syn_sent(struct inpcb *inp, int errno) { struct tcpcb *tp; =20 - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); INP_WLOCK_ASSERT(inp); =20 if ((inp->inp_flags & INP_TIMEWAIT) || @@ -2239,7 +2243,7 @@ sysctl_drop(SYSCTL_HANDLER_ARGS) default: return (EINVAL); } - INP_INFO_WLOCK(&V_tcbinfo); + INP_INFO_RLOCK(&V_tcbinfo); switch (addrs[0].ss_family) { #ifdef INET6 case AF_INET6: @@ -2278,7 +2282,7 @@ sysctl_drop(SYSCTL_HANDLER_ARGS) INP_WUNLOCK(inp); } else error =3D ESRCH; - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); return (error); } =20 diff --git a/sys/netinet/tcp_syncache.c b/sys/netinet/tcp_syncache.c index 55a5044..197c788 100644 --- a/sys/netinet/tcp_syncache.c +++ b/sys/netinet/tcp_syncache.c @@ -662,7 +662,7 @@ syncache_socket(struct syncache *sc, struct socket *l= so, struct mbuf *m) int error; char *s; =20 - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); =20 /* * Ok, create the full blown connection, and set things up @@ -944,7 +944,7 @@ syncache_expand(struct in_conninfo *inc, struct tcpop= t *to, struct tcphdr *th, * Global TCP locks are held because we manipulate the PCB lists * and create a new socket. */ - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); KASSERT((th->th_flags & (TH_RST|TH_ACK|TH_SYN)) =3D=3D TH_ACK, ("%s: can handle only ACK", __func__)); =20 diff --git a/sys/netinet/tcp_timer.c b/sys/netinet/tcp_timer.c index 1767e1e..997638c 100644 --- a/sys/netinet/tcp_timer.c +++ b/sys/netinet/tcp_timer.c @@ -269,7 +269,7 @@ tcp_timer_2msl(void *xtp) /* * XXXRW: Does this actually happen? */ - INP_INFO_WLOCK(&V_tcbinfo); + INP_INFO_RLOCK(&V_tcbinfo); inp =3D tp->t_inpcb; /* * XXXRW: While this assert is in fact correct, bugs in the tcpcb @@ -280,7 +280,7 @@ tcp_timer_2msl(void *xtp) */ if (inp =3D=3D NULL) { tcp_timer_race++; - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); return; } @@ -289,14 +289,14 @@ tcp_timer_2msl(void *xtp) if (callout_pending(&tp->t_timers->tt_2msl) || !callout_active(&tp->t_timers->tt_2msl)) { INP_WUNLOCK(tp->t_inpcb); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); return; } callout_deactivate(&tp->t_timers->tt_2msl); if ((inp->inp_flags & INP_DROPPED) !=3D 0) { INP_WUNLOCK(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); return; } @@ -332,7 +332,7 @@ tcp_timer_2msl(void *xtp) #endif if (tp !=3D NULL) INP_WUNLOCK(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); } =20 @@ -348,7 +348,7 @@ tcp_timer_keep(void *xtp) =20 ostate =3D tp->t_state; #endif - INP_INFO_WLOCK(&V_tcbinfo); + INP_INFO_RLOCK(&V_tcbinfo); inp =3D tp->t_inpcb; /* * XXXRW: While this assert is in fact correct, bugs in the tcpcb @@ -359,7 +359,7 @@ tcp_timer_keep(void *xtp) */ if (inp =3D=3D NULL) { tcp_timer_race++; - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); return; } @@ -367,14 +367,14 @@ tcp_timer_keep(void *xtp) if (callout_pending(&tp->t_timers->tt_keep) || !callout_active(&tp->t_timers->tt_keep)) { INP_WUNLOCK(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); return; } callout_deactivate(&tp->t_timers->tt_keep); if ((inp->inp_flags & INP_DROPPED) !=3D 0) { INP_WUNLOCK(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); return; } @@ -421,7 +421,7 @@ tcp_timer_keep(void *xtp) PRU_SLOWTIMO); #endif INP_WUNLOCK(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); return; =20 @@ -436,7 +436,7 @@ tcp_timer_keep(void *xtp) #endif if (tp !=3D NULL) INP_WUNLOCK(tp->t_inpcb); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); } =20 @@ -451,7 +451,7 @@ tcp_timer_persist(void *xtp) =20 ostate =3D tp->t_state; #endif - INP_INFO_WLOCK(&V_tcbinfo); + INP_INFO_RLOCK(&V_tcbinfo); inp =3D tp->t_inpcb; /* * XXXRW: While this assert is in fact correct, bugs in the tcpcb @@ -462,7 +462,7 @@ tcp_timer_persist(void *xtp) */ if (inp =3D=3D NULL) { tcp_timer_race++; - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); return; } @@ -470,14 +470,14 @@ tcp_timer_persist(void *xtp) if (callout_pending(&tp->t_timers->tt_persist) || !callout_active(&tp->t_timers->tt_persist)) { INP_WUNLOCK(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); return; } callout_deactivate(&tp->t_timers->tt_persist); if ((inp->inp_flags & INP_DROPPED) !=3D 0) { INP_WUNLOCK(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); return; } @@ -522,7 +522,7 @@ tcp_timer_persist(void *xtp) #endif if (tp !=3D NULL) INP_WUNLOCK(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); } =20 @@ -581,16 +581,16 @@ tcp_timer_rexmt(void * xtp) in_pcbref(inp); INP_INFO_RUNLOCK(&V_tcbinfo); INP_WUNLOCK(inp); - INP_INFO_WLOCK(&V_tcbinfo); + INP_INFO_RLOCK(&V_tcbinfo); INP_WLOCK(inp); if (in_pcbrele_wlocked(inp)) { - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); return; } if (inp->inp_flags & INP_DROPPED) { INP_WUNLOCK(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); return; } @@ -688,7 +688,7 @@ tcp_timer_rexmt(void * xtp) if (tp !=3D NULL) INP_WUNLOCK(inp); if (headlocked) - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); } =20 diff --git a/sys/netinet/tcp_timewait.c b/sys/netinet/tcp_timewait.c index 9c17655..7687058 100644 --- a/sys/netinet/tcp_timewait.c +++ b/sys/netinet/tcp_timewait.c @@ -202,10 +202,10 @@ tcp_tw_destroy(void) { struct tcptw *tw; =20 - INP_INFO_WLOCK(&V_tcbinfo); + INP_INFO_RLOCK(&V_tcbinfo); while ((tw =3D TAILQ_FIRST(&V_twq_2msl)) !=3D NULL) tcp_twclose(tw, 0); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); =20 TW_LOCK_DESTROY(V_tw_lock); uma_zdestroy(V_tcptw_zone); @@ -228,7 +228,7 @@ tcp_twstart(struct tcpcb *tp) int isipv6 =3D inp->inp_inc.inc_flags & INC_ISIPV6; #endif =20 - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); INP_WLOCK_ASSERT(inp); =20 if (V_nolocaltimewait) { @@ -357,7 +357,7 @@ tcp_twcheck(struct inpcb *inp, struct tcpopt *to __un= used, struct tcphdr *th, int thflags; tcp_seq seq; =20 - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); INP_WLOCK_ASSERT(inp); =20 /* @@ -458,7 +458,7 @@ tcp_twclose(struct tcptw *tw, int reuse) inp =3D tw->tw_inpcb; KASSERT((inp->inp_flags & INP_TIMEWAIT), ("tcp_twclose: !timewait")); KASSERT(intotw(inp) =3D=3D tw, ("tcp_twclose: inp_ppcb !=3D tw")); - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); /* in_pcbfree() */ + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); /* in_pcbfree() */ INP_WLOCK_ASSERT(inp); =20 tcp_tw_2msl_stop(tw, reuse); @@ -613,7 +613,7 @@ static void tcp_tw_2msl_reset(struct tcptw *tw, int rearm) { =20 - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); INP_WLOCK_ASSERT(tw->tw_inpcb); =20 TW_WLOCK(V_tw_lock); @@ -631,7 +631,7 @@ tcp_tw_2msl_stop(struct tcptw *tw, int reuse) struct inpcb *inp; int released; =20 - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); =20 TW_WLOCK(V_tw_lock); inp =3D tw->tw_inpcb; @@ -658,7 +658,7 @@ tcp_tw_2msl_reuse(void) struct tcptw *tw; struct inpcb *inp; =20 - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); =20 for (;;) { TW_RLOCK(V_tw_lock); @@ -715,26 +715,26 @@ tcp_tw_2msl_scan(void) in_pcbref(inp); TW_RUNLOCK(V_tw_lock); =20 - if (INP_INFO_TRY_WLOCK(&V_tcbinfo)) { + if (INP_INFO_TRY_RLOCK(&V_tcbinfo)) { =20 INP_WLOCK(inp); tw =3D intotw(inp); if (in_pcbrele_wlocked(inp)) { KASSERT(tw =3D=3D NULL, ("%s: held last inp " "reference but tw not NULL", __func__)); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); continue; } =20 if (tw =3D=3D NULL) { /* tcp_twclose() has already been called */ INP_WUNLOCK(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); continue; } =20 tcp_twclose(tw, 0); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); } else { /* INP_INFO lock is busy, continue later. */ INP_WLOCK(inp); diff --git a/sys/netinet/tcp_usrreq.c b/sys/netinet/tcp_usrreq.c index 2820ffb..faa2d45 100644 --- a/sys/netinet/tcp_usrreq.c +++ b/sys/netinet/tcp_usrreq.c @@ -163,7 +163,7 @@ tcp_detach(struct socket *so, struct inpcb *inp) { struct tcpcb *tp; =20 - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); INP_WLOCK_ASSERT(inp); =20 KASSERT(so->so_pcb =3D=3D inp, ("tcp_detach: so_pcb !=3D inp")); @@ -244,12 +244,12 @@ tcp_usr_detach(struct socket *so) =20 inp =3D sotoinpcb(so); KASSERT(inp !=3D NULL, ("tcp_usr_detach: inp =3D=3D NULL")); - INP_INFO_WLOCK(&V_tcbinfo); + INP_INFO_RLOCK(&V_tcbinfo); INP_WLOCK(inp); KASSERT(inp->inp_socket !=3D NULL, ("tcp_usr_detach: inp_socket =3D=3D NULL")); tcp_detach(so, inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); } =20 #ifdef INET @@ -603,7 +603,7 @@ tcp_usr_disconnect(struct socket *so) int error =3D 0; =20 TCPDEBUG0; - INP_INFO_WLOCK(&V_tcbinfo); + INP_INFO_RLOCK(&V_tcbinfo); inp =3D sotoinpcb(so); KASSERT(inp !=3D NULL, ("tcp_usr_disconnect: inp =3D=3D NULL")); INP_WLOCK(inp); @@ -619,7 +619,7 @@ tcp_usr_disconnect(struct socket *so) out: TCPDEBUG2(PRU_DISCONNECT); INP_WUNLOCK(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); return (error); } =20 @@ -734,7 +734,7 @@ tcp_usr_shutdown(struct socket *so) struct tcpcb *tp =3D NULL; =20 TCPDEBUG0; - INP_INFO_WLOCK(&V_tcbinfo); + INP_INFO_RLOCK(&V_tcbinfo); inp =3D sotoinpcb(so); KASSERT(inp !=3D NULL, ("inp =3D=3D NULL")); INP_WLOCK(inp); @@ -752,7 +752,7 @@ tcp_usr_shutdown(struct socket *so) out: TCPDEBUG2(PRU_SHUTDOWN); INP_WUNLOCK(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); =20 return (error); } @@ -814,7 +814,7 @@ tcp_usr_send(struct socket *so, int flags, struct mbu= f *m, * this call. */ if (flags & PRUS_EOF) - INP_INFO_WLOCK(&V_tcbinfo); + INP_INFO_RLOCK(&V_tcbinfo); inp =3D sotoinpcb(so); KASSERT(inp !=3D NULL, ("tcp_usr_send: inp =3D=3D NULL")); INP_WLOCK(inp); @@ -871,7 +871,7 @@ tcp_usr_send(struct socket *so, int flags, struct mbu= f *m, * Close the send side of the connection after * the data is sent. */ - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); socantsendmore(so); tcp_usrclosed(tp); } @@ -935,7 +935,7 @@ tcp_usr_send(struct socket *so, int flags, struct mbu= f *m, ((flags & PRUS_EOF) ? PRU_SEND_EOF : PRU_SEND)); INP_WUNLOCK(inp); if (flags & PRUS_EOF) - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); return (error); } =20 @@ -952,7 +952,7 @@ tcp_usr_abort(struct socket *so) inp =3D sotoinpcb(so); KASSERT(inp !=3D NULL, ("tcp_usr_abort: inp =3D=3D NULL")); =20 - INP_INFO_WLOCK(&V_tcbinfo); + INP_INFO_RLOCK(&V_tcbinfo); INP_WLOCK(inp); KASSERT(inp->inp_socket !=3D NULL, ("tcp_usr_abort: inp_socket =3D=3D NULL")); @@ -974,7 +974,7 @@ tcp_usr_abort(struct socket *so) inp->inp_flags |=3D INP_SOCKREF; } INP_WUNLOCK(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); } =20 /* @@ -990,7 +990,7 @@ tcp_usr_close(struct socket *so) inp =3D sotoinpcb(so); KASSERT(inp !=3D NULL, ("tcp_usr_close: inp =3D=3D NULL")); =20 - INP_INFO_WLOCK(&V_tcbinfo); + INP_INFO_RLOCK(&V_tcbinfo); INP_WLOCK(inp); KASSERT(inp->inp_socket !=3D NULL, ("tcp_usr_close: inp_socket =3D=3D NULL")); @@ -1013,7 +1013,7 @@ tcp_usr_close(struct socket *so) inp->inp_flags |=3D INP_SOCKREF; } INP_WUNLOCK(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); } =20 /* @@ -1611,10 +1611,10 @@ tcp_attach(struct socket *so) } so->so_rcv.sb_flags |=3D SB_AUTOSIZE; so->so_snd.sb_flags |=3D SB_AUTOSIZE; - INP_INFO_WLOCK(&V_tcbinfo); + INP_INFO_RLOCK(&V_tcbinfo); error =3D in_pcballoc(so, &V_tcbinfo); if (error) { - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); return (error); } inp =3D sotoinpcb(so); @@ -1630,12 +1630,12 @@ tcp_attach(struct socket *so) if (tp =3D=3D NULL) { in_pcbdetach(inp); in_pcbfree(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); return (ENOBUFS); } tp->t_state =3D TCPS_CLOSED; INP_WUNLOCK(inp); - INP_INFO_WUNLOCK(&V_tcbinfo); + INP_INFO_RUNLOCK(&V_tcbinfo); return (0); } =20 @@ -1653,7 +1653,7 @@ tcp_disconnect(struct tcpcb *tp) struct inpcb *inp =3D tp->t_inpcb; struct socket *so =3D inp->inp_socket; =20 - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); INP_WLOCK_ASSERT(inp); =20 /* @@ -1691,7 +1691,7 @@ static void tcp_usrclosed(struct tcpcb *tp) { =20 - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); INP_WLOCK_ASSERT(tp->t_inpcb); =20 switch (tp->t_state) { diff --git a/sys/netinet/toecore.c b/sys/netinet/toecore.c index 1ab6c73..5887576 100644 --- a/sys/netinet/toecore.c +++ b/sys/netinet/toecore.c @@ -339,7 +339,7 @@ toe_syncache_expand(struct in_conninfo *inc, struct t= cpopt *to, struct tcphdr *th, struct socket **lsop) { =20 - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); =20 return (syncache_expand(inc, to, th, lsop, NULL)); } @@ -370,7 +370,7 @@ toe_4tuple_check(struct in_conninfo *inc, struct tcph= dr *th, struct ifnet *ifp) =20 if ((inp->inp_flags & INP_TIMEWAIT) && th !=3D NULL) { =20 - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); /* for twcheck */ + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); /* for twcheck */ if (!tcp_twcheck(inp, NULL, th, NULL, 0)) return (EADDRINUSE); } else { @@ -574,7 +574,7 @@ toe_connect_failed(struct toedev *tod, struct inpcb *= inp, int err) (void) tcp_output(tp); } else { =20 - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); + INP_INFO_RLOCK_ASSERT(&V_tcbinfo); tp =3D tcp_drop(tp, err); if (tp =3D=3D NULL) INP_WLOCK(inp); /* re-acquire */ diff --git a/sys/netinet6/in6_pcb.c b/sys/netinet6/in6_pcb.c index 2be2e83..0fcf091 100644 --- a/sys/netinet6/in6_pcb.c +++ b/sys/netinet6/in6_pcb.c @@ -795,7 +795,7 @@ in6_pcbpurgeif0(struct inpcbinfo *pcbinfo, struct ifn= et *ifp) struct ip6_moptions *im6o; int i, gap; =20 - INP_INFO_RLOCK(pcbinfo); + INP_INFO_WLOCK(pcbinfo); LIST_FOREACH(in6p, pcbinfo->ipi_listhead, inp_list) { INP_WLOCK(in6p); im6o =3D in6p->in6p_moptions; @@ -826,7 +826,7 @@ in6_pcbpurgeif0(struct inpcbinfo *pcbinfo, struct ifn= et *ifp) } INP_WUNLOCK(in6p); } - INP_INFO_RUNLOCK(pcbinfo); + INP_INFO_WUNLOCK(pcbinfo); } =20 /* --------------090402000607020404040507-- --IArnHQlKn5sngVOmi6i0lvig0oDVojeVN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJULqHKAAoJEKVlQ5Je6dhxgKMH/2WnT+RXtDWrzwmM2Hx6PA6R QsnJyvWbSwvNpL+zLyMWReJyHWmMlfqoUD1Te8TyssjpAthqYGx45Bu3WqoZW7um rmTMbRJjTqzttYctaz3BDGB9xrpVqAG1oVK+urVzZ4qX7yO6b+GSIErfB2coPget EsWA9Pbw42bBT89SX91Oc/KE2Gu0gv5Npcqk1EDQ8UpGPNI+iG7XHPrgpDdmXEkM sDXDiy1ubql/Jrzax7cmr9RubxQ/QXktb3FbKpCiZOgxsF2kpWmcsi7PtVKuG5p5 l6rGjNU5PjsguCxZCQZzFsiPf6lHuuKDjlb+r6Ug73eA6n1DAPxG9jdHKct9Do0= =GIWQ -----END PGP SIGNATURE----- --IArnHQlKn5sngVOmi6i0lvig0oDVojeVN-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 3 14:04:00 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27DD3A2A for ; Fri, 3 Oct 2014 14:04:00 +0000 (UTC) Received: from na3sys009aog129.obsmtp.com (na3sys009aog129.obsmtp.com [74.125.149.142]) by mx1.freebsd.org (Postfix) with SMTP id CFA9310E for ; Fri, 3 Oct 2014 14:03:59 +0000 (UTC) Received: from mail-ig0-f179.google.com ([209.85.213.179]) (using TLSv1) by na3sys009aob129.postini.com ([74.125.148.12]) with SMTP ID DSNKVC6sxDcXMgbDA+4sf4eWNkMO5gvPmya3@postini.com; Fri, 03 Oct 2014 07:03:59 PDT Received: by mail-ig0-f179.google.com with SMTP id h18so2363723igc.6 for ; Fri, 03 Oct 2014 07:03:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TkeBzcebgddXpe8E08zoxwcV59xJWbSkEQvvRpLI094=; b=cdnbviSuyixa3bKU3h+sY6h1husKJoXyw+ix9o8Cx1QdhqKTJW1yJA8VTTb+awgIzL eb9wkc9LLhNIS4VSkNTkbBqchHxk8CCUIXe6uH8FArTJB55i0u3mQfStneS+3qclVzmw qDkgWdfTuS6MBoi2pK8LJiP7ZfCvg/bRKYQaMCTcgr790lpSK28bEshaKvxb8e1BgdbL Lt8NDugCYHDVVxFembH3CFjOtyJLLZckOeOJhgUMJGAldcdT6opJBqqfEZwU0RnzzK8+ T7QpTX8A2omaloX7SYFDVzjpVB48Z5JQ2i+Zuc2kcYme9/suDC9+LHjC1aDWBRN3OFR6 zeiA== X-Gm-Message-State: ALoCoQltUW+3RQAH5yQl+9lODY5aWsQn68y5dH943JDJ7vkcnOr16Ule/zDOYh8TydIoY4zwqLO1Hoc5BsZeQvis7jYfdqXbvuvED2uRP8FPqKvBgyYlp+wQmaIJYiNHQgPCcfzCrq/kct0Qkbj9e8VdBKPl3cQN3Q== X-Received: by 10.50.152.35 with SMTP id uv3mr14513100igb.46.1412345027827; Fri, 03 Oct 2014 07:03:47 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.152.35 with SMTP id uv3mr14513051igb.46.1412345027472; Fri, 03 Oct 2014 07:03:47 -0700 (PDT) Received: by 10.43.61.201 with HTTP; Fri, 3 Oct 2014 07:03:47 -0700 (PDT) In-Reply-To: <542B7D74.4090302@yandex.ru> References: <542B7D74.4090302@yandex.ru> Date: Fri, 3 Oct 2014 10:03:47 -0400 Message-ID: Subject: Re: Addressing refcount issues in ip6_setdstifaddr and ip6_getdstifaddr routines. From: Vedant Mathur To: "Andrey V. Elsukov" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Oct 2014 14:04:00 -0000 Andrey, Not a bad option. I saw you deleted the ip6_findaux routine which is used in route6_input. You have a ifdef around it. Whats that for? -Vedant On Wed, Oct 1, 2014 at 12:05 AM, Andrey V. Elsukov wrote: > On 30.09.2014 19:24, Vedant Mathur wrote: > > *Solution 2:* > > > > In ip6_setdstifaddr() routine we can access the struct ifa using > > ia6->ia_ifa and retrieve the IP address from the ifa and then push it > > into the m_tag instead of the struct in6_ifaddr pointer. Then we will > > not require a refcnt increment and in the ip6_getdstifaddr() we can > > use the ifa_withifaddr() routines to retrieve the ia by basically > > looping through the list of ifaddrs. > > > > Hi, > > *Solution 3:* > > Remove this code :) > What you think about this? > https://svnweb.freebsd.org/base?view=revision&revision=256673 > > -- > WBR, Andrey V. Elsukov > From owner-freebsd-net@FreeBSD.ORG Fri Oct 3 14:04:17 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41F1BAB7 for ; Fri, 3 Oct 2014 14:04:17 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 18ECE117 for ; Fri, 3 Oct 2014 14:04:17 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BEC05B985; Fri, 3 Oct 2014 10:04:15 -0400 (EDT) From: John Baldwin To: Jason Wolfe Subject: Re: ixgbe(4) spin lock held too long Date: Fri, 03 Oct 2014 08:52:10 -0400 Message-ID: <2951452.cFrDFFRBbl@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) In-Reply-To: References: <1410203348.1343.1.camel@bruno> <1577813.IPE4JfnhZd@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 03 Oct 2014 10:04:15 -0400 (EDT) Cc: freebsd-net@freebsd.org, Eric van Gyzen X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Oct 2014 14:04:17 -0000 On Thursday, October 02, 2014 06:40:21 PM Jason Wolfe wrote: > On Wed, Sep 10, 2014 at 8:24 AM, John Baldwin wrote: > > On Monday, September 08, 2014 03:34:02 PM Eric van Gyzen wrote: > > > On 09/08/2014 15:19, Sean Bruno wrote: > > > > On Mon, 2014-09-08 at 12:09 -0700, Sean Bruno wrote: > > > >> This sort of looks like the hardware failed to respond to us in time? > > > >> Too busy? > > > >> > > > >> sean > > > > > > > > This seems to be affecting my 10/stable machines from 15Aug2014. > > > > > > > > Not a lot of churn in the code so I don't think this is new. The > > > > afflicted machines, quite a few by my count, appear to have not been > > > > super busy (pushing about 200 Mb/s). > > > > > > > > sean > > > > > > > >> panic: spin lock held too long > > > >> > > > >> GNU gdb 6.1.1 [FreeBSD] > > > >> Copyright 2004 Free Software Foundation, Inc. > > > >> GDB is free software, covered by the GNU General Public License, and > > > > you > > > > > >> are > > > >> welcome to change it and/or distribute copies of it under certain > > > >> conditions. > > > >> Type "show copying" to see the conditions. > > > >> There is absolutely no warranty for GDB. Type "show warranty" for > > > >> details. > > > >> This GDB was configured as "amd64-marcel-freebsd"... > > > >> > > > >> Unread portion of the kernel message buffer: > > > >> spin lock 0xffffffff812a0400 (callout) held by 0xfffff800151fe000 > > > >> (tid > > > >> 100003) too long > > > > > > TID 100003 is usually a kernel idle thread, which would seem to indicate > > > a dangling lock. Can you enable WITNESS (without WITNESS_SKIPSPIN) on > > > this box? > > > > Also, do 'tid 100003' and 'bt' in kgdb to see what the thread holding the > > lock > > was doing. > > > > -- > > John Baldwin > > Sorry for the delay, I've been hoping to catch a crash on one of our > machines running the WITNESS kernel. Our luck seems to be in short supply, > the machines running sans WITNESS crash in the same manner at a rate of 2/3 > a day. I may have to grow the pool to catch this, but in the meantime here > is the bt/tid. > > (kgdb) bt 1000003 > #0 0xffffffff80ac39b8 in cpustop_handler () at > /usr/src/sys/amd64/amd64/mp_machdep.c:1432 > #1 0xffffffff80ac397f in ipi_nmi_handler () at > /usr/src/sys/amd64/amd64/mp_machdep.c:1417 > #2 0xffffffff80ad2d5a in trap (frame=0xffffffff81242830) at > /usr/src/sys/amd64/amd64/trap.c:190 > #3 0xffffffff80ab93c3 in nmi_calltrap () at > /usr/src/sys/amd64/amd64/exception.S:505 > #4 0xffffffff80734066 in callout_process (now=3278964590047193) at > /usr/src/sys/kern/kern_timeout.c:487 > (kgdb) tid 100003 > [Switching to thread 40 (Thread 100003)]#0 0xffffffff80ac39b8 in > cpustop_handler () at /usr/src/sys/amd64/amd64/mp_machdep.c:1432 > 1432 savectx(&stoppcbs[cpu]); Ok, so it is processing C_DIRECT callouts. Can you go to frame 4 and see where it is at? -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Oct 3 14:56:01 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5870DF8 for ; Fri, 3 Oct 2014 14:56:01 +0000 (UTC) Received: from forward7l.mail.yandex.net (forward7l.mail.yandex.net [IPv6:2a02:6b8:0:1819::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E9C68C9 for ; Fri, 3 Oct 2014 14:56:01 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward7l.mail.yandex.net (Yandex) with ESMTP id B764EBC1408; Fri, 3 Oct 2014 18:55:48 +0400 (MSK) Received: from smtp13.mail.yandex.net (localhost [127.0.0.1]) by smtp13.mail.yandex.net (Yandex) with ESMTP id 38A0EE40060; Fri, 3 Oct 2014 18:55:48 +0400 (MSK) Received: from unknown (unknown [2a02:6b8:0:c33::101]) by smtp13.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id e4E9KfHtGd-tl3m7PMI; Fri, 3 Oct 2014 18:55:47 +0400 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: c0861bd5-dc6d-4668-8d32-f9477b902b5f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1412348147; bh=ss9Wu+qZp2wVkoDinS6lSrMV8M0N97omM9/M8/FOe58=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=WXf3wF0cE4ZTtYm2MX+g2yH5Otp+4t6lbKFwY5b+81mAGrj8eEUqH+HoAGHhnKXG6 B1mG0IRsoOgrICsLyRhQq952MDftEnayM8jmLBCtu58/INXwfGCkC5fV/GlOvuN52g iHZEGWkKvtjfAuq0c6VuF8Rufop4aNywwJSZYuUQ= Authentication-Results: smtp13.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <542EB8A7.8060202@yandex.ru> Date: Fri, 03 Oct 2014 18:54:31 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Vedant Mathur Subject: Re: Addressing refcount issues in ip6_setdstifaddr and ip6_getdstifaddr routines. References: <542B7D74.4090302@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Oct 2014 14:56:02 -0000 On 03.10.2014 18:03, Vedant Mathur wrote: > Andrey, > > Not a bad option. I saw you deleted the ip6_findaux routine which is > used in route6_input. You have a ifdef around it. Whats that for? Hi, It isn't my ifdef, it was here and never has been used in FreeBSD. Probably similar functional will be needed when mobile IPv6 support will be added. -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Fri Oct 3 17:32:01 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0F7CB3E; Fri, 3 Oct 2014 17:32:00 +0000 (UTC) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9EC63C79; Fri, 3 Oct 2014 17:32:00 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id c9so1334468qcz.8 for ; Fri, 03 Oct 2014 10:31: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:message-id:subject :from:to:cc:content-type; bh=xOtc314qXnPlVEXUrVn8rMskN9JXDdJSyCjopq+/EaU=; b=VfoPe/mqljkRkMhvrrrJxNhTtA+YTiuDiDxxuCj+Q6KJD3XeIJN9edGyLb3EfSPsZi 60Yhq5nFv4poYl0GfZgNsV+Z7xXCRcJZL1SuLHLaK9GXKxczT4oG96wJqYFtW0Pt0DXU FbaZlf2h9rSzd1Otfal56nnW/LQ5N8VtZcMLpQ3LafzIIuWAmIzKst3MmbzFgjt8Hy+A 15tbrxPJgccEGi4amc2GphTyc/ZIlW5VOx+O49DC3zFcCJ+PB2JUETpiEwv3I9gYyMW5 UasKWftfX607/rjSOgKkqGQcCO9dTWaavLvpOmX0flJvdZW/VFpwNHjn3DsqjRZChNUm ahrA== MIME-Version: 1.0 X-Received: by 10.224.60.129 with SMTP id p1mr5572068qah.99.1412357516721; Fri, 03 Oct 2014 10:31:56 -0700 (PDT) Sender: hiren.panchasara@gmail.com Received: by 10.96.168.194 with HTTP; Fri, 3 Oct 2014 10:31:56 -0700 (PDT) In-Reply-To: <20141003080150.GL29361@mordor.lan> References: <20141002164202.GI29361@mordor.lan> <20141002181958.GJ29361@mordor.lan> <20141003080150.GL29361@mordor.lan> Date: Fri, 3 Oct 2014 10:31:56 -0700 X-Google-Sender-Auth: Dfij3evTil2z_1b8Sb5CUNJfED0 Message-ID: Subject: Re: [jcigar@ulb.ac.be: Listen queue overflow: 8 already in queue awaiting acceptance] From: hiren panchasara To: Julien Cigar Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" , FreeBSD Stable Mailing List X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Oct 2014 17:32:01 -0000 On Fri, Oct 3, 2014 at 1:01 AM, Julien Cigar wrote: > On Thu, Oct 02, 2014 at 04:36:49PM -0700, hiren panchasara wrote: >> On Thu, Oct 2, 2014 at 11:19 AM, Julien Cigar wrote: >> > On Thu, Oct 02, 2014 at 10:24:13AM -0700, hiren panchasara wrote: >> >> On Thu, Oct 2, 2014 at 9:42 AM, Julien Cigar wrote: >> >> > sorry for cross-posting, I'm forwarding this as it seems that part of >> >> > the problem is also related to: >> >> > https://lists.freebsd.org/pipermail/freebsd-net/2014-September/039664.html >> >> >> >> Umm, this looks like a different problem than the subject of this email. >> > >> > yes and no, seems the same hardware (HP and igb) and I have also some >> > "requests for mbufs denied" (https://dpaste.de/t8kJ/raw) without any >> > reasons. I should add that the box hanged a week ago and I had to do a >> > hard reboot, I have the feeling that it's somewhat related to this >> > problem .. >> > >> I suggest you try to debug these 2 problems separately. Did you get a >> chance to look at kgdb to find the culprit process as I suggested >> below? > > I tried what you suggested, but I get a "No struct type named inpcb" > Any idea ? :) Is your kernel not build with debug symbols? Can you share your kernconf? I have following in my kernconf: makeoptions DEBUG=-g options KDB options KDB_TRACE options DDB cheers, Hiren >> >> cheers, >> Hiren >> >> > >> >> > I also wonder if something has been fixed in -STABLE in this area .. >> >> > >> >> > (please keep me in CC as I'm not subscribed on freebsd-net@ an >> >> > freebsd-stable@) >> >> > >> >> > -- >> >> > Julien Cigar >> >> > Belgian Biodiversity Platform (http://www.biodiversity.be) >> >> > PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0 >> >> > No trees were killed in the creation of this message. >> >> > However, many electrons were terribly inconvenienced. >> >> > >> >> > >> >> > ---------- Forwarded message ---------- >> >> > From: Julien Cigar >> >> > To: freebsd-questions@freebsd.org >> >> > Cc: >> >> > Date: Thu, 2 Oct 2014 11:52:06 +0200 >> >> > Subject: Listen queue overflow: 8 already in queue awaiting acceptance >> >> > Hello, >> >> > >> >> > I'm running 10-RELEASE on a HP Proliant DL160 Gen8 and I'm seeing the >> >> > following in my kernel logs: >> >> > sonewconn: pcb 0xfffff8010e561310: Listen queue overflow: 8 already in >> >> > queue awaiting acceptance >> >> >> >> This usually means the application is not keeping up with the incoming >> >> connections. >> >> > >> >> > I already raised kern.ipc.soacceptqueue to 1024 and netstat -naA | grep >> >> > "fffff8010e561310" returns nothing >> >> >> >> This is the usual way of finding the culprit process. If this doesn't >> >> return anything, it probably means that it is a short-lived process. >> >> >> >> Here is an example of what you could do: >> >> >> >> sonewconn: pcb 0xfffff8008f40cb10: Listen queue overflow: 1 already in queue >> >> awaiting acceptance >> >> >> >> From kgdb, >> >> (kgdb) p ((struct inpcb *)0xfffff8008f40cb10)->inp_inc >> >> $3 = {inc_flags = 0 '\0', inc_len = 0 '\0', inc_fibnum = 0, inc_ie = {ie_fport >> >> = 0, ie_lport = 10295, ie_dependfaddr = { >> >> ie46_foreign = {ia46_pad32 = {0, 0, 0}, ia46_addr4 = {s_addr = 0}}, >> >> ie6_foreign = {__u6_addr = { >> >> __u6_addr8 = '\0' , __u6_addr16 = {0, 0, 0, 0, 0, >> >> 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}}, >> >> ie_dependladdr = {ie46_local = {ia46_pad32 = {0, 0, 0}, ia46_addr4 = >> >> {s_addr = 0}}, ie6_local = {__u6_addr = { >> >> __u6_addr8 = '\0' , __u6_addr16 = {0, 0, 0, 0, 0, >> >> 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}}}} >> >> >> >> Here, ie_lport = 10295 which is in n/w byte order and converting it to host >> >> byte order, 10295 -> 0x2837 and swapping them gives us 0x3728 which is 14120. >> >> >> >> Now, use sockstat to find out what process is on that port: >> >> >> >> $ sockstat -l | grep 14120 >> >> >> >> cheers, >> >> Hiren >> > >> > -- >> > Julien Cigar >> > Belgian Biodiversity Platform (http://www.biodiversity.be) >> > PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0 >> > No trees were killed in the creation of this message. >> > However, many electrons were terribly inconvenienced. > > -- > Julien Cigar > Belgian Biodiversity Platform (http://www.biodiversity.be) > PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0 > No trees were killed in the creation of this message. > However, many electrons were terribly inconvenienced. From owner-freebsd-net@FreeBSD.ORG Sat Oct 4 00:55:42 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 797982E9 for ; Sat, 4 Oct 2014 00:55:42 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6197968A for ; Sat, 4 Oct 2014 00:55:42 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s940tgFE093864 for ; Sat, 4 Oct 2014 00:55:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193053] ixgbe(4) IXGBE_LEGACY_TX + ALTQ path broken Date: Sat, 04 Oct 2014 00:55:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dan_256@yahoo.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 04 Oct 2014 00:55:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053 Dan changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dan_256@yahoo.com --- Comment #10 from Dan --- On 10.1-RC1, with the change below, I still get the dreaded "pfctl: igb1: driver does not support altq". If ixgbe is targeted for 10.1-RELEASE, can igb be fixed as well? Index: sys/modules/igb/Makefile =================================================================== --- sys/modules/igb/Makefile (revision 272488) +++ sys/modules/igb/Makefile (working copy) @@ -21,7 +21,7 @@ # instead use the older if_start non-multiqueue capable interface. # This might be desireable for testing, or to enable the use of # ALTQ. -#CFLAGS += -DIGB_LEGACY_TX +CFLAGS += -DIGB_LEGACY_TX .if !defined(KERNBUILDDIR) .if ${MK_INET_SUPPORT} != "no" I posted more about it here: https://forums.freebsd.org/viewtopic.php?f=44&t=48283 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sat Oct 4 01:56:15 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ECBC06FC for ; Sat, 4 Oct 2014 01:56:15 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D4AB5B8A for ; Sat, 4 Oct 2014 01:56:15 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s941uFb2066310 for ; Sat, 4 Oct 2014 01:56:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193053] ixgbe(4) IXGBE_LEGACY_TX + ALTQ path broken Date: Sat, 04 Oct 2014 01:56:16 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ncrogers@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 04 Oct 2014 01:56:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053 --- Comment #11 from ncrogers@gmail.com --- (In reply to Dan from comment #10) > On 10.1-RC1, with the change below, I still get the dreaded "pfctl: igb1: > driver does not support altq". If ixgbe is targeted for 10.1-RELEASE, can > igb be fixed as well? > > Index: sys/modules/igb/Makefile > =================================================================== > --- sys/modules/igb/Makefile (revision 272488) > +++ sys/modules/igb/Makefile (working copy) > @@ -21,7 +21,7 @@ > # instead use the older if_start non-multiqueue capable interface. > # This might be desireable for testing, or to enable the use of > # ALTQ. > -#CFLAGS += -DIGB_LEGACY_TX > +CFLAGS += -DIGB_LEGACY_TX > > .if !defined(KERNBUILDDIR) > .if ${MK_INET_SUPPORT} != "no" > > I posted more about it here: > > https://forums.freebsd.org/viewtopic.php?f=44&t=48283 I've always had to add #define IXGBE_LEGACY_TX to sys/dev/e1000/if_igb.c and sys/dev/e1000/if_igb.h to get it to work. Uncommenting CFLAGS in the igb Makefile doesn't work when compiling a kernel. I believe it needs to be added as a kernel option of some kind to be cleaner. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sat Oct 4 05:02:08 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1B6DBC2 for ; Sat, 4 Oct 2014 05:02:08 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9027BE5A for ; Sat, 4 Oct 2014 05:02:08 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9452863009698 for ; Sat, 4 Oct 2014 05:02:08 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193053] ixgbe(4) IXGBE_LEGACY_TX + ALTQ path broken Date: Sat, 04 Oct 2014 05:02:08 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dan_256@yahoo.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 04 Oct 2014 05:02:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053 --- Comment #12 from Dan --- (In reply to ncrogers from comment #11) > (In reply to Dan from comment #10) > > On 10.1-RC1, with the change below, I still get the dreaded "pfctl: igb1: > > driver does not support altq". If ixgbe is targeted for 10.1-RELEASE, can > > igb be fixed as well? > > > > Index: sys/modules/igb/Makefile > > =================================================================== > > --- sys/modules/igb/Makefile (revision 272488) > > +++ sys/modules/igb/Makefile (working copy) > > @@ -21,7 +21,7 @@ > > # instead use the older if_start non-multiqueue capable interface. > > # This might be desireable for testing, or to enable the use of > > # ALTQ. > > -#CFLAGS += -DIGB_LEGACY_TX > > +CFLAGS += -DIGB_LEGACY_TX > > > > .if !defined(KERNBUILDDIR) > > .if ${MK_INET_SUPPORT} != "no" > > > > I posted more about it here: > > > > https://forums.freebsd.org/viewtopic.php?f=44&t=48283 > > I've always had to add #define IXGBE_LEGACY_TX to sys/dev/e1000/if_igb.c and > sys/dev/e1000/if_igb.h to get it to work. Uncommenting CFLAGS in the igb > Makefile doesn't work when compiling a kernel. I believe it needs to be > added as a kernel option of some kind to be cleaner. I guess in the last 3 years, no one has bother to do it because they keep secretly hoping we can stop using legacy mode to use ALTQ :) Pretty sure it would be easy to add as a kernel option. I even saw a thread where someone described what it would take. I wonder why it never got committed. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sat Oct 4 05:24:40 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F5D9E82 for ; Sat, 4 Oct 2014 05:24:40 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 26DC9FEB for ; Sat, 4 Oct 2014 05:24:40 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s945OejU060563 for ; Sat, 4 Oct 2014 05:24:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193053] ixgbe(4) IXGBE_LEGACY_TX + ALTQ path broken Date: Sat, 04 Oct 2014 05:24:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dan_256@yahoo.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 04 Oct 2014 05:24:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053 --- Comment #13 from Dan --- Thanks, btw. That worked. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sat Oct 4 12:37:04 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B56562A; Sat, 4 Oct 2014 12:37:04 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2812FD2B; Sat, 4 Oct 2014 12:37:04 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XaKaj-000O7E-Ql; Sat, 04 Oct 2014 12:21:25 +0400 Message-ID: <542FE9A7.9090208@FreeBSD.org> Date: Sat, 04 Oct 2014 16:35:51 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" , freebsd-ipfw , freebsd-current@freebsd.org Subject: HEADS UP: Merging projects/ipfw to HEAD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 04 Oct 2014 12:37:04 -0000 Hi, I'm going to merge projects/ipfw branch to HEAD in the middle of next week. What has changed: Main user-visible changes are related to tables: * Tables are now identified by names, not numbers. There can be up to 65k tables with up to 63-byte long names. * Tables are now set-aware (default off), so you can switch/move them atomically with rules. * More functionality is supported (swap, lock, limits, user-level lookup, batched add/del) by generic table code. * New table types are added (flow) so you can match multiple packet fields at once. * Ability to add different type of lookup algorithms for particular table type has been added. * New table algorithms are added (cidr:hash, iface:array, number:array and flow:hash) to make certain types of lookup more effective. * Table value are now capable of holding multiple data fields for different tablearg users Some examples (see ipfw(8) manual page for the description): 0:02 [2] zfscurr0# ipfw table fl2 create type flow:src-ip,proto,dst-port algo flow:hash valtype skipto,fib 0:02 [2] zfscurr0# ipfw table fl2 info +++ table(fl2), set(0) +++ kindex: 0, type: flow:src-ip,proto,dst-port valtype: number, references: 0 algorithm: flow:hash items: 0, size: 280 0:02 [2] zfscurr0# ipfw table fl2 add 2a02:6b8::333,tcp,443 45000,12 0:02 [2] zfscurr0# ipfw table fl2 add 10.0.0.92,tcp,80 22000,13 0:02 [2] zfscurr0# ipfw table fl2 list +++ table(fl2), set(0) +++ 2a02:6b8::333,6,443 45000 10.0.0.92,6,80 22000 0:02 [2] zfscurr0# ipfw add 200 count tcp from me to 78.46.89.105 80 flow 'table(fl2)' ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64" ipfw table mi_test add 10.0.0.8/30 ipfw table mi_test add 2a02:6b8:b010::1/64 25 # ipfw table si add 1.1.1.1/32 1111 2.2.2.2/32 2222 added: 1.1.1.1/32 1111 added: 2.2.2.2/32 2222 # ipfw table si add 2.2.2.2/32 2200 4.4.4.4/32 4444 exists: 2.2.2.2/32 2200 added: 4.4.4.4/32 4444 ipfw: Adding record failed: record already exists ^^^^^ Returns error but keeps inserted items # ipfw table si list +++ table(si), set(0) +++ 1.1.1.1/32 1111 2.2.2.2/32 2222 4.4.4.4/32 4444 # ipfw table si atomic add 3.3.3.3/32 3333 4.4.4.4/32 4400 5.5.5.5/32 5555 added(reverted): 3.3.3.3/32 3333 exists: 4.4.4.4/32 4400 ignored: 5.5.5.5/32 5555 ipfw: Adding record failed: record already exists ^^^^^ Returns error and reverts added records Performance changes: * Main ipfw lock was converted to rmlock * Rule counters were separated from rule itself and made per-cpu. * Radix table entries fits into 128 bytes * struct ip_fw is now more compact so more rules will fit into 64 bytes * interface tables uses array of existing ifindexes for faster match ABI changes: All functionality supported by old ipfw(8) remains functional. Old & new binaries can work together with the following restrictions: * Tables named other than ^\d+$ are shown as table(65535) in ruleset in old binaries * I'm a bit unsure about "lookup src-port|dst-port N" case, something may be broken here. Anyway, this can be fixed for MFC Internal changes:. Changing table ids to numbers resulted in format modification for most sockopt codes. Old sopt format was compact, but very hard to extend (no versioning, inability to add more opcodes), so * All relevant opcodes were converted to TLV-based versioned IP_FW3-based codes. * The remaining opcodes were also converted to be able to eliminate all older opcodes at once * All IP_FW3 handlers uses special API instead of calling sooptcopy* directly to ease adding another communication methods * struct ip_fw is now different for kernel and userland * tablearg value has been changed to 0 to ease future extensions * table "values" are now indexes in special value array which holds extended data for given index * Batched add/delete has been added to tables code * Most changes has been done to permit batched rule addition. * interface tracking API has been added (started on demand) to permit effective interface tables operations * O(1) skipto cache, currently turned off by default at compile-time (eats 512K). * Several steps has been made towards making libipfw: * most of new functions were separated into "parse/prepare/show and actuall-do-stuff" pieces (already merged). * there are separate functions for parsing text string into "struct ip_fw" and printing "struct ip_fw" to supplied buffer (already merged). * Probably some more less significant/forgotten features From owner-freebsd-net@FreeBSD.ORG Sat Oct 4 14:01:11 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D9F4EFB for ; Sat, 4 Oct 2014 14:01:11 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [67.212.89.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D152D775 for ; Sat, 4 Oct 2014 14:01:10 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id 82596139D0 for ; Sat, 4 Oct 2014 11:01:15 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-transfer-encoding:content-type:content-type :in-reply-to:references:subject:subject:to:mime-version :user-agent:from:from:date:date:message-id; s=dkim; t= 1412431273; x=1413295274; bh=AS37+3uAaTCUxEXbayXDYCQJWIGyE0DD85d ighK4A00=; b=UpoU3jLXQy/cW/JxGjR5xUr/WVNUA9QHePx+jJlT+8GIm4VE3br 5TS+zkcs/f2IhIkLeJNjQtYl0PoYtNMfB4Wyfr8SA8bSL3N5peSBdWaUdnBsGzoz TuCjo/fYM5oY1GxhvHRGbT7s0oIdzzZGX2ijH/L9d96NXfvf4EcnqMco= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4zoBXL5n-aA for ; Sat, 4 Oct 2014 11:01:13 -0300 (BRT) Received: from [192.168.10.208] (unknown [186.193.54.69]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id E92B5139C8 for ; Sat, 4 Oct 2014 11:01:11 -0300 (BRT) Message-ID: <542FFD95.5050200@bsdinfo.com.br> Date: Sat, 04 Oct 2014 11:00:53 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: HEADS UP: Merging projects/ipfw to HEAD References: <542FE9A7.9090208@FreeBSD.org> In-Reply-To: <542FE9A7.9090208@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 04 Oct 2014 14:01:11 -0000 Excellent work! :) I really enjoyed the news. This new ipfwcome with FreeBSD 10.1 release? Cheers, Gondim On 04/10/2014 09:35, Alexander V. Chernikov wrote: > Hi, > > I'm going to merge projects/ipfw branch to HEAD in the middle of next > week. > > What has changed: > > Main user-visible changes are related to tables: > > * Tables are now identified by names, not numbers. There can be up to > 65k tables with up to 63-byte long names. > * Tables are now set-aware (default off), so you can switch/move them > atomically with rules. > * More functionality is supported (swap, lock, limits, user-level > lookup, batched add/del) by generic table code. > * New table types are added (flow) so you can match multiple packet > fields at once. > * Ability to add different type of lookup algorithms for particular > table type has been added. > * New table algorithms are added (cidr:hash, iface:array, number:array > and flow:hash) to make certain types of lookup more effective. > * Table value are now capable of holding multiple data fields for > different tablearg users > > Some examples (see ipfw(8) manual page for the description): > > 0:02 [2] zfscurr0# ipfw table fl2 create type > flow:src-ip,proto,dst-port algo flow:hash valtype skipto,fib > 0:02 [2] zfscurr0# ipfw table fl2 info > +++ table(fl2), set(0) +++ > kindex: 0, type: flow:src-ip,proto,dst-port > valtype: number, references: 0 > algorithm: flow:hash > items: 0, size: 280 > 0:02 [2] zfscurr0# ipfw table fl2 add 2a02:6b8::333,tcp,443 45000,12 > 0:02 [2] zfscurr0# ipfw table fl2 add 10.0.0.92,tcp,80 22000,13 > 0:02 [2] zfscurr0# ipfw table fl2 list > +++ table(fl2), set(0) +++ > 2a02:6b8::333,6,443 45000 > 10.0.0.92,6,80 22000 > 0:02 [2] zfscurr0# ipfw add 200 count tcp from me to 78.46.89.105 > 80 flow 'table(fl2)' > > ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64" > ipfw table mi_test add 10.0.0.8/30 > ipfw table mi_test add 2a02:6b8:b010::1/64 25 > > # ipfw table si add 1.1.1.1/32 1111 2.2.2.2/32 2222 > added: 1.1.1.1/32 1111 > added: 2.2.2.2/32 2222 > # ipfw table si add 2.2.2.2/32 2200 4.4.4.4/32 4444 > exists: 2.2.2.2/32 2200 > added: 4.4.4.4/32 4444 > ipfw: Adding record failed: record already exists > ^^^^^ Returns error but keeps inserted items > # ipfw table si list > +++ table(si), set(0) +++ > 1.1.1.1/32 1111 > 2.2.2.2/32 2222 > 4.4.4.4/32 4444 > # ipfw table si atomic add 3.3.3.3/32 3333 4.4.4.4/32 4400 > 5.5.5.5/32 5555 > added(reverted): 3.3.3.3/32 3333 > exists: 4.4.4.4/32 4400 > ignored: 5.5.5.5/32 5555 > ipfw: Adding record failed: record already exists > ^^^^^ Returns error and reverts added records > > Performance changes: > * Main ipfw lock was converted to rmlock > * Rule counters were separated from rule itself and made per-cpu. > * Radix table entries fits into 128 bytes > * struct ip_fw is now more compact so more rules will fit into 64 bytes > * interface tables uses array of existing ifindexes for faster match > > ABI changes: > All functionality supported by old ipfw(8) remains functional. Old & > new binaries can work together with the following restrictions: > * Tables named other than ^\d+$ are shown as table(65535) in ruleset > in old binaries > * I'm a bit unsure about "lookup src-port|dst-port N" case, something > may be broken here. Anyway, this can be fixed for MFC > > Internal changes:. > Changing table ids to numbers resulted in format modification for most > sockopt codes. > Old sopt format was compact, but very hard to extend (no versioning, > inability to add more opcodes), so > * All relevant opcodes were converted to TLV-based versioned > IP_FW3-based codes. > * The remaining opcodes were also converted to be able to eliminate > all older opcodes at once > * All IP_FW3 handlers uses special API instead of calling sooptcopy* > directly to ease adding another communication methods > * struct ip_fw is now different for kernel and userland > * tablearg value has been changed to 0 to ease future extensions > * table "values" are now indexes in special value array which holds > extended data for given index > * Batched add/delete has been added to tables code > * Most changes has been done to permit batched rule addition. > * interface tracking API has been added (started on demand) to permit > effective interface tables operations > * O(1) skipto cache, currently turned off by default at compile-time > (eats 512K). > > * Several steps has been made towards making libipfw: > * most of new functions were separated into "parse/prepare/show and > actuall-do-stuff" pieces (already merged). > * there are separate functions for parsing text string into "struct > ip_fw" and printing "struct ip_fw" to supplied buffer (already merged). > * Probably some more less significant/forgotten features