From owner-freebsd-net@FreeBSD.ORG Sun Sep 21 10:08:33 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1884A14F for ; Sun, 21 Sep 2014 10:08:33 +0000 (UTC) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) (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 E23CC6BD for ; Sun, 21 Sep 2014 10:08:32 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id fb1so2753286pad.41 for ; Sun, 21 Sep 2014 03:08:25 -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 :subject:content-type:content-transfer-encoding; bh=uiJ9kA+X2n34yFIT2X85Ric9BmQC/Dm9m4F3ZIMi/BU=; b=QbfdgbrKZ3miaPtpYvoAjDWg47G2R2rq3lIIuZJEc/AjvxWBnCsl6dBO8Uq17N20ad 6xvv7H8iQB9VaCLXJJ7e5utnlahe0MXx2+E5Yg+OwhcNVKQ9fjXFOPs8nTTLrW+C2R/X wDw79C7b7gAZ2u81krP0VETt985QPM+nc2gTrW6ZJg0P4LQ0QPkhIk/rqNda32omj0Qz O/GYaCVPR8kgZmXOZqK3a3r4fjjcH78lc9Qphw1jEdVyR+9ENZpJ/P6G2OteJZlDVpYI bqb40Ms2rHfCovm1woV9zxewJKkJqqsnrXfK4A+9Cm4Not5S1s5Q36WFF5dbxI9KMUBX watQ== X-Gm-Message-State: ALoCoQls6p6ZSJaEZoqp7rtoqRHveue+3C+hMGowrCv4uLi4i8JB/G7wUcKgLLPMra2SID5rgbG6 X-Received: by 10.70.118.9 with SMTP id ki9mr18434577pdb.104.1411294105584; Sun, 21 Sep 2014 03:08:25 -0700 (PDT) Received: from [113.11.122.237] ([113.11.122.237]) by mx.google.com with ESMTPSA id ju4sm6427889pbc.6.2014.09.21.03.08.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Sep 2014 03:08:25 -0700 (PDT) Message-ID: <541EA396.7050201@winterei.se> Date: Sun, 21 Sep 2014 19:08:22 +0900 From: "Paul S." User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: IP fast forwarding and setkey Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.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, 21 Sep 2014 10:08:33 -0000 Hi folks, I plan to make an edge router out of a freebsd system with OpenBGPD + FreeBSD 10, or such. I've been reading up, and noticed that the net.inet.ip.fastforwarding flag provides rather nice performance benefits. My issue is, my upstream networks insist on using TCP MD5 authentication on their BGP sessions. This is fine, except on FreeBSD -- I'm going to have to use the setkey utility to set those since native PF_KEY support for OpenBGPD does not seem available. Now, since setkey is part of IPSec, and there are countless warnings about using IPSec and fastforwarding together in the manpage, am I correct in assuming that this will not work if I have fastforwarding enabled? Is there any way to make it work? Quagga, from what I've read, seems to also be in the same boat (Usage of setkey required for TCP MD5). I tried searching the manpages, but couldn't locate anything concrete on this. Any assistance/replies are welcome. Thank you! From owner-freebsd-net@FreeBSD.ORG Sun Sep 21 10:26: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D56E3AC for ; Sun, 21 Sep 2014 10:26:43 +0000 (UTC) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::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 407408A0 for ; Sun, 21 Sep 2014 10:26:43 +0000 (UTC) Received: by mail-pd0-f181.google.com with SMTP id r10so2636476pdi.40 for ; Sun, 21 Sep 2014 03:26:42 -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=aT+kgMB3sicscnPgaQGLShns+LaBlxp2Bdehtk7c9Co=; b=yGeCGXCfcX/iGQQXQxHPl3qwTHeb2YGWR0XVjUZh9iroaVyOMSEEDg/ujxfbEFwQS8 iBhGv2OhXihdYvvsqs6mzzmfaYla3Xx+gi0IfFGJIvKfDL9ZP8iQ3azBjWxVpJXa/4q9 5GUVDsLo+behouwFnBJM+68Zq6J64sUSTNcHskA7+gb/F9JO8hhSL55z14VNUMblWu5g av0giSx/tjk61hM0KsmwLvvkwAC4e3W5EzvtArgysrgedI2McsNVkBFLIjZtc9KFXLg7 Qel9eXw6FmHGWcbZmX6U/Z6DdBYZZCkRiTY4krCCbcVLbFqIAns5bCdXybDbgSG88js1 Wxvg== MIME-Version: 1.0 X-Received: by 10.66.158.200 with SMTP id ww8mr17210421pab.15.1411295202716; Sun, 21 Sep 2014 03:26:42 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.70.102.80 with HTTP; Sun, 21 Sep 2014 03:26:42 -0700 (PDT) In-Reply-To: <541EA396.7050201@winterei.se> References: <541EA396.7050201@winterei.se> Date: Sun, 21 Sep 2014 12:26:42 +0200 X-Google-Sender-Auth: S13FHijzSte1DrVAK8jj031azLM Message-ID: Subject: Re: IP fast forwarding and setkey From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= To: "Paul S." 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: Sun, 21 Sep 2014 10:26:43 -0000 If for you is an option pfSense has all the hard work done for you and you can use it for such installations. On Sun, Sep 21, 2014 at 12:08 PM, Paul S. wrote: > Hi folks, > > I plan to make an edge router out of a freebsd system with OpenBGPD + > FreeBSD 10, or such. > > I've been reading up, and noticed that the net.inet.ip.fastforwarding flag > provides rather nice performance benefits. > > My issue is, my upstream networks insist on using TCP MD5 authentication > on their BGP sessions. > > This is fine, except on FreeBSD -- I'm going to have to use the setkey > utility to set those since native PF_KEY support for OpenBGPD does not seem > available. > > Now, since setkey is part of IPSec, and there are countless warnings about > using IPSec and fastforwarding together in the manpage, am I correct in > assuming that this will not work if I have fastforwarding enabled? > > Is there any way to make it work? Quagga, from what I've read, seems to > also be in the same boat (Usage of setkey required for TCP MD5). > > I tried searching the manpages, but couldn't locate anything concrete on > this. > > Any assistance/replies are welcome. > > Thank you! > _______________________________________________ > 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 Sun Sep 21 10:31:34 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE0AF4E3 for ; Sun, 21 Sep 2014 10:31:34 +0000 (UTC) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) (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 AEFFE8D7 for ; Sun, 21 Sep 2014 10:31:34 +0000 (UTC) Received: by mail-pa0-f47.google.com with SMTP id et14so2727171pad.34 for ; Sun, 21 Sep 2014 03:31:28 -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=CLL3poenNP01+Zfhgp0yGR6jRANEbdQGxycbxO0+pCo=; b=mAGrrZsDjexE/mw3O7RGqorpfO08WMyG2XBzDFapOnjHHvGLEPV5vTmCjq3tj4UkVN 2zzUqwHl1eKyLplF17PZzCCUiFmwJgoqk5SyT7O+bM2OGE/OdqyZjzN/5x2CRbtkLNsN i0q8PU9cMa2WRcMVQrORRvz7q+zcZSO8d9EzU+puWMbAt8tsJTqgM+pf4ZyxDR1QtfWG 2r0Ba/+QaZ1lDsShopWAB6RlgeNJDOVYov78DN23H0S4POMZHBEQ85qHrCHWrzFRqxnw A1IMsdVFfkqMdgsDNrA6OTBw9+lI5qIZ5PXihvTntIN59DSX31WTXFfr3kQ2lEtgyf3D 3tHQ== X-Gm-Message-State: ALoCoQkQ7S2NzzvROq4hfRdLUj1r61NHSJ4lg8RJ8H0UfKpm7ZmbSTsd3BVA3zG617dBa1lz4X+H X-Received: by 10.70.118.97 with SMTP id kl1mr1438769pdb.163.1411295488644; Sun, 21 Sep 2014 03:31:28 -0700 (PDT) Received: from [113.11.122.237] ([113.11.122.237]) by mx.google.com with ESMTPSA id fn4sm6504128pab.39.2014.09.21.03.31.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Sep 2014 03:31:28 -0700 (PDT) Message-ID: <541EA8FE.5080905@winterei.se> Date: Sun, 21 Sep 2014 19:31:26 +0900 From: "Paul S." User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?RXJtYWwgTHXDp2k=?= Subject: Re: IP fast forwarding and setkey References: <541EA396.7050201@winterei.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: Sun, 21 Sep 2014 10:31:35 -0000 Ermal, I'd prefer a raw BSD installation (Call it a comfort thing, if you will). Has the pfSense project actually managed to patch OpenBGPD to remove its dependency on OpenBSD specific bindings for TCP_MD5? It might be worth it to just try to build their fork, if that's the case. Thank you for responding! On 9/21/2014 午後 07:26, Ermal Luçi wrote: > If for you is an option pfSense has all the hard work done for you and > you can use it for such installations. > > On Sun, Sep 21, 2014 at 12:08 PM, Paul S. > wrote: > > Hi folks, > > I plan to make an edge router out of a freebsd system with > OpenBGPD + FreeBSD 10, or such. > > I've been reading up, and noticed that the > net.inet.ip.fastforwarding flag provides rather nice performance > benefits. > > My issue is, my upstream networks insist on using TCP MD5 > authentication on their BGP sessions. > > This is fine, except on FreeBSD -- I'm going to have to use the > setkey utility to set those since native PF_KEY support for > OpenBGPD does not seem available. > > Now, since setkey is part of IPSec, and there are countless > warnings about using IPSec and fastforwarding together in the > manpage, am I correct in assuming that this will not work if I > have fastforwarding enabled? > > Is there any way to make it work? Quagga, from what I've read, > seems to also be in the same boat (Usage of setkey required for > TCP MD5). > > I tried searching the manpages, but couldn't locate anything > concrete on this. > > Any assistance/replies are welcome. > > Thank you! > _______________________________________________ > 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 Sun Sep 21 10:35:57 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F194670B for ; Sun, 21 Sep 2014 10:35:57 +0000 (UTC) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::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 C3604977 for ; Sun, 21 Sep 2014 10:35:57 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id ey11so3130695pad.14 for ; Sun, 21 Sep 2014 03:35: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=Ma7jBKv8wMP6ONZHi5PQIPOwJYIYFjnF+ovOlNE1Vyc=; b=lxQ8ZFvs7sLALdjrBte4SEenAd5ugDd0s96utvJpeRZ7J+YwL9KamCrmFxfT62omDZ ao7LvXr/L4s8t8tPGmGV96AAwMkoo5S9ojl8smUR4oHRzhmyKaFcPewnI9gYuqkymKjJ KO6w91IgB4X02J45L2jkAdgs3qix+rBLu+PBdI9D8tQJ/07c0smmqJLEbXqLu483wlIK tk/cE2Vhir0ezvBXiOaEatFfCPX5n8o7EHfOY7St442OBXx4Lxb71Ie1r0o5oinYiHRZ FKrYysFuGxeZ270mERxR02S+J0qMCXIGuqIQn8zwOdpd9o+H7lhpV2PwhN4SYEB1skyp zhsw== MIME-Version: 1.0 X-Received: by 10.68.69.38 with SMTP id b6mr14242870pbu.70.1411295757286; Sun, 21 Sep 2014 03:35:57 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.70.102.80 with HTTP; Sun, 21 Sep 2014 03:35:57 -0700 (PDT) In-Reply-To: <541EA8FE.5080905@winterei.se> References: <541EA396.7050201@winterei.se> <541EA8FE.5080905@winterei.se> Date: Sun, 21 Sep 2014 12:35:57 +0200 X-Google-Sender-Auth: -po8j8dL54dzrmOrSkYlSGu1Leg Message-ID: Subject: Re: IP fast forwarding and setkey From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= To: "Paul S." 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: Sun, 21 Sep 2014 10:35:58 -0000 On Sun, Sep 21, 2014 at 12:31 PM, Paul S. wrote: > Ermal, > > I'd prefer a raw BSD installation (Call it a comfort thing, if you will). > > Has the pfSense project actually managed to patch OpenBGPD to remove its > dependency on OpenBSD specific bindings for TCP_MD5? > > It might be worth it to just try to build their fork, if that's the case. > > Thank you for responding! > > Yeah OpenBGPd port of pfSense has the support for installing SPDs without setkey. > > On 9/21/2014 =E5=8D=88=E5=BE=8C 07:26, Ermal Lu=C3=A7i wrote: > > If for you is an option pfSense has all the hard work done for you and yo= u > can use it for such installations. > > On Sun, Sep 21, 2014 at 12:08 PM, Paul S. wrote: > >> Hi folks, >> >> I plan to make an edge router out of a freebsd system with OpenBGPD + >> FreeBSD 10, or such. >> >> I've been reading up, and noticed that the net.inet.ip.fastforwarding >> flag provides rather nice performance benefits. >> >> My issue is, my upstream networks insist on using TCP MD5 authentication >> on their BGP sessions. >> >> This is fine, except on FreeBSD -- I'm going to have to use the setkey >> utility to set those since native PF_KEY support for OpenBGPD does not s= eem >> available. >> >> Now, since setkey is part of IPSec, and there are countless warnings >> about using IPSec and fastforwarding together in the manpage, am I corre= ct >> in assuming that this will not work if I have fastforwarding enabled? >> >> Is there any way to make it work? Quagga, from what I've read, seems to >> also be in the same boat (Usage of setkey required for TCP MD5). >> >> I tried searching the manpages, but couldn't locate anything concrete on >> this. >> >> Any assistance/replies are welcome. >> >> Thank you! >> _______________________________________________ >> 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 > > > --=20 Ermal From owner-freebsd-net@FreeBSD.ORG Sun Sep 21 11:41:12 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2230CF4C for ; Sun, 21 Sep 2014 11:41:12 +0000 (UTC) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) (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 E36ADEDF for ; Sun, 21 Sep 2014 11:41:11 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id kx10so2843754pab.2 for ; Sun, 21 Sep 2014 04:41:05 -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=DjEWft6kF4hdKfRpmhIKbVrAJJNe1UdnCsuaNLrPPsI=; b=X1DBJ3YgFcMFo/4feMuzGcld6NiY/AnKyCcOSTyUTYJiqtv/3YyntaDK2/rl+dqzYj 0eK8LjGQ+n4YS7ru0renYFPjLHw4ZJgDq49JVCsCZav5UW2IuU8p3+so/TcE5KyFvnrL 6Jv5As1wUj3pwjwRL+n6rxYlK3vUHoo+ppI23Sz4fqjEoW4yCurKxtVstj31riHkCl06 uEAXz4T4e6OmvkcUJAeBUhMuVoBWIfPkCCz/Dy9rAvbFTFTO+i8AWgaV2aYo3kjZDbzl b/F08INimZza3m0kouYWLzp+8KyoHSHdd9CmifFTxjxuFILzVNMMmtcTrr39CIy4JoBT MZIQ== X-Gm-Message-State: ALoCoQn/St5eAfTEveMFqrCmtk/ivHKkuszUojEYgeT3lqzR1pUSZHZ9bFLOVgguE6p4qc+hYBDr X-Received: by 10.68.245.135 with SMTP id xo7mr2397728pbc.161.1411299665196; Sun, 21 Sep 2014 04:41:05 -0700 (PDT) Received: from [113.11.122.237] ([113.11.122.237]) by mx.google.com with ESMTPSA id i4sm6595533pdk.54.2014.09.21.04.41.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Sep 2014 04:41:04 -0700 (PDT) Message-ID: <541EB94E.3050500@winterei.se> Date: Sun, 21 Sep 2014 20:41:02 +0900 From: "Paul S." User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?RXJtYWwgTHXDp2k=?= Subject: Re: IP fast forwarding and setkey References: <541EA396.7050201@winterei.se> <541EA8FE.5080905@winterei.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: Sun, 21 Sep 2014 11:41:12 -0000 Interesting. Would you happen to know where I could obtain sources to their version of OpenBGPD, then? Thanks! On 9/21/2014 午後 07:35, Ermal Luçi wrote: > > > On Sun, Sep 21, 2014 at 12:31 PM, Paul S. > wrote: > > Ermal, > > I'd prefer a raw BSD installation (Call it a comfort thing, if you > will). > > Has the pfSense project actually managed to patch OpenBGPD to > remove its dependency on OpenBSD specific bindings for TCP_MD5? > > It might be worth it to just try to build their fork, if that's > the case. > > Thank you for responding! > > > Yeah OpenBGPd port of pfSense has the support for installing SPDs > without setkey. > > > On 9/21/2014 午後 07:26, Ermal Luçi wrote: >> If for you is an option pfSense has all the hard work done for >> you and you can use it for such installations. >> >> On Sun, Sep 21, 2014 at 12:08 PM, Paul S. > > wrote: >> >> Hi folks, >> >> I plan to make an edge router out of a freebsd system with >> OpenBGPD + FreeBSD 10, or such. >> >> I've been reading up, and noticed that the >> net.inet.ip.fastforwarding flag provides rather nice >> performance benefits. >> >> My issue is, my upstream networks insist on using TCP MD5 >> authentication on their BGP sessions. >> >> This is fine, except on FreeBSD -- I'm going to have to use >> the setkey utility to set those since native PF_KEY support >> for OpenBGPD does not seem available. >> >> Now, since setkey is part of IPSec, and there are countless >> warnings about using IPSec and fastforwarding together in the >> manpage, am I correct in assuming that this will not work if >> I have fastforwarding enabled? >> >> Is there any way to make it work? Quagga, from what I've >> read, seems to also be in the same boat (Usage of setkey >> required for TCP MD5). >> >> I tried searching the manpages, but couldn't locate anything >> concrete on this. >> >> Any assistance/replies are welcome. >> >> Thank you! >> _______________________________________________ >> 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 > > > > > -- > Ermal From owner-freebsd-net@FreeBSD.ORG Sun Sep 21 12:13:29 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F120B1C for ; Sun, 21 Sep 2014 12:13:29 +0000 (UTC) Received: from sender1.zohomail.com (sender1.zohomail.com [74.201.84.156]) by mx1.freebsd.org (Postfix) with ESMTP id 407A2236 for ; Sun, 21 Sep 2014 12:13:28 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=subject:from:to:content-type:date:message-id:mime-version; b=jUKi2p6zROkOLTli3KgQxDiu9UJLOhFDeTFoVo6qh31OiNVOYsbcfIyJxf4ryXu1LmmddyffbOeb 0eF3/viYvISmMswt2yb9B6pLcS37c9ZjbMQ1soDS/m9CgkdseE9T Received: from [192.168.0.100] (host-176-36-82-223.la.net.ua [176.36.82.223]) by mx.zohomail.com with SMTPS id 141130160175125.734277567280287; Sun, 21 Sep 2014 05:13:21 -0700 (PDT) Subject: getting factory MAC address From: clutton To: freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" Date: Sun, 21 Sep 2014 15:13:17 +0300 Message-ID: <1411301597.21088.7.camel@eva02> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-ZohoMailClient: External X-Zoho-Virus-Status: 2 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, 21 Sep 2014 12:13:29 -0000 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 From owner-freebsd-net@FreeBSD.ORG Sun Sep 21 14:01:33 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B218F9 for ; Sun, 21 Sep 2014 14:01:33 +0000 (UTC) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) (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 0A146D0C for ; Sun, 21 Sep 2014 14:01:32 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id lf10so2883306pab.8 for ; Sun, 21 Sep 2014 07:01: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:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=pTr9gZLWyr2NcK0KnsP3JehaIWZYaUcfbOgdcINWo98=; b=T6Irm2xHM0cRmwzHWpVJlZVJ6QTyLfUaY+QYaCC8uzaPv9O90D4xlePUkdYjTTsbjv ddoH2u0tzhWV8G4qR6SecNAmCs8Yv8ta+fPGd72BFim1mOZTqv3WN+6Rf4v0tSRvtp28 fcjks/6c3p8ON7/43mzNl9Y04XMNG45RGzwJaA0wUsJ3xnDUTPTeks8OkGg6ZZV46Fpk R2XuR0VFH9EApOF8sbUQioo5I06gq+axBjJXzItY2YHVJ8v7j1IxoTuJ/OG+GyvOs++A CiuQ4PIbWLOUXHz8e05EpnOvmZBw3P5xewbzUbMLDo4CI/RBbRlYo+XwD1TgXau1F4al epYA== X-Gm-Message-State: ALoCoQmx37+g3J/G8RBanW13jQUBIrAXgyT+CIbX54NwlLbsx3VDyO1JPZgSdzicKiOVo0bQ/pSl X-Received: by 10.70.98.201 with SMTP id ek9mr4274596pdb.150.1411308086125; Sun, 21 Sep 2014 07:01:26 -0700 (PDT) Received: from [113.11.122.237] ([113.11.122.237]) by mx.google.com with ESMTPSA id q1sm6843259pdq.67.2014.09.21.07.01.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Sep 2014 07:01:25 -0700 (PDT) Message-ID: <541EDA32.3080007@winterei.se> Date: Sun, 21 Sep 2014 23:01:22 +0900 From: "Paul S." User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?RXJtYWwgTHXDp2k=?= Subject: [Solved] Re: IP fast forwarding and setkey References: <541EA396.7050201@winterei.se> <541EA8FE.5080905@winterei.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: Sun, 21 Sep 2014 14:01:33 -0000 So, just to notify -- I got a copy of the pfsense port of OpenBGPD (available from the pfsense-tools repository -- see https://forum.pfsense.org/index.php?topic=76132.0) and TCP-MD5 indeed does work in the build. Configuring local-address per peer is mandatory, however. I think it uses that to configure the SPDs. Cheers! On 9/21/2014 午後 07:35, Ermal Luçi wrote: > > > On Sun, Sep 21, 2014 at 12:31 PM, Paul S. > wrote: > > Ermal, > > I'd prefer a raw BSD installation (Call it a comfort thing, if you > will). > > Has the pfSense project actually managed to patch OpenBGPD to > remove its dependency on OpenBSD specific bindings for TCP_MD5? > > It might be worth it to just try to build their fork, if that's > the case. > > Thank you for responding! > > > Yeah OpenBGPd port of pfSense has the support for installing SPDs > without setkey. > > > On 9/21/2014 午後 07:26, Ermal Luçi wrote: >> If for you is an option pfSense has all the hard work done for >> you and you can use it for such installations. >> >> On Sun, Sep 21, 2014 at 12:08 PM, Paul S. > > wrote: >> >> Hi folks, >> >> I plan to make an edge router out of a freebsd system with >> OpenBGPD + FreeBSD 10, or such. >> >> I've been reading up, and noticed that the >> net.inet.ip.fastforwarding flag provides rather nice >> performance benefits. >> >> My issue is, my upstream networks insist on using TCP MD5 >> authentication on their BGP sessions. >> >> This is fine, except on FreeBSD -- I'm going to have to use >> the setkey utility to set those since native PF_KEY support >> for OpenBGPD does not seem available. >> >> Now, since setkey is part of IPSec, and there are countless >> warnings about using IPSec and fastforwarding together in the >> manpage, am I correct in assuming that this will not work if >> I have fastforwarding enabled? >> >> Is there any way to make it work? Quagga, from what I've >> read, seems to also be in the same boat (Usage of setkey >> required for TCP MD5). >> >> I tried searching the manpages, but couldn't locate anything >> concrete on this. >> >> Any assistance/replies are welcome. >> >> Thank you! >> _______________________________________________ >> 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 > > > > > -- > Ermal From owner-freebsd-net@FreeBSD.ORG Sun Sep 21 15:42:14 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7142A1D0 for ; Sun, 21 Sep 2014 15:42:14 +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 09F698C8 for ; Sun, 21 Sep 2014 15:42:13 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id z2so1691248wiv.5 for ; Sun, 21 Sep 2014 08:42:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=UF5+aSFtvRwXJ7hEBvBCNG7dak0wN5OwvZCCzJ7Yk2k=; b=UhGNCxSBA9ZzU47rye6SHym9zOdMXGvGF9skc9M9bKQH9K+569dkCUBlMMFUTB7z3X h9B0xKnanwOnGMtQ9FSG2u8ZBHrY6fGZjTiKg6ctzURQdHsHEQ7Vz8AIgpm2BhtNTR3q MaMaNHhhRye1B1GgCrC4WwOeyuDijIhB9T+P0ZHY7GVwqjbLa+yrR5l5HehhYfJf7Hty zah+as6kfaWPuM0sjOlQbIOSdR5BAd0osEFO1S3looPERMNnJC7rnq7/Rsd8P4IZ6SeR OuKu/+3ptjiiR9PWQ6xVZuwPNzI6J+HpgVfOEgE7wt8I7Xo5hbkOU58xhTJC9kJdr/bn Jwaw== X-Received: by 10.194.88.195 with SMTP id bi3mr14960129wjb.10.1411314131352; Sun, 21 Sep 2014 08:42:11 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.194.240.102 with HTTP; Sun, 21 Sep 2014 08:41:51 -0700 (PDT) In-Reply-To: <541EA396.7050201@winterei.se> References: <541EA396.7050201@winterei.se> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Sun, 21 Sep 2014 17:41:51 +0200 X-Google-Sender-Auth: FmVqLg9fvhjdqEZ7HDzEz6pbL4Y Message-ID: Subject: Re: IP fast forwarding and setkey To: "Paul S." Content-Type: text/plain; charset=ISO-8859-1 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: Sun, 21 Sep 2014 15:42:14 -0000 On Sun, Sep 21, 2014 at 12:08 PM, Paul S. wrote: > Hi folks, > > I plan to make an edge router out of a freebsd system with OpenBGPD + > FreeBSD 10, or such. > > I've been reading up, and noticed that the net.inet.ip.fastforwarding flag > provides rather nice performance benefits. > > My issue is, my upstream networks insist on using TCP MD5 authentication > on their BGP sessions. > > This is fine, except on FreeBSD -- I'm going to have to use the setkey > utility to set those since native PF_KEY support for OpenBGPD does not seem > available. > > Now, since setkey is part of IPSec, and there are countless warnings about > using IPSec and fastforwarding together in the manpage, am I correct in > assuming that this will not work if I have fastforwarding enabled? > > Is there any way to make it work? Quagga, from what I've read, seems to > also be in the same boat (Usage of setkey required for TCP MD5). > > fastforwarding is not compatible with IPSec only but can be used with TCP_MD5 without problem (tested on FreeBSD 10-stable). Regards, Olivier From owner-freebsd-net@FreeBSD.ORG Sun Sep 21 18:45: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1E6BCF1E for ; Sun, 21 Sep 2014 18:45:00 +0000 (UTC) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (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 CD0C7A0E for ; Sun, 21 Sep 2014 18:44:58 +0000 (UTC) Received: by mail-qg0-f49.google.com with SMTP id q107so1982868qgd.36 for ; Sun, 21 Sep 2014 11:44:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=s9ODZQYerZ5qAuMB1voMEvyw+SLlrmvOxG9qhM1nUJ4=; b=a0dttom66aE+rM/FthvmoWz7NEYQueWpnaa3WReAq4llKdpjePOcwXZpJOuL4gQUnr yVOk64fsg54L/wJGeqpT3+9Zpdkesj+S+xAb7Bnivz6xAJSfwfDykr0rmjmiwwbKCzgM Aikn4phqqm3Z8KF01O+4E5b5bEDRsLVfbVk2tuHCNFZ/C9UB8emXHS5XI74+2nGTQreI rz3dBNmVRYkNapuYr0fP88ivRpkI7zBUf3skaQ4QVm7u/TI6f1bgfpW3lwobwwhjReXZ l2eMcQyn7yebTmX74x8SJKS8dTeLehQGAUD8IG2HbaqTbxfIxQRKcekh3meL8AU4RnYi Stag== X-Gm-Message-State: ALoCoQnZT80ByoI515MHTnbPYp+Yrs1blcpi/Ojct9uVmxiPTOQRL+OUKsYuDUOMIGJF6extZXhF X-Received: by 10.140.23.177 with SMTP id 46mr16988282qgp.64.1411325091847; Sun, 21 Sep 2014 11:44:51 -0700 (PDT) Received: from [29.134.39.245] (66-87-121-245.pools.spcsdns.net. [66.87.121.245]) by mx.google.com with ESMTPSA id s102sm6059343qgd.44.2014.09.21.11.44.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Sep 2014 11:44:50 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: IP fast forwarding and setkey From: Jim Thompson X-Mailer: iPhone Mail (12A365) In-Reply-To: Date: Sun, 21 Sep 2014 13:44:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2F5CE512-4C4F-4D6B-A6DA-C349CF75C54D@netgate.com> References: <541EA396.7050201@winterei.se> To: =?utf-8?Q?Olivier_Cochard-Labb=C3=A9?= Cc: "freebsd-net@freebsd.org" , "Paul 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: Sun, 21 Sep 2014 18:45:00 -0000 > On Sep 21, 2014, at 10:41, Olivier Cochard-Labb=C3=A9 = wrote: >=20 >> On Sun, Sep 21, 2014 at 12:08 PM, Paul S. wrote: >>=20 >> Hi folks, >>=20 >> I plan to make an edge router out of a freebsd system with OpenBGPD + >> FreeBSD 10, or such. >>=20 >> I've been reading up, and noticed that the net.inet.ip.fastforwarding fla= g >> provides rather nice performance benefits. >>=20 >> My issue is, my upstream networks insist on using TCP MD5 authentication >> on their BGP sessions. >>=20 >> This is fine, except on FreeBSD -- I'm going to have to use the setkey >> utility to set those since native PF_KEY support for OpenBGPD does not se= em >> available. >>=20 >> Now, since setkey is part of IPSec, and there are countless warnings abou= t >> using IPSec and fastforwarding together in the manpage, am I correct in >> assuming that this will not work if I have fastforwarding enabled? >>=20 >> Is there any way to make it work? Quagga, from what I've read, seems to >> also be in the same boat (Usage of setkey required for TCP MD5). > fastforwarding is not compatible with IPSec only but can be used with > TCP_MD5 without problem (tested on FreeBSD 10-stable). Even this is solvable, and will likely occur in a future version of pfSense.= =20 Jim From owner-freebsd-net@FreeBSD.ORG Sun Sep 21 21:00:23 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD02FD40 for ; Sun, 21 Sep 2014 21:00:23 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 9F0798A2 for ; Sun, 21 Sep 2014 21:00:23 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8LL0NZB019113 for ; Sun, 21 Sep 2014 21:00:23 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201409212100.s8LL0NZB019113@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, 21 Sep 2014 21:00:23 +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, 21 Sep 2014 21:00:23 -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 22 08:00:16 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B2425D4 for ; Mon, 22 Sep 2014 08:00:16 +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 4E010CC2 for ; Mon, 22 Sep 2014 08:00:16 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8M80GGg004559 for ; Mon, 22 Sep 2014 08:00:16 GMT (envelope-from bugzilla-noreply@freebsd.org) Message-Id: <201409220800.s8M80GGg004559@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, 22 Sep 2014 08:00:16 +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, 22 Sep 2014 08:00:16 -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 22 12:18:40 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32B5C29D; Mon, 22 Sep 2014 12:18:40 +0000 (UTC) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 D0BD0D85; Mon, 22 Sep 2014 12:18:39 +0000 (UTC) Received: by mail-qg0-f52.google.com with SMTP id j5so1811189qga.25 for ; Mon, 22 Sep 2014 05:18:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l7q4xn43AYPwUsyuVnrWBAEpbwpnhAI3bAPdYr7u77w=; b=c0TpLnKyk3ZARxiMxP9lapc316EQPfaQdqCXHSbxzo97pz7/yWURbAg7gziS1gmkKn H+wzxs6+KiVR4q0BzhC+MT0WRvN7y5pN+QXtbeebLPdTCY8ZreFMSFf5qjbn+gvvC4k2 wBUECvOCLErwuoN/ko5UC+whdArpE8XFdalZ7G6b9UmtrpjeFpr3jbtXlBeVY3LNDhcz HkOQOg+D+c/XbEzb8DpjEj/0VY7r1kfPpHcjByDNx+xaI1cQ3zgZj5+buoUqemt1D1KA zzBsq9dhaU5N2NwPOXRrLFH9ZjlcaKegjw2/cxG8Na+IbbRw9KbIqmZBR/m8FEjAD+FT bLig== MIME-Version: 1.0 X-Received: by 10.140.30.227 with SMTP id d90mr21776793qgd.55.1411388318852; Mon, 22 Sep 2014 05:18:38 -0700 (PDT) Received: by 10.140.104.241 with HTTP; Mon, 22 Sep 2014 05:18:38 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Sep 2014 14:18:38 +0200 Message-ID: Subject: Re: [RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD From: Stefano Garzarella To: Ryan Stone Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , freebsd-current , 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: Mon, 22 Sep 2014 12:18:40 -0000 Hi Ryan, in gso_dispatch(), I put the "eh_len" parameter in order to have the offset of the L3 header. In this way, if someone adds QinQ support, just call gso_dispatch() with the right length of the MAC header. During the execution the GSO, the MAC header is simply copied as it is in each new segment. Instead, for the vxlan support, we can define a new entries in gso_type, define a new "gso_functions" to properly handle these types of packets and mark the packet in the network stack with the correct GSO type. For now we used only 4 bit to encode the gso_type in m_pkthdr.csum_flags, but, in the future, we can use more bit or a specific field in the m_pkthdr. Your suggestions are very good, but I tried to make a software TSO, modifying as little as possible the network stack. Thanks, Stefano 2014-09-18 20:50 GMT+02:00 Ryan Stone : > On Wed, Sep 17, 2014 at 4:27 AM, Stefano Garzarella > wrote: > > Much of the advantage of TSO comes from crossing the network stack only > > once per (large) segment instead of once per 1500-byte frame. > > GSO does the same both for segmentation (TCP) and fragmentation (UDP) > > by doing these operations as late as possible. > > My initial impression is that this is a layering violation. Code like > this gives me pause: > > + eh = mtod(m, struct ether_vlan_header *); > + if (eh->evl_encap_proto == htons(ETHERTYPE_VLAN)) { > + eh_len = ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN; > + } else { > + eh_len = ETHER_HDR_LEN; > + } > + > + return gso_dispatch(ifp, m, eh_len); > > If someone adds QinQ support, this code must be updated. When vxlan > support comes in, we must update this code or else the outer UDP > packet gets fragmented instead of the inner TCP payload being > segmented. As more tunneling protocols get added to FreeBSD, the > dispatch code for GSO gets uglier and uglier. > > It seems to me that the real problem that we are trying to solve is a > lack of batching in the kernel. Currently the network stack operates > on the mbuf (packet) boundary. It seems to me that we could introduce > a "packet group" concept that is guaranteed to have the same L3 and L2 > endpoint. In the transmit path, we would initially have a single > (potentially oversized) packet in the group. When TCP segments the > packet, it would add each packet to the packet group and pass it down > the stack. Because we guarantee that the endpoints are the same for > every packet in the group, the L3 code can do a single routing table > lookup and the L2 code can do a single l2table lookup for the entire > group. > > The disadvantages of packet groups would be that: > a) You have touch a lot more code in a lot more places to take > advantage of the concept. > b) TSO inherently has the same layering problems. If we're going to > solve the problem for tunneling protocols then GSO might well be able > to take advantage of them. > -- *Stefano Garzarella* stefano.garzarella@gmail.com From owner-freebsd-net@FreeBSD.ORG Mon Sep 22 15:13:22 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2CC277E for ; Mon, 22 Sep 2014 15:13:21 +0000 (UTC) Received: from DUB004-OMC2S19.hotmail.com (dub004-omc2s19.hotmail.com [157.55.1.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F7D280E for ; Mon, 22 Sep 2014 15:13:21 +0000 (UTC) Received: from DUB125-W13 ([157.55.1.137]) by DUB004-OMC2S19.hotmail.com with Microsoft SMTPSVC(7.5.7601.22724); Mon, 22 Sep 2014 08:12:11 -0700 X-TMN: [YvOsUF6xfq2gYst9ajvxV3uz+WKBGdjf] X-Originating-Email: [elofu17@hotmail.com] Message-ID: From: Elof Ofel To: "freebsd-net@freebsd.org" Subject: How do I balance bandwidth over several virtual NICs? Date: Mon, 22 Sep 2014 17:12:11 +0200 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 22 Sep 2014 15:12:11.0948 (UTC) FILETIME=[95C93EC0:01CFD677] Content-Type: text/plain; charset="iso-8859-1" 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: Mon, 22 Sep 2014 15:13:22 -0000 I have a single NIC=2C mon0=2C that constantly receive 800 Mbps of mirrored= traffic. I want to split these 800 Mbps into smaller chunks and feed them to a coupl= e of virtual interfaces. Each virtual interface can then have instance of 'snort' inspecting its tra= ffic. Say approximately 200 Mbps per interface =3D four interfaces. That way=2C each of the four snort processes only get 200 Mbps of data to i= nspect instead of having *one* single snort process (single-threaded) tryin= g to cope with 800 Mbps. (the problem I'm trying to solve is utilizing all cpu's. Currently one cpu = runs snort at 100% while all the other cpu's idle.) The important thing though is that all packets in the connection need to be= diverted to the same virtual NIC. You can't send the SYN to NIC0 and the S= YN-ACK to NIC1=2C 'cause then neither snort-process-0 nor snort-process-1 s= ee the other side of the connection. The loadbalancing must be based on a hash built from at least the mac-addre= sses+IP-addresses. So=2C what I think I'm looking for is a way to configure a lagg0 interface = in loadbalance mode=2C that take all the incoming traffic on mon0 and distr= ibute it over four virtual member NICs. (these four NICs would then probabl= y be configured to run in monitor mode.) Do FreeBSD support what I'm looking for? How do I do it? Where should I loo= k? /Elof = From owner-freebsd-net@FreeBSD.ORG Mon Sep 22 16:45:30 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00658B05 for ; Mon, 22 Sep 2014 16:45:29 +0000 (UTC) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::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 B2E96332 for ; Mon, 22 Sep 2014 16:45:29 +0000 (UTC) Received: by mail-vc0-f177.google.com with SMTP id im17so4288045vcb.8 for ; Mon, 22 Sep 2014 09:45:28 -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:content-transfer-encoding; bh=NG9L+/8HaPyNHmJARvcS2TkTIOP+2Nma1jwlccYOT/U=; b=vHhw07S//dlQXxgLOU++NpHu+im76kbzoCCWWPZ/PcXhCcPAUykZjSZRGfFvXdDAwx zh2qBhCSHxNKFl/KIKaObfaVBfhgtkS2na2QWC2HpI8yc7QBC+/UH2uYeZhIpIJpg2sW 9HUMrmS/hky1P4du4D3qxevtuU9OWEn0J3gin87SUG2Ny4KeYMFoJaUUuaEMYtKR10CA JQ0YDiIrnJmI4bZiyCxuzKaKZOhK/KytCbXU11qkwuFKQUsJxEwHfPfg3vE3J7jIQ6Oh ybn0LJSl5K9nYi239xFXlQbNKeIcmUui8LuCc/ECsTao2X8rm2PbmX6Lj5F8SXjNw8qI /wCA== MIME-Version: 1.0 X-Received: by 10.221.9.1 with SMTP id ou1mr7877059vcb.60.1411404328753; Mon, 22 Sep 2014 09:45:28 -0700 (PDT) Sender: ndenev@gmail.com Received: by 10.220.168.202 with HTTP; Mon, 22 Sep 2014 09:45:28 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Sep 2014 18:45:28 +0200 X-Google-Sender-Auth: mf_UtKTUHagamj5DXasxH8HZ2_o Message-ID: Subject: Re: How do I balance bandwidth over several virtual NICs? From: Nikolay Denev To: Elof Ofel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, 22 Sep 2014 16:45:30 -0000 On Mon, Sep 22, 2014 at 5:12 PM, Elof Ofel wrote: > I have a single NIC, mon0, that constantly receive 800 Mbps of mirrored t= raffic. > I want to split these 800 Mbps into smaller chunks and feed them to a cou= ple of virtual interfaces. > Each virtual interface can then have instance of 'snort' inspecting its t= raffic. > > Say approximately 200 Mbps per interface =3D four interfaces. > That way, each of the four snort processes only get 200 Mbps of data to i= nspect instead of having *one* single snort process (single-threaded) tryin= g to cope with 800 Mbps. > > (the problem I'm trying to solve is utilizing all cpu's. Currently one cp= u runs snort at 100% while all the other cpu's idle.) > > > The important thing though is that all packets in the connection need to = be diverted to the same virtual NIC. You can't send the SYN to NIC0 and the= SYN-ACK to NIC1, 'cause then neither snort-process-0 nor snort-process-1 s= ee the other side of the connection. > The loadbalancing must be based on a hash built from at least the mac-add= resses+IP-addresses. > > > So, what I think I'm looking for is a way to configure a lagg0 interface = in loadbalance mode, that take all the incoming traffic on mon0 and distrib= ute it over four virtual member NICs. (these four NICs would then probably = be configured to run in monitor mode.) > > > Do FreeBSD support what I'm looking for? How do I do it? Where should I l= ook? > > /Elof > > _______________________________________________ > 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" Since this is below one Gig, would running separate snort processes on mon0 and using a BPF filter to split traffic work? --Nikolay From owner-freebsd-net@FreeBSD.ORG Mon Sep 22 19:07:16 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2A6CFFA for ; Mon, 22 Sep 2014 19:07:16 +0000 (UTC) Received: from DUB004-OMC3S33.hotmail.com (dub004-omc3s33.hotmail.com [157.55.2.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 32011864 for ; Mon, 22 Sep 2014 19:07:15 +0000 (UTC) Received: from DUB125-W85 ([157.55.2.8]) by DUB004-OMC3S33.hotmail.com with Microsoft SMTPSVC(7.5.7601.22724); Mon, 22 Sep 2014 12:06:06 -0700 X-TMN: [2ePILDCgEg8B1WM30oIL6n5T/r78BtO/] X-Originating-Email: [elofu17@hotmail.com] Message-ID: From: Elof Ofel To: Nikolay Denev Subject: RE: How do I balance bandwidth over several virtual NICs? Date: Mon, 22 Sep 2014 21:06:06 +0200 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 22 Sep 2014 19:06:06.0518 (UTC) FILETIME=[430AAD60:01CFD698] 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@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, 22 Sep 2014 19:07:16 -0000 Hi Nikolay. Unfortunetly no=2C that's not a solution. mon0 could in theory be a bridge0 with four 10 GE interfaces =3D 40 Gbps th= eoretical input that need to be distributed over multiple virtual NICs. Als= o=2C I have no control of the mirrored traffic=2C so it would be hard for m= e to build and maintain bpf filters that tries to roughly balance the bandw= idth load. Any other suggestions? /Elof > Date: Mon=2C 22 Sep 2014 18:45:28 +0200 > Subject: Re: How do I balance bandwidth over several virtual NICs? > From: nike_d@cytexbg.com > To: elofu17@hotmail.com > CC: freebsd-net@freebsd.org >=20 > On Mon=2C Sep 22=2C 2014 at 5:12 PM=2C Elof Ofel wr= ote: > > I have a single NIC=2C mon0=2C that constantly receive 800 Mbps of mirr= ored traffic. > > I want to split these 800 Mbps into smaller chunks and feed them to a c= ouple of virtual interfaces. > > Each virtual interface can then have instance of 'snort' inspecting its= traffic. > > > > Say approximately 200 Mbps per interface =3D four interfaces. > > That way=2C each of the four snort processes only get 200 Mbps of data = to inspect instead of having *one* single snort process (single-threaded) t= rying to cope with 800 Mbps. > > > > (the problem I'm trying to solve is utilizing all cpu's. Currently one = cpu runs snort at 100% while all the other cpu's idle.) > > > > > > The important thing though is that all packets in the connection need t= o be diverted to the same virtual NIC. You can't send the SYN to NIC0 and t= he SYN-ACK to NIC1=2C 'cause then neither snort-process-0 nor snort-process= -1 see the other side of the connection. > > The loadbalancing must be based on a hash built from at least the mac-a= ddresses+IP-addresses. > > > > > > So=2C what I think I'm looking for is a way to configure a lagg0 interf= ace in loadbalance mode=2C that take all the incoming traffic on mon0 and d= istribute it over four virtual member NICs. (these four NICs would then pro= bably be configured to run in monitor mode.) > > > > > > Do FreeBSD support what I'm looking for? How do I do it? Where should I= look? > > > > /Elof > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe=2C send any mail to "freebsd-net-unsubscribe@freebsd.org= " >=20 > Since this is below one Gig=2C would running separate snort processes on > mon0 and using a BPF filter to split traffic work? >=20 > --Nikolay = From owner-freebsd-net@FreeBSD.ORG Mon Sep 22 19:46: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60C34CC4 for ; Mon, 22 Sep 2014 19:46:03 +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 EDB84D38 for ; Mon, 22 Sep 2014 19:46:02 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id z2so3747567wiv.14 for ; Mon, 22 Sep 2014 12:46:01 -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:content-transfer-encoding; bh=PNpNghrk9N2R+Z9NnxnEe9ekLgigaoseeAfxVheUN9U=; b=zL1pXk9jEX6OUgBX0oUaFmejx1xvWHR5DO2YZuBmFrbBjzyDW7mrW/q1Bt1zN5eUA9 Az2y/F503Td3ID/gYmFoAZLfXxDmAotTcCte0ihaicFphKLgmMqujfaSaa7Mxtdu+xJi cuzsKxnakrdyjgwmutTK3o9fGnWZzj96WVAXsJbbZMM/gYvFgw0K2HckYNbaBpFNGxq1 OWkSB7oX17wk1m84BH/vU+4M8nTSppPVHdI34h0vhWwC20TjRMgmlggp3tKwFKLAYTAF 6bogKfhfmEUXVsE9dQdF/2JGly0q5GroMEq7MfbMLWiFQZra6ECD7550yPsTmCmWC/2k GN0Q== MIME-Version: 1.0 X-Received: by 10.194.187.241 with SMTP id fv17mr22979216wjc.13.1411415161171; Mon, 22 Sep 2014 12:46:01 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.199 with HTTP; Mon, 22 Sep 2014 12:46:01 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Sep 2014 12:46:01 -0700 X-Google-Sender-Auth: zGygxJ7miprKKrZAzn7gB-Z5JKM Message-ID: Subject: Re: How do I balance bandwidth over several virtual NICs? From: Adrian Chadd To: Elof Ofel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, 22 Sep 2014 19:46:03 -0000 Hi, Yes. * grab an ixgbe NIC and the -HEAD driver; (or cxgbe - I haven't gone and written RSS programming code for that just yet); * patch it to use a symmetric RSS key; * configure up N queues; * run an instance of snort on each TX/RX ring from the NIC. The last step requires that you have snort use netmap rather than just straight bpf - or maybe somehow there's a way to glue bpf into a single netmap ring. I haven't wrapped all of this up and thrown it into FreeBSD-HEAD yet, but i know that a symmetric RSS key works fine on 82599 hardware with a fixed driver. -a On 22 September 2014 12:06, Elof Ofel wrote: > Hi Nikolay. > > Unfortunetly no, that's not a solution. > mon0 could in theory be a bridge0 with four 10 GE interfaces =3D 40 Gbps = theoretical input that need to be distributed over multiple virtual NICs. A= lso, I have no control of the mirrored traffic, so it would be hard for me = to build and maintain bpf filters that tries to roughly balance the bandwid= th load. > > Any other suggestions? > > /Elof > >> Date: Mon, 22 Sep 2014 18:45:28 +0200 >> Subject: Re: How do I balance bandwidth over several virtual NICs? >> From: nike_d@cytexbg.com >> To: elofu17@hotmail.com >> CC: freebsd-net@freebsd.org >> >> On Mon, Sep 22, 2014 at 5:12 PM, Elof Ofel wrote: >> > I have a single NIC, mon0, that constantly receive 800 Mbps of mirrore= d traffic. >> > I want to split these 800 Mbps into smaller chunks and feed them to a = couple of virtual interfaces. >> > Each virtual interface can then have instance of 'snort' inspecting it= s traffic. >> > >> > Say approximately 200 Mbps per interface =3D four interfaces. >> > That way, each of the four snort processes only get 200 Mbps of data t= o inspect instead of having *one* single snort process (single-threaded) tr= ying to cope with 800 Mbps. >> > >> > (the problem I'm trying to solve is utilizing all cpu's. Currently one= cpu runs snort at 100% while all the other cpu's idle.) >> > >> > >> > The important thing though is that all packets in the connection need = to be diverted to the same virtual NIC. You can't send the SYN to NIC0 and = the SYN-ACK to NIC1, 'cause then neither snort-process-0 nor snort-process-= 1 see the other side of the connection. >> > The loadbalancing must be based on a hash built from at least the mac-= addresses+IP-addresses. >> > >> > >> > So, what I think I'm looking for is a way to configure a lagg0 interfa= ce in loadbalance mode, that take all the incoming traffic on mon0 and dist= ribute it over four virtual member NICs. (these four NICs would then probab= ly be configured to run in monitor mode.) >> > >> > >> > Do FreeBSD support what I'm looking for? How do I do it? Where should = I look? >> > >> > /Elof >> > >> > _______________________________________________ >> > 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" >> >> Since this is below one Gig, would running separate snort processes on >> mon0 and using a BPF filter to split traffic work? >> >> --Nikolay > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Sep 22 20:40: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11C93415; Mon, 22 Sep 2014 20:40:57 +0000 (UTC) Received: from DUB004-OMC4S24.hotmail.com (dub004-omc4s24.hotmail.com [157.55.2.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F2F063D; Mon, 22 Sep 2014 20:40:56 +0000 (UTC) Received: from DUB125-W51 ([157.55.2.72]) by DUB004-OMC4S24.hotmail.com with Microsoft SMTPSVC(7.5.7601.22724); Mon, 22 Sep 2014 13:39:45 -0700 X-TMN: [8uRS5kDYI7uaH97EiSuTvZ0DSIBOozyA] X-Originating-Email: [elofu17@hotmail.com] Message-ID: From: Elof Ofel To: Adrian Chadd Subject: RE: How do I balance bandwidth over several virtual NICs? Date: Mon, 22 Sep 2014 22:39:45 +0200 Importance: Normal In-Reply-To: References: , , , MIME-Version: 1.0 X-OriginalArrivalTime: 22 Sep 2014 20:39:45.0758 (UTC) FILETIME=[585EA7E0:01CFD6A5] 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@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, 22 Sep 2014 20:40:57 -0000 Hi Adrian! Now this sounds promising! All my sensors use the ixgbe driver. However=2C my skills in programming/compiling isn't vast. I know how to pat= ch and use poudriere. That's about it. I must admit I don't really understand what you mean with "patch it to use = a symmetric RSS key"=2C but it sounds like the functionality I'm looking fo= r is not yet there in the driver. If we assume that someone in the future write and submit the above into the= ixgbe driver=2C could I be so bold as to ask you for a commandline/configu= ration example (a brief guide) of how one would setup netmap and how to con= figure it to use the RX-queues? That way I can start playing around with netmap and learning it while I wai= t for the ixgbe driver to be updated... I've got two professional programme= r colleagues who've dealt extensively with e.g. the libnids and pfring sour= ce code=2C so if I get a grasp of how to setup netmap=2C and I find it inte= resting=2C it is likely that they can dive into and fix the ixgbe driver an= d improve it as per above. So please=2C can you help me with a "netmap guid= e"? When I try to find documentation or examples of how to setup netmap I find = none. Not even the netmap-enabled pcaplib contain any information as how to= use it. I'm no programmer=2C so showing me different C structs for deliver= ing data is of no use. :-/=20 I would very much like to improve the ixgbe driver and give back to the Fre= eBSD community rather than scrap FreeBSD and move to Linux and PF-RING. /Elof > Date: Mon=2C 22 Sep 2014 12:46:01 -0700 > Subject: Re: How do I balance bandwidth over several virtual NICs? > From: adrian@freebsd.org > To: elofu17@hotmail.com > CC: nike_d@cytexbg.com=3B freebsd-net@freebsd.org >=20 > Hi=2C >=20 > Yes. >=20 > * grab an ixgbe NIC and the -HEAD driver=3B (or cxgbe - I haven't gone > and written RSS programming code for that just yet)=3B > * patch it to use a symmetric RSS key=3B > * configure up N queues=3B > * run an instance of snort on each TX/RX ring from the NIC. >=20 > The last step requires that you have snort use netmap rather than just > straight bpf - or maybe somehow there's a way to glue bpf into a > single netmap ring. >=20 > I haven't wrapped all of this up and thrown it into FreeBSD-HEAD yet=2C > but i know that a symmetric RSS key works fine on 82599 hardware with > a fixed driver. >=20 >=20 > -a >=20 >=20 > On 22 September 2014 12:06=2C Elof Ofel wrote: > > Hi Nikolay. > > > > Unfortunetly no=2C that's not a solution. > > mon0 could in theory be a bridge0 with four 10 GE interfaces =3D 40 Gbp= s theoretical input that need to be distributed over multiple virtual NICs.= Also=2C I have no control of the mirrored traffic=2C so it would be hard f= or me to build and maintain bpf filters that tries to roughly balance the b= andwidth load. > > > > Any other suggestions? > > > > /Elof > > > >> Date: Mon=2C 22 Sep 2014 18:45:28 +0200 > >> Subject: Re: How do I balance bandwidth over several virtual NICs? > >> From: nike_d@cytexbg.com > >> To: elofu17@hotmail.com > >> CC: freebsd-net@freebsd.org > >> > >> On Mon=2C Sep 22=2C 2014 at 5:12 PM=2C Elof Ofel = wrote: > >> > I have a single NIC=2C mon0=2C that constantly receive 800 Mbps of m= irrored traffic. > >> > I want to split these 800 Mbps into smaller chunks and feed them to = a couple of virtual interfaces. > >> > Each virtual interface can then have instance of 'snort' inspecting = its traffic. > >> > > >> > Say approximately 200 Mbps per interface =3D four interfaces. > >> > That way=2C each of the four snort processes only get 200 Mbps of da= ta to inspect instead of having *one* single snort process (single-threaded= ) trying to cope with 800 Mbps. > >> > > >> > (the problem I'm trying to solve is utilizing all cpu's. Currently o= ne cpu runs snort at 100% while all the other cpu's idle.) > >> > > >> > > >> > The important thing though is that all packets in the connection nee= d to be diverted to the same virtual NIC. You can't send the SYN to NIC0 an= d the SYN-ACK to NIC1=2C 'cause then neither snort-process-0 nor snort-proc= ess-1 see the other side of the connection. > >> > The loadbalancing must be based on a hash built from at least the ma= c-addresses+IP-addresses. > >> > > >> > > >> > So=2C what I think I'm looking for is a way to configure a lagg0 int= erface in loadbalance mode=2C that take all the incoming traffic on mon0 an= d distribute it over four virtual member NICs. (these four NICs would then = probably be configured to run in monitor mode.) > >> > > >> > > >> > Do FreeBSD support what I'm looking for? How do I do it? Where shoul= d I look? > >> > > >> > /Elof > >> > > >> > _______________________________________________ > >> > freebsd-net@freebsd.org mailing list > >> > http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> > To unsubscribe=2C send any mail to "freebsd-net-unsubscribe@freebsd.= org" > >> > >> Since this is below one Gig=2C would running separate snort processes = on > >> mon0 and using a BPF filter to split traffic work? > >> > >> --Nikolay > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe=2C send any mail to "freebsd-net-unsubscribe@freebsd.org= " = From owner-freebsd-net@FreeBSD.ORG Mon Sep 22 22:15:04 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BAB60C9D for ; Mon, 22 Sep 2014 22:15:04 +0000 (UTC) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::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 52C63F7A for ; Mon, 22 Sep 2014 22:15:04 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id k14so3459900wgh.12 for ; Mon, 22 Sep 2014 15:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=M09xIKxQypfdoazG+OYbPv2CvjKk6L500Whetc2qudE=; b=vWcKO1ZhXPmTwZjoBGJz3f8fHEwT/BaGb044Aqvbox2oP4D6t4J4A8gmEHOAIbNE2E pGoWfqKboeAm8/2gjG2BEbQ5P8DCnikxjZT0A8sS4apwaPPwnkllxEc76dCX2JBJ64dA v2GefnQwD7YbS6e40bmTgVA/taCHphG1LqoxOX+5pGidx5vJTY+FtWySySMl9oygXTXg qaHKylhg4EJQ7KDXYxsIPoimDdgGleULhC141TJ2cX5OoEYYAytPrFhjYp8MQsriX3L7 4f4nn8AEx8OlObpnak6R5ATw6HXxha76YMc8N6qwfH5yaL0ospmIfcQGWuR3K2rG2kCw ePuA== MIME-Version: 1.0 X-Received: by 10.180.107.100 with SMTP id hb4mr17874642wib.59.1411424102622; Mon, 22 Sep 2014 15:15:02 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.199 with HTTP; Mon, 22 Sep 2014 15:15:02 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Sep 2014 15:15:02 -0700 X-Google-Sender-Auth: bUjsUqzQcOm3aVEcxett_pWDrAk Message-ID: Subject: Re: How do I balance bandwidth over several virtual NICs? From: Adrian Chadd To: Elof Ofel Content-Type: text/plain; charset=UTF-8 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, 22 Sep 2014 22:15:04 -0000 On 22 September 2014 13:39, Elof Ofel wrote: > Hi Adrian! > > Now this sounds promising! All my sensors use the ixgbe driver. > However, my skills in programming/compiling isn't vast. I know how to patch > and use poudriere. That's about it. > > I must admit I don't really understand what you mean with "patch it to use a > symmetric RSS key", but it sounds like the functionality I'm looking for is > not yet there in the driver. A few years ago a couple of researchers figured out you could abuse the toeplitz hash to do symmetric RSS hashing: http://www.ndsl.kaist.edu/~shinae/papers/TR-symRSS.pdf This means that the same RSS hash value is chosen no matter which direction the traffic is going on. This is what you need to ensure that the packets going both directions in a connection end up in the same NIC hardware receive ring. So, all you have to do (!) is: * grab freebsd-head, because the ixgbe driver there has some recent bug fixes that you need for this to completely work; * look at ixgbe_initialise_rss_mapping() - that's where the RSS key, mapping and RSS hash types are configured; * patch it to use the example symmetric RSS key that was provided in the paper; * patch it to only hash on IPv4 / IPv6 2-tuple, that way you don't end up with IPv4/IPv6 fragments in the wrong queue; * configure up say, 4 or 8 rings in /boot/loader.conf: hw.ix.num_queues=8 (I think it's hw.ix, it used to be hw.ixgbe..) * then, when you use netmap on ixgbe, you just bind to each TX and RX ring with a separate process or thread. That thread will get packets in both directions for a given flow. > If we assume that someone in the future write and submit the above into the > ixgbe driver, could I be so bold as to ask you for a > commandline/configuration example (a brief guide) of how one would setup > netmap and how to configure it to use the RX-queues? I don't know of any examples of using netmap in this way from the command line. I've normally written C code (And when I do, i start with the bridge example in src/tools/tools/netmap/bridge.c) . > That way I can start playing around with netmap and learning it while I wait > for the ixgbe driver to be updated... I've got two professional programmer > colleagues who've dealt extensively with e.g. the libnids and pfring source > code, so if I get a grasp of how to setup netmap, and I find it interesting, > it is likely that they can dive into and fix the ixgbe driver and improve it > as per above. So please, can you help me with a "netmap guide"? > > When I try to find documentation or examples of how to setup netmap I find > none. Not even the netmap-enabled pcaplib contain any information as how to > use it. I'm no programmer, so showing me different C structs for delivering > data is of no use. :-/ You mean: https://code.google.com/p/netmap-libpcap/ ? I've not used it before, sorry :( -a From owner-freebsd-net@FreeBSD.ORG Mon Sep 22 22:31:23 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79B26AC for ; Mon, 22 Sep 2014 22:31:23 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3967B1C9 for ; Mon, 22 Sep 2014 22:31:22 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s8MMVLI0094673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2014 15:31:22 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s8MMVLAh094672; Mon, 22 Sep 2014 15:31:21 -0700 (PDT) (envelope-from jmg) Date: Mon, 22 Sep 2014 15:31:21 -0700 From: John-Mark Gurney To: Elof Ofel Subject: Re: How do I balance bandwidth over several virtual NICs? Message-ID: <20140922223121.GU96798@funkthat.com> Mail-Followup-To: Elof Ofel , "freebsd-net@freebsd.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 22 Sep 2014 15:31:22 -0700 (PDT) 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, 22 Sep 2014 22:31:23 -0000 Elof Ofel wrote this message on Mon, Sep 22, 2014 at 17:12 +0200: > I have a single NIC, mon0, that constantly receive 800 Mbps of mirrored traffic. > I want to split these 800 Mbps into smaller chunks and feed them to a couple of virtual interfaces. > Each virtual interface can then have instance of 'snort' inspecting its traffic. > > Say approximately 200 Mbps per interface = four interfaces. > That way, each of the four snort processes only get 200 Mbps of data to inspect instead of having *one* single snort process (single-threaded) trying to cope with 800 Mbps. > > (the problem I'm trying to solve is utilizing all cpu's. Currently one cpu runs snort at 100% while all the other cpu's idle.) > > > The important thing though is that all packets in the connection need to be diverted to the same virtual NIC. You can't send the SYN to NIC0 and the SYN-ACK to NIC1, 'cause then neither snort-process-0 nor snort-process-1 see the other side of the connection. > The loadbalancing must be based on a hash built from at least the mac-addresses+IP-addresses. > > > So, what I think I'm looking for is a way to configure a lagg0 interface in loadbalance mode, that take all the incoming traffic on mon0 and distribute it over four virtual member NICs. (these four NICs would then probably be configured to run in monitor mode.) > > > Do FreeBSD support what I'm looking for? How do I do it? Where should I look? One possible option (and I say possible in that I have no clue if it would work) is to use lagg onto n tap interfaces... The lagg splits the traffic, and the tap interfaces accept it... Though you may have to do something special to throw away the traffic... You could also possibly do something similar w/ netgraph, say one2many+bpf (w/ basicly the same rule as lagg) to ng_ether.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Mon Sep 22 22:41:51 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 424FF4AF for ; Mon, 22 Sep 2014 22:41:51 +0000 (UTC) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) (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 028A52DD for ; Mon, 22 Sep 2014 22:41:50 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id o6so2173016oag.39 for ; Mon, 22 Sep 2014 15:41:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=0Z7hk5j6TQTbbetnAdsf9hRQeyE2XPpQRRNeT1TfKOs=; b=VX44a/7ml2PGdsD9tVQxhaLoVyMHQw5iqZXg9i4cbtswsqEzasOGLOOpYHftmdhsXK 3IV0eRw+U4bTtx5eA5H7rIUGSBJV0z4TjuY/Ph7UHDfwUpsYJKNYZKYDiuYReY7vJZ9s rM2HF2WC23d099YaEt8/Hhor+fTGpuRcqxLlZv6H6ucIfvQ47jei8gjFtPbBhkErO/lX 1+jYdEMRNvR5moZqF64jlFUBxDiYkGyPyCANaSqedUl7dF1D6sjtZhTblyCiEOmZWkiK M2E0cfg1S1osp20RLYzdgkM5obuHa5o1BcL6uAutYdrgNAOtstArJdsI/77dAnAspFCv Zckw== X-Gm-Message-State: ALoCoQkdxEoAUtquRjPGuE2JBX6pd3cWIEndtVoAvq6KWFQUhg2l9uU4bbKimi1Gsxx8IeSzyf7d X-Received: by 10.182.111.229 with SMTP id il5mr29433932obb.3.1411425312021; Mon, 22 Sep 2014 15:35:12 -0700 (PDT) Received: from ?IPv6:2610:160:11:33:5127:735b:4e0e:1c05? ([2610:160:11:33:5127:735b:4e0e:1c05]) by mx.google.com with ESMTPSA id j16sm6928866obe.5.2014.09.22.15.35.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Sep 2014 15:35:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1985.3\)) Subject: Re: How do I balance bandwidth over several virtual NICs? From: Jim Thompson In-Reply-To: Date: Mon, 22 Sep 2014 17:35:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <54200A0E-6337-40E1-B5DE-DC42F9CE8CCC@netgate.com> References: To: Adrian Chadd X-Mailer: Apple Mail (2.1985.3) Cc: "freebsd-net@freebsd.org" , Elof Ofel 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, 22 Sep 2014 22:41:51 -0000 > On Sep 22, 2014, at 5:15 PM, Adrian Chadd wrote: >=20 > On 22 September 2014 13:39, Elof Ofel wrote: >> Hi Adrian! >>=20 >> Now this sounds promising! All my sensors use the ixgbe driver. >> However, my skills in programming/compiling isn't vast. I know how to = patch >> and use poudriere. That's about it. >>=20 >> I must admit I don't really understand what you mean with "patch it = to use a >> symmetric RSS key", but it sounds like the functionality I'm looking = for is >> not yet there in the driver. >=20 > A few years ago a couple of researchers figured out you could abuse > the toeplitz hash to do symmetric RSS hashing: >=20 > http://www.ndsl.kaist.edu/~shinae/papers/TR-symRSS.pdf >=20 > This means that the same RSS hash value is chosen no matter which > direction the traffic is going on. > This is what you need to ensure that the packets going both directions > in a connection end up in the same NIC hardware receive ring. >=20 > So, all you have to do (!) is: >=20 > * grab freebsd-head, because the ixgbe driver there has some recent > bug fixes that you need for this to completely work; > * look at ixgbe_initialise_rss_mapping() - that's where the RSS key, > mapping and RSS hash types are configured; > * patch it to use the example symmetric RSS key that was provided in = the paper; possible that XOR-ing the values to be hashed will produce a similar = result. Of course, this is software, not hardware generation of = Toeplitz. > * patch it to only hash on IPv4 / IPv6 2-tuple, that way you don't end > up with IPv4/IPv6 fragments in the wrong queue; I hope these two aren=E2=80=99t embedded in the code. The coming Intel = devices both support the symmetric RSS key and will correctly hash on ipv4/ipv4 4 tuple. See section 7.1.10.1 and 7.1.10.3 in=20 = http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xl7= 10-10-40-controller-datasheet.pdf > * configure up say, 4 or 8 rings in /boot/loader.conf: >=20 > hw.ix.num_queues=3D8 > (I think it's hw.ix, it used to be hw.ixgbe..) >=20 > * then, when you use netmap on ixgbe, you just bind to each TX and RX > ring with a separate process or thread. That thread will get packets > in both directions for a given flow. >=20 >> If we assume that someone in the future write and submit the above = into the >> ixgbe driver, could I be so bold as to ask you for a >> commandline/configuration example (a brief guide) of how one would = setup >> netmap and how to configure it to use the RX-queues? >=20 > I don't know of any examples of using netmap in this way from the > command line. I've normally written C code (And when I do, i start > with the bridge example in src/tools/tools/netmap/bridge.c) . >=20 >> That way I can start playing around with netmap and learning it while = I wait >> for the ixgbe driver to be updated... I've got two professional = programmer >> colleagues who've dealt extensively with e.g. the libnids and pfring = source >> code, so if I get a grasp of how to setup netmap, and I find it = interesting, >> it is likely that they can dive into and fix the ixgbe driver and = improve it >> as per above. So please, can you help me with a "netmap guide"? >>=20 >> When I try to find documentation or examples of how to setup netmap I = find >> none. Not even the netmap-enabled pcaplib contain any information as = how to >> use it. I'm no programmer, so showing me different C structs for = delivering >> data is of no use. :-/ >=20 > You mean: >=20 > https://code.google.com/p/netmap-libpcap/ >=20 > ? >=20 > I've not used it before, sorry :( >=20 >=20 >=20 > -a > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Sep 22 23:40:41 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94826EA8 for ; Mon, 22 Sep 2014 23:40:41 +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 7C1C2A6A for ; Mon, 22 Sep 2014 23:40:41 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8MNefu0004916 for ; Mon, 22 Sep 2014 23:40:41 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: Mon, 22 Sep 2014 23:40:41 +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: Mon, 22 Sep 2014 23:40:41 -0000 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. From owner-freebsd-net@FreeBSD.ORG Tue Sep 23 00:28: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1691338D for ; Tue, 23 Sep 2014 00:28:04 +0000 (UTC) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::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 A1991E0F for ; Tue, 23 Sep 2014 00:28:03 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id y10so3790089wgg.2 for ; Mon, 22 Sep 2014 17:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=blDz+QPOzIEOKX/v1lUT4CqKmju6wB37nUFX4PY7ZL0=; b=GYYBia97DzG4+5A8fmGORrvmBS+4jqD6zK9VhKado0nOoiIZOQEmtYYIl+8305Ea8Z KAxpD6nh+4XeW4vcS5Y3VLZ71gOVC/Jowy2J337rhAvPhR2tX1bsbYyl4yQgboOOZ7ZF NtdhfzwMuu+DhwefIWDF4Jpgo5+N1mtHDGEXlUeymzGUjJxZo+enj4Avoxz9pURIRajV zXzfjQDD5J1NhOlgYBps6gwMiMAtLnUKdfNEeT2adOdu7FOC69bzYbjsCv/6GQkQuvQv 3poh/bQEnxVCFIY09vX4RdzIrLK2OLYqiJjX2Bp2pMTBnJO1DPdIR/bk9s525U4SqxF+ c9cw== MIME-Version: 1.0 X-Received: by 10.180.97.98 with SMTP id dz2mr17192684wib.26.1411432081925; Mon, 22 Sep 2014 17:28:01 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.199 with HTTP; Mon, 22 Sep 2014 17:28:01 -0700 (PDT) In-Reply-To: <54200A0E-6337-40E1-B5DE-DC42F9CE8CCC@netgate.com> References: <54200A0E-6337-40E1-B5DE-DC42F9CE8CCC@netgate.com> Date: Mon, 22 Sep 2014 17:28:01 -0700 X-Google-Sender-Auth: y9bYq7sjdMZZP-T5-tAyTZlv9qc Message-ID: Subject: Re: How do I balance bandwidth over several virtual NICs? From: Adrian Chadd To: Jim Thompson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , Elof Ofel 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, 23 Sep 2014 00:28:04 -0000 On 22 September 2014 15:35, Jim Thompson wrote: > >> On Sep 22, 2014, at 5:15 PM, Adrian Chadd wrote: >> >> On 22 September 2014 13:39, Elof Ofel wrote: >>> Hi Adrian! >>> >>> Now this sounds promising! All my sensors use the ixgbe driver. >>> However, my skills in programming/compiling isn't vast. I know how to p= atch >>> and use poudriere. That's about it. >>> >>> I must admit I don't really understand what you mean with "patch it to = use a >>> symmetric RSS key", but it sounds like the functionality I'm looking fo= r is >>> not yet there in the driver. >> >> A few years ago a couple of researchers figured out you could abuse >> the toeplitz hash to do symmetric RSS hashing: >> >> http://www.ndsl.kaist.edu/~shinae/papers/TR-symRSS.pdf >> >> This means that the same RSS hash value is chosen no matter which >> direction the traffic is going on. >> This is what you need to ensure that the packets going both directions >> in a connection end up in the same NIC hardware receive ring. >> >> So, all you have to do (!) is: >> >> * grab freebsd-head, because the ixgbe driver there has some recent >> bug fixes that you need for this to completely work; >> * look at ixgbe_initialise_rss_mapping() - that's where the RSS key, >> mapping and RSS hash types are configured; >> * patch it to use the example symmetric RSS key that was provided in the= paper; > > possible that XOR-ing the values to be hashed will produce a similar resu= lt. Of course, this is software, not hardware generation of Toeplitz. > >> * patch it to only hash on IPv4 / IPv6 2-tuple, that way you don't end >> up with IPv4/IPv6 fragments in the wrong queue; > > I hope these two aren=E2=80=99t embedded in the code. The coming Intel d= evices both support the symmetric RSS key and > will correctly hash on ipv4/ipv4 4 tuple. > See section 7.1.10.1 and 7.1.10.3 in > http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xl= 710-10-40-controller-datasheet.pdf I think it'll still do the same thing - it'll not be able to 4-tuple IPv4 frames that are fragmented, as the non-first frame doesn't have the TCP/UDP information. (The support for symmetric RSS by XORing the source/destination bits is very nice - we'll have to teach freebsd's RSS code about that at some point.) -a From owner-freebsd-net@FreeBSD.ORG Tue Sep 23 03:56:29 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1EA8E95; Tue, 23 Sep 2014 03:56:29 +0000 (UTC) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (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 D073237D; Tue, 23 Sep 2014 03:56:28 +0000 (UTC) Received: from Midoris-MacBook-Air.local (p3b93eea5.tokynt01.ap.so-net.ne.jp [59.147.238.165]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 3513F2780BB; Tue, 23 Sep 2014 12:56:17 +0900 (JST) Message-ID: <5420EF61.5040509@sfc.wide.ad.jp> Date: Tue, 23 Sep 2014 12:56:17 +0900 From: Midori Kato 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: Lawrence Stewart Subject: Re: DCTCP implementation References: <5338FF05.1020302@sfc.wide.ad.jp> <540509C1.6090006@freebsd.org> In-Reply-To: <540509C1.6090006@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Eggert, Lars" , hiren panchasara , "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, 23 Sep 2014 03:56:29 -0000 Hi Lawrence, Thank you so much for your response. I discuss KPI changes with Hiren over a month and understood your idea. The main point in your discussion thread was the KPI changes in cc_module. So, I describe about it as follows. As you mention, the changes in my implemtation is DCTCP specific ones. It makes sense not to add these two functions (ect_handler and ecnpkt_handler) into the main stream. At the same time, without these functions, it means that we cannot use DCTCP in FreeBSD. We have to find alternative ways to be putting into them. I think the compatibility with RFC3168 is the thing we should consider. The current KPI has not thought about it. There are two idea to achieve this: - append parameters to handle ECN in struct cc_var - change APIs to process ECN The former idea is easy and elegant. Which idea do you like when we implement DCTCP? And let me know if you have more better idea. I love to work on this to complete the DCTCP implementation. Hiren, if I miss something about our discussion, please provide additional explanation. Many thanks, -- Midori (9/2/14, 9:05 AM), Lawrence Stewart wrote: > Hi Midori (& Lars), > > On 03/31/14 16:37, Midori Kato wrote: >> Hi FreeBSD developpers, >> >> I'm Midori Kato. I'm working on the DCTCP implementation in the FreeBSD >> with Lars Eggert. I mail you because I would like to ask you a code >> review and testing. The attached patch is not good enough to test our >> code. Please give me your message. I will send an ECN marking >> implmenetation in dummynet and test scripts personally to you. > [snip] > > Firstly, please let me apologise for not providing follow up feedback > and review after our initial discussion of your work last year. It was > always my intention to come back to this but life has been particularly > crazy the past 12 months and I have been unsuccessful in my attempts to > keep a number of balls in the air. > > Hiren has been diligently working on shepherding your code into the > FreeBSD source tree and has been prodding me for a review which I > finally got around to yesterday. Unfortunately, my understanding is that > non developers are unable to interact with the code review system being > used, so we're moving the discussion back to the mailing list so that > you and others can participate. You can read the review discussion > history to date at [1]. > > Leaving editorial work on the documentation aside for the time being, > I'd like to discuss the KPI changes and stack integration aspects of the > patch to start with. Specifically: > > - The ect_handler KPI addition seems redundant to me and I believe the > patch can be simplified by removing it entirely. > > - The ecnpkt_handler KPI addition takes arguments which are too specific > to DCTCP, and is too indiscriminate in what it matches i.e. all packets > for ECN enabled connections. I would argue we either add a fully > generalist hook which would catch all packets of an ESTABLISHED > connection, and have the dctcp module check if ECN is enabled or not > before continuing processing (not my preferred option), or we extract > the essence of what dctcp_ecnpkt_handler() needs to do into a less > generic hook or bit of meta data passed in to an existing hook via > struct cc_var (I need to study the code a bit more, but will likely > strongly push for this option). > > - I don't believe the code correctly handles the case of dctcp being > used on connections which did not successfully negotiate ECN. > > There is more to discuss but I think getting these high level technical > things resolved first will help guide the remainder of the review > discussion. > > Cheers, > Lawrence > > [1] https://reviews.freebsd.org/D604 From owner-freebsd-net@FreeBSD.ORG Tue Sep 23 08:38:00 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 58C0813D; Tue, 23 Sep 2014 08:38:00 +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 E4EE61F0; Tue, 23 Sep 2014 08:37:59 +0000 (UTC) Received: from secured.by.ipfw.ru ([95.143.220.47] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XWHcl-000Lk0-UC; Tue, 23 Sep 2014 08:22:48 +0400 Message-ID: <5421310C.5010406@FreeBSD.org> Date: Tue, 23 Sep 2014 12:36:28 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Adrian Chadd , Elof Ofel Subject: Re: How do I balance bandwidth over several virtual NICs? References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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, 23 Sep 2014 08:38:00 -0000 On 22.09.2014 23:46, Adrian Chadd wrote: > Hi, > > Yes. > > * grab an ixgbe NIC and the -HEAD driver; (or cxgbe - I haven't gone > and written RSS programming code for that just yet); > * patch it to use a symmetric RSS key; > * configure up N queues; > * run an instance of snort on each TX/RX ring from the NIC. Oh, wow. I have a low priority task to do that. Nice to see this in stock fbsd! > > The last step requires that you have snort use netmap rather than just > straight bpf - or maybe somehow there's a way to glue bpf into a > single netmap ring. I've wrote snort netmap DAG once, but it does not play well w/o symmetric rss. I've see if I can share it. I > > I haven't wrapped all of this up and thrown it into FreeBSD-HEAD yet, > but i know that a symmetric RSS key works fine on 82599 hardware with > a fixed driver. Greate, thanks! > > > -a > > > On 22 September 2014 12:06, Elof Ofel wrote: >> Hi Nikolay. >> >> Unfortunetly no, that's not a solution. >> mon0 could in theory be a bridge0 with four 10 GE interfaces = 40 Gbps theoretical input that need to be distributed over multiple virtual NICs. Also, I have no control of the mirrored traffic, so it would be hard for me to build and maintain bpf filters that tries to roughly balance the bandwidth load. >> >> Any other suggestions? >> >> /Elof >> >>> Date: Mon, 22 Sep 2014 18:45:28 +0200 >>> Subject: Re: How do I balance bandwidth over several virtual NICs? >>> From: nike_d@cytexbg.com >>> To: elofu17@hotmail.com >>> CC: freebsd-net@freebsd.org >>> >>> On Mon, Sep 22, 2014 at 5:12 PM, Elof Ofel wrote: >>>> I have a single NIC, mon0, that constantly receive 800 Mbps of mirrored traffic. >>>> I want to split these 800 Mbps into smaller chunks and feed them to a couple of virtual interfaces. >>>> Each virtual interface can then have instance of 'snort' inspecting its traffic. >>>> >>>> Say approximately 200 Mbps per interface = four interfaces. >>>> That way, each of the four snort processes only get 200 Mbps of data to inspect instead of having *one* single snort process (single-threaded) trying to cope with 800 Mbps. >>>> >>>> (the problem I'm trying to solve is utilizing all cpu's. Currently one cpu runs snort at 100% while all the other cpu's idle.) >>>> >>>> >>>> The important thing though is that all packets in the connection need to be diverted to the same virtual NIC. You can't send the SYN to NIC0 and the SYN-ACK to NIC1, 'cause then neither snort-process-0 nor snort-process-1 see the other side of the connection. >>>> The loadbalancing must be based on a hash built from at least the mac-addresses+IP-addresses. >>>> >>>> >>>> So, what I think I'm looking for is a way to configure a lagg0 interface in loadbalance mode, that take all the incoming traffic on mon0 and distribute it over four virtual member NICs. (these four NICs would then probably be configured to run in monitor mode.) >>>> >>>> >>>> Do FreeBSD support what I'm looking for? How do I do it? Where should I look? >>>> >>>> /Elof >>>> >>>> _______________________________________________ >>>> 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" >>> >>> Since this is below one Gig, would running separate snort processes on >>> mon0 and using a BPF filter to split traffic work? >>> >>> --Nikolay >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Sep 23 12:05:54 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E393D73 for ; Tue, 23 Sep 2014 12:05:54 +0000 (UTC) Received: from mtaout22.012.net.il (mtaout22.012.net.il [80.179.55.172]) by mx1.freebsd.org (Postfix) with ESMTP id 3E744FBB for ; Tue, 23 Sep 2014 12:05:53 +0000 (UTC) Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NCC00H00S3UUL00@a-mtaout22.012.net.il> for freebsd-net@freebsd.org; Tue, 23 Sep 2014 15:05:51 +0300 (IDT) Received: from mail.ngtech.co.il ([84.95.212.160]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NCC00H2WS9REM90@a-mtaout22.012.net.il> for freebsd-net@freebsd.org; Tue, 23 Sep 2014 15:05:51 +0300 (IDT) Received: from [192.168.10.131] (unknown [192.168.10.254]) by mail.ngtech.co.il (Postfix) with ESMTPA id 2A1CA21099 for ; Tue, 23 Sep 2014 15:05:51 +0300 (IDT) Date: Tue, 23 Sep 2014 15:05:51 +0300 From: Eliezer Croitoru Subject: Re: How do I balance bandwidth over several virtual NICs? In-reply-to: X-012-Sender: eliezer-111@012.net.il To: freebsd-net@freebsd.org Message-id: <5421621F.2070504@ngtech.co.il> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 7bit References: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.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, 23 Sep 2014 12:05:54 -0000 Just wanted to make sure I understand the issue: Snort is not utilizing from some reason the CPU by not threading or by something else with the NIC configuration? From my point of view Snort has to do the changes and not the OS, am I misunderstanding something? Thanks, Eliezer On 09/22/2014 10:46 PM, Adrian Chadd wrote: > Hi, > > Yes. > > * grab an ixgbe NIC and the -HEAD driver; (or cxgbe - I haven't gone > and written RSS programming code for that just yet); > * patch it to use a symmetric RSS key; > * configure up N queues; > * run an instance of snort on each TX/RX ring from the NIC. > > The last step requires that you have snort use netmap rather than just > straight bpf - or maybe somehow there's a way to glue bpf into a > single netmap ring. > > I haven't wrapped all of this up and thrown it into FreeBSD-HEAD yet, > but i know that a symmetric RSS key works fine on 82599 hardware with > a fixed driver. > > > -a From owner-freebsd-net@FreeBSD.ORG Tue Sep 23 14:36:55 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E062A4F; Tue, 23 Sep 2014 14:36:55 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::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 D28DC79F; Tue, 23 Sep 2014 14:36:54 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id q5so5227049wiv.1 for ; Tue, 23 Sep 2014 07:36:52 -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=JlG6g2vzffeUkecOGOl4YNkg6u0eFPK5r7b0tNp+jPM=; b=LQ8wixvfTo36oKaq/NRO6xhY2WnE0DI+Bhtn5UUFZ7qHfVDfryyk3ycvyMMRs5B/vY 14EUNkfACJuF37h5YZ7j2FieREObyYgIK4hu97JNFZHikj2khDz3bdmWVHj5IluKhlVU sRMXxkKjqEQr8HMaUTCSUDoOgJqeRYUoecssWFI/mOQhZFhICR25dPx1P2VHbPFfGDUd kTL/CBQuQ4P0a8+kh60WBT8X01dbSj8r6TZIGfDL+qVqXpkssWvxjY1cG39HGlPGRwmA eq2TWF2h2Uga1wmwde9biW4h4PX6TimbFKjul4jnTTQDoD1XkaH7J9/trL/WqD6Btov4 JS8w== MIME-Version: 1.0 X-Received: by 10.194.108.41 with SMTP id hh9mr81402wjb.68.1411483012765; Tue, 23 Sep 2014 07:36:52 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.199 with HTTP; Tue, 23 Sep 2014 07:36:52 -0700 (PDT) In-Reply-To: <5421310C.5010406@FreeBSD.org> References: <5421310C.5010406@FreeBSD.org> Date: Tue, 23 Sep 2014 07:36:52 -0700 X-Google-Sender-Auth: QjR6qspiKWZfHmcMg-YEVNsrxJE Message-ID: Subject: Re: How do I balance bandwidth over several virtual NICs? From: Adrian Chadd To: "Alexander V. Chernikov" Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" , Elof Ofel 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, 23 Sep 2014 14:36:55 -0000 On 23 September 2014 01:36, Alexander V. Chernikov wrote: > On 22.09.2014 23:46, Adrian Chadd wrote: >> Hi, >> >> Yes. >> >> * grab an ixgbe NIC and the -HEAD driver; (or cxgbe - I haven't gone >> and written RSS programming code for that just yet); >> * patch it to use a symmetric RSS key; >> * configure up N queues; >> * run an instance of snort on each TX/RX ring from the NIC. > Oh, wow. > I have a low priority task to do that. > Nice to see this in stock fbsd! > >> >> The last step requires that you have snort use netmap rather than just >> straight bpf - or maybe somehow there's a way to glue bpf into a >> single netmap ring. > I've wrote snort netmap DAG once, but it does not play well w/o > symmetric rss. > I've see if I can share it. That'd be great! I'll see if I can get -HEAD enabled with an optional symmetric RSS key. It shouldn't be too difficult. The problem is the current RSS setup uses the same key for all NICs. I _guess_ that isn't going to /really/ be a problem here - unless you really want your server to serve lots of traffic /and/ snort :) Then we just need a netmap enabled snort :) -a From owner-freebsd-net@FreeBSD.ORG Tue Sep 23 14:44: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E20CACFD; Tue, 23 Sep 2014 14:44:04 +0000 (UTC) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::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 03B47884; Tue, 23 Sep 2014 14:44:03 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id l4so8900782lbv.30 for ; Tue, 23 Sep 2014 07:44:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=c17EUo80i72EIjCKwvFlE//DFm00j3kox50Leshj3Go=; b=WnRIGLOvKlzboxqTUjPgsio9/JWZiPscwiSkFrk2Es+RIBOOMweJ5A7sBC7kz+FXTi yhb9ws+uocJy5W3JAecM11MgRHhrQa+qxKvqaG/KczWutteg9uUHEQICXeThnx+PY36F FQX7fPfbxcFlq9Js3k+oFvTJ0FkEWMjYeL6LZODlyNj457s84jQ9mM+ALEDBTu3M26Bs 63oxs5UkKJvz5n98SUQUMpwwB9ElgV+XILVB5FgxuSuGbvFr+b1CoxTaKkcFCvhdDNOP OclwA5EXSvAa407FNneRvl+vtmLGIyRc90VSBfbEl0UnQaOsW7P3L6yP/UySZPCNs5mn rWyg== MIME-Version: 1.0 X-Received: by 10.152.28.74 with SMTP id z10mr188425lag.10.1411483441980; Tue, 23 Sep 2014 07:44:01 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.26.37 with HTTP; Tue, 23 Sep 2014 07:44:01 -0700 (PDT) In-Reply-To: References: <5421310C.5010406@FreeBSD.org> Date: Tue, 23 Sep 2014 16:44:01 +0200 X-Google-Sender-Auth: nwaul6Jc1RMmXIPrejjve9xaQ9g Message-ID: Subject: Re: How do I balance bandwidth over several virtual NICs? From: Luigi Rizzo To: Adrian Chadd 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" , 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: Tue, 23 Sep 2014 14:44:05 -0000 On Tue, Sep 23, 2014 at 4:36 PM, Adrian Chadd wrote: > On 23 September 2014 01:36, Alexander V. Chernikov > wrote: > > On 22.09.2014 23:46, Adrian Chadd wrote: > >> Hi, > >> > >> Yes. > >> > >> * grab an ixgbe NIC and the -HEAD driver; (or cxgbe - I haven't gone > >> and written RSS programming code for that just yet); > >> * patch it to use a symmetric RSS key; > >> * configure up N queues; > >> * run an instance of snort on each TX/RX ring from the NIC. > > Oh, wow. > > I have a low priority task to do that. > > Nice to see this in stock fbsd! > > > >> > >> The last step requires that you have snort use netmap rather than just > >> straight bpf - or maybe somehow there's a way to glue bpf into a > >> single netmap ring. > > I've wrote snort netmap DAG once, but it does not play well w/o > > symmetric rss. > > I've see if I can share it. > > That'd be great! > > I'll see if I can get -HEAD enabled with an optional symmetric RSS key. > > It shouldn't be too difficult. The problem is the current RSS setup > uses the same key for all NICs. > I _guess_ that isn't going to /really/ be a problem here - unless you > really want your server to serve lots of traffic /and/ snort :) > > Then we just need a netmap enabled snort :) > =E2=80=8Bfrom my (not first-hand) knowledge with IDSes, i =E2=80=8Bbelieve=E2=80=8B that the bottleneck is =E2=80=8B =E2=80=8B mostly the processing done in the IDS, rather than =E2=80=8B =E2=80=8B the network I/O (provided it is =E2=80=8Breasonably fast ). As a result, just running IDS instances on top of a netmap-enabled libpcap (i.e. no source code modifications) should do the job. I know the Bro developers (in Bcc so they can pitch in if they like) have been playing with some external traffic demultiplexer that reads from the NIC (in netmap mode) and passes traffic to IDS instances using VALE ports or netmap pipes, all of which are compatible with the netmap-libpcap. In other words, even if the hardware cannot do rss in a useful way, you should be able to do the =E2=80=8Bdemux in software. Of course, if you can put the hardware at work, you should go for that. cheers luigi=E2=80=8B =E2=80=8B From owner-freebsd-net@FreeBSD.ORG Tue Sep 23 15:11: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82763A9B for ; Tue, 23 Sep 2014 15:11:25 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B380BCC for ; Tue, 23 Sep 2014 15:11:25 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-253-99.lns20.per2.internode.on.net [121.45.253.99]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s8NFBLeG036576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 23 Sep 2014 08:11:23 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <54218D93.9030002@freebsd.org> Date: Tue, 23 Sep 2014 23:11:15 +0800 From: Julian Elischer 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: How do I balance bandwidth over several virtual NICs? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.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, 23 Sep 2014 15:11:25 -0000 On 9/22/14, 11:12 PM, Elof Ofel wrote: > I have a single NIC, mon0, that constantly receive 800 Mbps of mirrored traffic. > I want to split these 800 Mbps into smaller chunks and feed them to a couple of virtual interfaces. > Each virtual interface can then have instance of 'snort' inspecting its traffic. > > Say approximately 200 Mbps per interface = four interfaces. > That way, each of the four snort processes only get 200 Mbps of data to inspect instead of having *one* single snort process (single-threaded) trying to cope with 800 Mbps. > > (the problem I'm trying to solve is utilizing all cpu's. Currently one cpu runs snort at 100% while all the other cpu's idle.) > > > The important thing though is that all packets in the connection need to be diverted to the same virtual NIC. You can't send the SYN to NIC0 and the SYN-ACK to NIC1, 'cause then neither snort-process-0 nor snort-process-1 see the other side of the connection. > The loadbalancing must be based on a hash built from at least the mac-addresses+IP-addresses. you can probably do this with ipfw and/or netgraph in about half a dozen different ways. Firstly, are the packets COPIES, or are these packets "Live".? (do we have to get the packets back?) I'm going to assume they are not copies and htat we need ot copy them. Secondly, do you want to run in inline mode so that snort can drop packets? I'm going to assume no.. Here is one possibility: firstly do a "check-state" in ipfw. This will effectively jump to another rule if the session has been seen before. (see below) If the state fails, "skipto" based on a table, to send packets to one of N packet rules depending on some set of bits in the address(es). On each set of rules we forward the packet to a different snort, with a 'keep-state' rule. This assures that all following packets will do the same thing (It's a little known fact that 'check state' is actually very close to a conditional skipto.. it effectively jumps to the rule that first matched that session.) the set of rules can achieve the forwarding in a number of ways, but I suggest using the 'ngtee' rule to send a copy of the packet to netgraph. the netgraph node in question can send it to a virtual interface, from which snort is listenning using bpf. At one stage there was a snort action to allow it to listen directly to divert packets, so you could use just a 'tee' rule. However I THINK that may only work in inline mode.. but you may check. You could also use the 'forward' rule to send different sessions to differnet virtual interfaces. from where you could look at them but you'd have to somehow gather them all together again after that (a bridge?). > > > So, what I think I'm looking for is a way to configure a lagg0 interface in loadbalance mode, that take all the incoming traffic on mon0 and distribute it over four virtual member NICs. (these four NICs would then probably be configured to run in monitor mode.) > > > Do FreeBSD support what I'm looking for? How do I do it? Where should I look? > > /Elof > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Sep 23 15:18: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB656F0B; Tue, 23 Sep 2014 15:18:07 +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 3E7C1C4D; Tue, 23 Sep 2014 15:18:07 +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 1XWNrx-0000Je-Ue; Tue, 23 Sep 2014 15:02:54 +0400 Message-ID: <54218EF4.6090102@FreeBSD.org> Date: Tue, 23 Sep 2014 19:17:08 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Luigi Rizzo , Adrian Chadd Subject: Re: How do I balance bandwidth over several virtual NICs? References: <5421310C.5010406@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Elof Ofel 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, 23 Sep 2014 15:18:07 -0000 On 23.09.2014 18:44, Luigi Rizzo wrote: > > > On Tue, Sep 23, 2014 at 4:36 PM, Adrian Chadd > wrote: > > On 23 September 2014 01:36, Alexander V. Chernikov > > wrote: > > On 22.09.2014 23:46, Adrian Chadd wrote: > >> Hi, > >> > >> Yes. > >> > >> * grab an ixgbe NIC and the -HEAD driver; (or cxgbe - I haven't > gone > >> and written RSS programming code for that just yet); > >> * patch it to use a symmetric RSS key; > >> * configure up N queues; > >> * run an instance of snort on each TX/RX ring from the NIC. > > Oh, wow. > > I have a low priority task to do that. > > Nice to see this in stock fbsd! > > > >> > >> The last step requires that you have snort use netmap rather > than just > >> straight bpf - or maybe somehow there's a way to glue bpf into a > >> single netmap ring. > > I've wrote snort netmap DAG once, but it does not play well w/o > > symmetric rss. > > I've see if I can share it. > > That'd be great! > > I'll see if I can get -HEAD enabled with an optional symmetric RSS > key. > > It shouldn't be too difficult. The problem is the current RSS setup > uses the same key for all NICs. > I _guess_ that isn't going to /really/ be a problem here - unless you > really want your server to serve lots of traffic /and/ snort :) > > Then we just need a netmap enabled snort :) > > > ​from my (not first-hand) knowledge with IDSes, > i > ​believe​ > that the bottleneck is > ​ ​ > mostly the processing > done in the IDS, rather than > ​ ​ > the network I/O (provided > it is > ​reasonably fast > ). True. > > As a result, just running IDS instances on top > of a netmap-enabled libpcap (i.e. no source code > modifications) should do the job. The problem with snort is that is single-threaded, so you have to (somehow) split traffic (preserving sessions) and run multiple snort instances on each. Linux guys do that with pf_ring. I've created snort netmap DAG to be able to open each NIC queue with different snort process. However, in addition to non-symmetric RSS (which is hopefully being addressed), there is another usual "producer - multuple consumers" problem: one snort process can start process packets very slowly, or hang, or crash. In that case host RX ring is getting full, NIC fails to push packets to given queue and start storing them inside its skid buffer (512k for Niantic afair). After that buffer becomes full traffic and all processing stops. > > I know the Bro developers (in Bcc so they can pitch > in if they like) have been playing with some > external traffic demultiplexer that reads from the > NIC (in netmap mode) and passes traffic to IDS > instances using VALE ports or netmap pipes, > all of which are compatible with the netmap-libpcap. > > In other words, even if the hardware cannot do rss > in a useful way, you should be able to do the > ​demux in software. > > Of course, if you can put the hardware at work, > you should go for that. > > cheers > luigi​ > > ​ From owner-freebsd-net@FreeBSD.ORG Tue Sep 23 15:32:40 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4738E837 for ; Tue, 23 Sep 2014 15:32:40 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 10067E42 for ; Tue, 23 Sep 2014 15:32:39 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-253-99.lns20.per2.internode.on.net [121.45.253.99]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s8NFWZLg036756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 23 Sep 2014 08:32:38 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5421928D.5090909@freebsd.org> Date: Tue, 23 Sep 2014 23:32:29 +0800 From: Julian Elischer 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: How do I balance bandwidth over several virtual NICs? References: <54218D93.9030002@freebsd.org> In-Reply-To: <54218D93.9030002@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 23 Sep 2014 15:32:40 -0000 On 9/23/14, 11:11 PM, Julian Elischer wrote: > On 9/22/14, 11:12 PM, Elof Ofel wrote: >> I have a single NIC, mon0, that constantly receive 800 Mbps of >> mirrored traffic. >> I want to split these 800 Mbps into smaller chunks and feed them to >> a couple of virtual interfaces. >> Each virtual interface can then have instance of 'snort' inspecting >> its traffic. >> >> Say approximately 200 Mbps per interface = four interfaces. >> That way, each of the four snort processes only get 200 Mbps of >> data to inspect instead of having *one* single snort process >> (single-threaded) trying to cope with 800 Mbps. >> >> (the problem I'm trying to solve is utilizing all cpu's. Currently >> one cpu runs snort at 100% while all the other cpu's idle.) >> >> >> The important thing though is that all packets in the connection >> need to be diverted to the same virtual NIC. You can't send the SYN >> to NIC0 and the SYN-ACK to NIC1, 'cause then neither >> snort-process-0 nor snort-process-1 see the other side of the >> connection. >> The loadbalancing must be based on a hash built from at least the >> mac-addresses+IP-addresses. > you can probably do this with ipfw and/or netgraph in about half a > dozen different ways. > > Firstly, are the packets COPIES, or are these packets "Live".? (do > we have to get the packets back?) > I'm going to assume they are not copies and htat we need ot copy them. oh wait you said it was mirrored traffic! (looks for glasses). ok so a divert rule would be sufficient if you can get snort to listen to diverted packets . From memory its' something like: --daq --daq-var port={some divert port number} > > Secondly, do you want to run in inline mode so that snort can drop > packets? > I'm going to assume no.. > > Here is one possibility: > firstly do a "check-state" in ipfw. This will effectively jump to > another rule if the session has been seen before. (see below) > If the state fails, "skipto" based on a table, to send packets to > one of N packet rules depending on some set of bits in the address(es). > On each set of rules we forward the packet to a different snort, > with a 'keep-state' rule. This assures that all following packets > will do the same thing (It's a little known fact that 'check state' > is actually very close to a conditional skipto.. it effectively > jumps to the rule that first matched that session.) > > > the set of rules can achieve the forwarding in a number of ways, but > I suggest using the 'ngtee' rule to send a copy of the packet to > netgraph. the netgraph node in question can send it to a virtual > interface, from which snort is listenning using bpf. since this is mirrored traffic, just use the "netgraph" rule not ngtee. I'm not exactly sure what kind of virtual interface to hook it to.. I guess a regular ng_iface node would be good.. you really don't want the packets to enter the ip stack, so you need to make sure it is in 'monitor' mode. > > At one stage there was a snort action to allow it to listen directly > to divert packets, so you could use just a 'tee' rule. However I > THINK that may only work in inline mode.. but you may check. > > You could also use the 'forward' rule to send different sessions to > differnet virtual interfaces. from where you could look at them but > you'd have to somehow gather them all together again after that (a > bridge?). > > >> >> >> So, what I think I'm looking for is a way to configure a lagg0 >> interface in loadbalance mode, that take all the incoming traffic >> on mon0 and distribute it over four virtual member NICs. (these >> four NICs would then probably be configured to run in monitor mode.) >> >> >> Do FreeBSD support what I'm looking for? How do I do it? Where >> should I look? >> >> /Elof >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Tue Sep 23 15:41:19 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5822CB32; Tue, 23 Sep 2014 15:41: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 F35B2F2F; Tue, 23 Sep 2014 15:41:18 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id B90927300A; Tue, 23 Sep 2014 17:46:10 +0200 (CEST) Date: Tue, 23 Sep 2014 17:46:10 +0200 From: Luigi Rizzo To: "Alexander V. Chernikov" Subject: Re: How do I balance bandwidth over several virtual NICs? Message-ID: <20140923154610.GD84074@onelab2.iet.unipi.it> References: <5421310C.5010406@FreeBSD.org> <54218EF4.6090102@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54218EF4.6090102@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "freebsd-net@freebsd.org" , Adrian Chadd , Elof Ofel 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, 23 Sep 2014 15:41:19 -0000 On Tue, Sep 23, 2014 at 07:17:08PM +0400, Alexander V. Chernikov wrote: > On 23.09.2014 18:44, Luigi Rizzo wrote: ... > However, in addition to non-symmetric RSS (which is hopefully being > addressed), there is another > usual "producer - multuple consumers" problem: one snort process can > start process packets very slowly, or hang, or crash. > In that case host RX ring is getting full, NIC fails to push packets to > given queue and start storing them inside > its skid buffer (512k for Niantic afair). After that buffer becomes full > traffic and all processing stops. interesting. Actually, scary! Do you have any reference to the data sheets documenting that behaviour ? I have indeed received reports saying something similar but always suspected user errors. The fact that a starved queue can consume the entire internal buffer seems a really bad bug. At least you can overcome this one by having the demux done in software. cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Sep 23 15:47:21 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0895FF6 for ; Tue, 23 Sep 2014 15:47:21 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 908C4F94 for ; Tue, 23 Sep 2014 15:47:21 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-253-99.lns20.per2.internode.on.net [121.45.253.99]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s8NFlFbY036821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 23 Sep 2014 08:47:19 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <542195FE.5050800@freebsd.org> Date: Tue, 23 Sep 2014 23:47:10 +0800 From: Julian Elischer 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: Eliezer Croitoru , freebsd-net@freebsd.org Subject: Re: How do I balance bandwidth over several virtual NICs? References: <5421621F.2070504@ngtech.co.il> In-Reply-To: <5421621F.2070504@ngtech.co.il> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.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, 23 Sep 2014 15:47:21 -0000 On 9/23/14, 8:05 PM, Eliezer Croitoru wrote: > Just wanted to make sure I understand the issue: > Snort is not utilizing from some reason the CPU by not threading or > by something else with the NIC configuration? > From my point of view Snort has to do the changes and not the OS, am > I misunderstanding something? No, but asking them to change acording to one's internal project schedule is not realistic.. so in the interest of time one has to live with (and work around) the problem. > > Thanks, > Eliezer > > On 09/22/2014 10:46 PM, Adrian Chadd wrote: >> Hi, >> >> Yes. >> >> * grab an ixgbe NIC and the -HEAD driver; (or cxgbe - I haven't gone >> and written RSS programming code for that just yet); >> * patch it to use a symmetric RSS key; >> * configure up N queues; >> * run an instance of snort on each TX/RX ring from the NIC. >> >> The last step requires that you have snort use netmap rather than just >> straight bpf - or maybe somehow there's a way to glue bpf into a >> single netmap ring. >> >> I haven't wrapped all of this up and thrown it into FreeBSD-HEAD yet, >> but i know that a symmetric RSS key works fine on 82599 hardware with >> a fixed driver. >> >> >> -a > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Sep 23 16:00: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADFC25C8; Tue, 23 Sep 2014 16:00:46 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::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 1EF39149; Tue, 23 Sep 2014 16:00:45 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id q5so5411288wiv.13 for ; Tue, 23 Sep 2014 09:00:44 -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=UAresm+NFRCVr2yzqhS/IxOGcUZXz+LjAwXe3CmVy2Q=; b=VYbZ83OsvjZqkfUqj38nSSf3cMwui4itw7s1ZbHByX6ifd/8/CrQ/TjoiTAqRsvUiF DfOkYINKOvz1sLWDyclBo5jKfjmQj9fmPFRb4dYxrCzuEJZ4HIgpos+a6VeJpRTYWcA/ Alt5Yr+Sf3iODay9FEq+/w99yZzDDzHPqBTCFr81LsbV9v3pqRKiLuJJTbQDEJRWfc4g SFYwzVwnY+w/CDWvA0EN6SQ8s2KTL4TfwHpMoJWlbns4sHe1Egs//5wRWQTcXC7rLaXt MQYcKiMNcGHmLWuF0A9xFSbEXzi1bZWX7MAZQUVshGVq+eucmw+Bu/HsxsLcT5JfurIv ygMw== MIME-Version: 1.0 X-Received: by 10.180.101.129 with SMTP id fg1mr23828477wib.20.1411488044435; Tue, 23 Sep 2014 09:00:44 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.199 with HTTP; Tue, 23 Sep 2014 09:00:44 -0700 (PDT) In-Reply-To: <20140923154610.GD84074@onelab2.iet.unipi.it> References: <5421310C.5010406@FreeBSD.org> <54218EF4.6090102@FreeBSD.org> <20140923154610.GD84074@onelab2.iet.unipi.it> Date: Tue, 23 Sep 2014 09:00:44 -0700 X-Google-Sender-Auth: FDhHZMDkr3mv29Kj_2GOQzTpvBk Message-ID: Subject: 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: Tue, 23 Sep 2014 16:00:46 -0000 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 From owner-freebsd-net@FreeBSD.ORG Tue Sep 23 16:36:04 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B606F58; Tue, 23 Sep 2014 16:36: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 083C8800; Tue, 23 Sep 2014 16:36: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 1XWP5O-0001FO-DI; Tue, 23 Sep 2014 16:20:50 +0400 Message-ID: <5421A138.90803@FreeBSD.org> Date: Tue, 23 Sep 2014 20:35:04 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: How do I balance bandwidth over several virtual NICs? References: <5421310C.5010406@FreeBSD.org> <54218EF4.6090102@FreeBSD.org> <20140923154610.GD84074@onelab2.iet.unipi.it> In-Reply-To: <20140923154610.GD84074@onelab2.iet.unipi.it> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "freebsd-net@freebsd.org" , Adrian Chadd , Elof Ofel 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, 23 Sep 2014 16:36:04 -0000 On 23.09.2014 19:46, Luigi Rizzo wrote: > On Tue, Sep 23, 2014 at 07:17:08PM +0400, Alexander V. Chernikov wrote: >> On 23.09.2014 18:44, Luigi Rizzo wrote: > ... >> However, in addition to non-symmetric RSS (which is hopefully being >> addressed), there is another >> usual "producer - multuple consumers" problem: one snort process can >> start process packets very slowly, or hang, or crash. >> In that case host RX ring is getting full, NIC fails to push packets to >> given queue and start storing them inside >> its skid buffer (512k for Niantic afair). After that buffer becomes full >> traffic and all processing stops. > interesting. Actually, scary! > Do you have any reference to the data sheets documenting > that behaviour ? I have indeed received reports saying something Quoting latest 82599 datasheet: Flow control: 3.7.7.3.4 Packet Buffer Size .. Suggested buffer size (FC on): 512K Suggested buffer size (FC off, jumbo): 40Kb 7.1 Receive Functionality Packet reception consists of: Recognizing the presence of a packet on the wire Performing address filtering DMA queue assignment Storing the packet in the receive data FIFO ----------------------------------- ^^^^^^^^^^^ Transferring the data to assigned receive queues in host memory Updating the state of a receive descriptor. 7.1.9.1 Low Receive Descriptors Threshold The number of usable (free) descriptors for the hardware is the distance between the Tail and Head registers. When the tail reaches the head, there are no free descriptors and further packets might be either dropped or block the receive FIFO. In order to avoid this situation, the 82599 might generate a low latency interrupt (associated to the relevant > similar but always suspected user errors. > The fact that a starved queue can consume the entire internal > buffer seems a really bad bug. > > At least you can overcome this one by having the demux done > in software. Well, yes. Despite the fact that 82599 can handle huge (65k) RX queues, this does not help much unless there is some knob to prevent HOL. > > cheers > luigi > From owner-freebsd-net@FreeBSD.ORG Tue Sep 23 16:38:03 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2CEA175; Tue, 23 Sep 2014 16:38:02 +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 AF5A8828; Tue, 23 Sep 2014 16:38:02 +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 1XWP7J-0001Hb-MN; Tue, 23 Sep 2014 16:22:49 +0400 Message-ID: <5421A1AF.9000800@FreeBSD.org> Date: Tue, 23 Sep 2014 20:37:03 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Adrian Chadd , Luigi Rizzo Subject: Re: How do I balance bandwidth over several virtual NICs? References: <5421310C.5010406@FreeBSD.org> <54218EF4.6090102@FreeBSD.org> <20140923154610.GD84074@onelab2.iet.unipi.it> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , Elof Ofel 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, 23 Sep 2014 16:38:03 -0000 On 23.09.2014 20:00, 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. Oh, cool. Yet another reason to turn flow control off by default. > > > > -a > From owner-freebsd-net@FreeBSD.ORG Tue Sep 23 16:40:19 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24EA92FE; Tue, 23 Sep 2014 16:40:19 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::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 3F560840; Tue, 23 Sep 2014 16:40:18 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id b12so9145263lbj.28 for ; Tue, 23 Sep 2014 09:40: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=r4IPfzud9ZLJDAIULtKCL1CwRDpg7KKaL6ksDlUoi4o=; b=SfzUID6rZjBaUnp+LdaQai/2HhsKd8IMxUQdnqwudcgviYMcH3EGfDUL3sJLpS8AqH ydL+8xuFDNoq5kwv8YIyveoQ+3cdQLjBJ5keMTWlMPiPIauKehm6MM3hRqmDm8jT7tZY ELVwCJhF7rpj/abYe3MoZxnZddnmjYRzhPnIlB2rl43QcanU5AjtAPOYquf87aDqylka Hy3VwJiuupIY2bebkMKMR9KEXLOjWkKspY64c7k9nLey7J16mAfcowXkUz3ugWTTVNnb W6IADASPzwCuQHFwoNZ+m6HfV5D+bTb5lrXjdcIUy2lVEd9AtpCsX9NxCBzWEDRY7DkJ v+1A== MIME-Version: 1.0 X-Received: by 10.112.54.169 with SMTP id k9mr861429lbp.32.1411490416138; Tue, 23 Sep 2014 09:40:16 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.26.37 with HTTP; Tue, 23 Sep 2014 09:40:15 -0700 (PDT) In-Reply-To: <5421A1AF.9000800@FreeBSD.org> References: <5421310C.5010406@FreeBSD.org> <54218EF4.6090102@FreeBSD.org> <20140923154610.GD84074@onelab2.iet.unipi.it> <5421A1AF.9000800@FreeBSD.org> Date: Tue, 23 Sep 2014 18:40:15 +0200 X-Google-Sender-Auth: mFnY25ft-GNP5T1GPrzQqa-Klug Message-ID: Subject: Re: How do I balance bandwidth over several virtual NICs? From: Luigi Rizzo To: "Alexander V. Chernikov" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Adrian Chadd , Elof Ofel 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, 23 Sep 2014 16:40:19 -0000 On Tuesday, September 23, 2014, Alexander V. Chernikov wrote: > On 23.09.2014 20:00, 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. >> > Oh, cool. > Yet another reason to turn flow control off by default. Or at least decouple the two features. Cheers Luigi > >> >> >> -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 Tue Sep 23 17:14:25 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4396CB74; Tue, 23 Sep 2014 17:14:25 +0000 (UTC) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (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 E19AFBDB; Tue, 23 Sep 2014 17:14:24 +0000 (UTC) Received: from [IPv6:::1] (scone.ICSI.Berkeley.EDU [192.150.186.121]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id s8NGY3ot009038; Tue, 23 Sep 2014 09:34:04 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: How do I balance bandwidth over several virtual NICs? From: Seth Hall In-Reply-To: Date: Tue, 23 Sep 2014 12:34:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5421310C.5010406@FreeBSD.org> 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: Tue, 23 Sep 2014 17:14:25 -0000 On Sep 23, 2014, at 10:44 AM, Luigi Rizzo wrote: > I know the Bro developers (in Bcc so they can pitch > in if they like) have been playing with some > external traffic demultiplexer that reads from the > NIC (in netmap mode) and passes traffic to IDS > instances using VALE ports or netmap pipes, > all of which are compatible with the netmap-libpcap. We're trying to solve a lot of problems that people have with low level = packet handling for network monitoring. Not sure how much I have to say = about it quite yet, but the tool is called PacketBricks and can be found = here:=20 https://github.com/bro/packet-bricks One request we've been proxying through Luigi, but I'd like to push it = with more people is to get netmap compiled into the GENERIC FreeBSD = kernel. In my opinion it would be nice for FreeBSD to reclaim the = position of the best OS for network monitoring and I think that netmap = compiled into the default install would be fantastic. .Seth -- Seth Hall International Computer Science Institute (Bro) because everyone has a network http://www.bro.org/ From owner-freebsd-net@FreeBSD.ORG Tue Sep 23 23:18:53 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2DB24B1 for ; Tue, 23 Sep 2014 23:18:53 +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 805039B9 for ; Tue, 23 Sep 2014 23:18:53 +0000 (UTC) Received: by mail-la0-f43.google.com with SMTP id gb8so96175lab.30 for ; Tue, 23 Sep 2014 16:18:51 -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=VwaKFYsWfPziBS5h/DHgqhTITr13GZuDZkNWUIGlBKQ=; b=ohhYAH1NLgTxAFv50rN4f62sAGFhRqi8tSBw9YN7KLMau5t5Qx4fGB0TMIuUBNUuUb DgbOePlH9vIYehpDZLZTs9xf6sfaZqeYBIGJ6BnVYgpp+cWtWTJJt2a0KVE+xYKbmWuF FDYJLLWYO0V8pUbSWSWw8rv4BopO5ptJRVczx/Gc+0Fes4sweTBVDLFza7o9e4YBUyqK pxIR/Gwp5zxx3uVbxYEAqqrsBdjcyMcgcaNCIMZ6DCGXQU+1yJizrvlPlSFV7/FBrMG5 9tBSUKUYmyOfEScQE0q5vLuCYZ2C8aZWYFZmhWqL4tzGLoNrhkIX5duNKC35q1BQeSvx 5tyw== MIME-Version: 1.0 X-Received: by 10.112.172.38 with SMTP id az6mr2365088lbc.53.1411514331318; Tue, 23 Sep 2014 16:18:51 -0700 (PDT) Received: by 10.25.21.166 with HTTP; Tue, 23 Sep 2014 16:18:51 -0700 (PDT) Date: Tue, 23 Sep 2014 19:18:51 -0400 Message-ID: Subject: [PATCH] Convert ixl(4) and ixlv(4) to ifcounters, and fix some counter bugs From: Ryan Stone To: freebsd-net 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: Tue, 23 Sep 2014 23:18:54 -0000 The patch below converts the ixl(4) and ixlv(4) drivers to use the new ifcounter interface. I've hidden the interface behind some macros to ensure that the driver continues to compile for FreeBSD 10 and earlier. The result of the macros is that the ifcounter implementation is somewhat clunkier than I would have liked, but I preferred to try and share as much code between the legacy counter implementation and the ifcounter implementation. I have tested the ixl driver with head. I have only compile-tested it for stable/10. This patch also fixes some counter bugs: - Ensure that tx discards are reported - There are actually two types of rx discard counters in the hardware. Currently the driver is only reporting discards from one of the two counters, so I fixed that - The ipackets and opackets counters were being unnecessarily incremented in the rx and tx paths. This was racy, unnecessary (the counters also get explicitly set based on the values in HW counters) and very bad for performance -- the cacheline contained the counters was constantly bouncing between CPUs. I saw this even with only one queue active, probably due to false sharing with some other field in the ifnet struct. https://people.freebsd.org/~rstone/patches/ixl/0005-Convert-ixl-and-ixlv-drivers-to-use-new-ifcounter-in.patch From owner-freebsd-net@FreeBSD.ORG Tue Sep 23 23:50:11 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D883D9AA for ; Tue, 23 Sep 2014 23:50: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 B7733C32 for ; Tue, 23 Sep 2014 23:50: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 s8NNoBo1057981 for ; Tue, 23 Sep 2014 23:50:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 183920] [ixgbe] [patch] Incorrect ifconfig media on INTEL X520-T2 10G Dual-port Ethernet Server Adapter, RJ45/2 Date: Tue, 23 Sep 2014 23:50: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: 9.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ricera10@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 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, 23 Sep 2014 23:50:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183920 Eric Joyner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ricera10@gmail.com --- Comment #2 from Eric Joyner --- Wow, this has been here for a while. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Sep 24 19:11:48 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D23F654B for ; Wed, 24 Sep 2014 19:11:48 +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 ACA50CF4 for ; Wed, 24 Sep 2014 19:11:48 +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 8DCB6B941 for ; Wed, 24 Sep 2014 15:11:47 -0400 (EDT) From: John Baldwin To: net@freebsd.org Subject: [PATCH] Convert netipsec/key from timeout(9) to callout(9) Date: Wed, 24 Sep 2014 15:02:59 -0400 Message-ID: <1960797.oookSHr2PM@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) 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); Wed, 24 Sep 2014 15:11:47 -0400 (EDT) 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, 24 Sep 2014 19:11:48 -0000 This patch converts a timer in the IPSEC code from using timeout() to using callout() instead. Can someone test it or review it? http://people.freebsd.org/~jhb/patches/ipsec_callout.patch -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Sep 25 09:47:34 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 644EFADB; Thu, 25 Sep 2014 09:47:34 +0000 (UTC) Received: from nijmegen.renzel.net (mx1.renzel.net [195.243.213.130]) by mx1.freebsd.org (Postfix) with ESMTP id 27238FD6; Thu, 25 Sep 2014 09:47:33 +0000 (UTC) Received: from dublin.vkf.isb.de.renzel.net (unknown [10.0.0.80]) by nijmegen.renzel.net (smtpd) with ESMTP id 76EA61414951; Thu, 25 Sep 2014 11:44:13 +0200 (CEST) Received: from asbach.renzel.net (unknown [10.2.0.7]) by dublin.vkf.isb.de.renzel.net (Postfix) with ESMTP id 3C3EB98FA7; Thu, 25 Sep 2014 11:44:25 +0200 (CEST) Content-Type: text/plain; charset="ISO-8859-1" From: Nils Beyer Organization: VKF Renzel GmbH Date: Thu, 25 Sep 2014 11:44:24 +0200 User-Agent: KNode/4.12.5 Content-Transfer-Encoding: 7Bit Subject: Re: Success with Qualcomm Atheros QCA8171 To: freebsd-drivers@freebsd.org, freebsd-net@freebsd.org References: <3320661411119387@web21h.yandex.ru> Lines: 52 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: Thu, 25 Sep 2014 09:47:34 -0000 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. But for small data transfers (SSH, RSYNC, RDP) it's okay. Mark has done a good job so far: =============================================================================== #dmesg | grep alx alx0: port 0x2000-0x207f mem 0xd0400000-0xd043ffff irq 16 at device 0.0 on pci2 alx0: Ethernet address: 5c:f9:dd:55:c9:fb #ifconfig alx0 alx0: flags=8843 metric 0 mtu 1500 ether 5c:f9:dd:55:c9:fb inet6 fe80::5ef9:ddff:fe55:c9fb%alx0 prefixlen 64 scopeid 0x2 nd6 options=29 media: Ethernet autoselect status: no carrier #pciconf -evl | tail -13 alx0@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 PCI-e errors = Correctable Error Detected Non-Fatal Error Detected Unsupported Request Detected Non-fatal = Unsupported Request Corrected = Bad TLP Bad DLLP REPLAY_NUM Rollover Replay Timer Timeout =============================================================================== ... Regards, Nils From owner-freebsd-net@FreeBSD.ORG Thu Sep 25 11:07:13 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9DBF3F93; Thu, 25 Sep 2014 11:07:13 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 5F3C3AD7; Thu, 25 Sep 2014 11:07:13 +0000 (UTC) Received: from [172.22.0.99] (unknown [213.222.32.13]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 75B811928C4; Thu, 25 Sep 2014 11:07:08 +0000 (UTC) Subject: Re: svn commit: r272089 - head/sys/netpfil/ipfw From: Sean Bruno Reply-To: sbruno@freebsd.org To: Gleb Smirnoff In-Reply-To: <20140925051808.GS884@FreeBSD.org> References: <201409250226.s8P2Q6AS055635@svn.freebsd.org> <20140925051808.GS884@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Sep 2014 04:07:03 -0700 Message-ID: <1411643223.2161.2.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Adrian Chadd , David Carlier 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, 25 Sep 2014 11:07:13 -0000 On Thu, 2014-09-25 at 09:18 +0400, Gleb Smirnoff wrote: > On Wed, Sep 24, 2014 at 07:40:23PM -0700, Adrian Chadd wrote: > A> Hm, I saw this from Kate on IRC. Did anyone figure out _where_ these > A> frames are coming from? > A> > A> Just dropping them is cool, but I'd really like to see the contents of > A> the frames and what their origin is. > A> > A> I'm worried that they're valid stack-generated frames.. > > I agree on this. Fixing NULL pointer derefs with NULL check is not > always a right thing to do. > > A> -a > A> > A> > A> On 24 September 2014 19:26, Sean Bruno wrote: > A> > Author: sbruno > A> > Date: Thu Sep 25 02:26:05 2014 > A> > New Revision: 272089 > A> > URL: http://svnweb.freebsd.org/changeset/base/272089 > A> > > A> > Log: > A> > Fix NULL pointer deref in ipfw when using dummynet at layer 2. > A> > Drop packet if pkg->ifp is NULL, which is the case here. > A> > > A> > ref. https://github.com/HardenedBSD/hardenedBSD > A> > commit 4eef3881c64f6e3aa38eebbeaf27a947a5d47dd7 > A> > > A> > PR 193861 -- DUMMYNET LAYER2: kernel panic > A> > > A> > in this case a kernel panic occurs. Hence, when we do not get an interface, > A> > we just drop the packet in question. > A> > > A> > PR: 193681 > A> > Submitted by: David Carlier > A> > Obtained from: Hardened BSD > A> > MFC after: 2 weeks > A> > Relnotes: yes > A> > > A> > Modified: > A> > head/sys/netpfil/ipfw/ip_dn_io.c > A> > > A> > Modified: head/sys/netpfil/ipfw/ip_dn_io.c > A> > ============================================================================== > A> > --- head/sys/netpfil/ipfw/ip_dn_io.c Wed Sep 24 22:58:10 2014 (r272088) > A> > +++ head/sys/netpfil/ipfw/ip_dn_io.c Thu Sep 25 02:26:05 2014 (r272089) > A> > @@ -751,10 +751,15 @@ dummynet_send(struct mbuf *m) > A> > /* extract the dummynet info, rename the tag > A> > * to carry reinject info. > A> > */ > A> > - dst = pkt->dn_dir; > A> > - ifp = pkt->ifp; > A> > - tag->m_tag_cookie = MTAG_IPFW_RULE; > A> > - tag->m_tag_id = 0; > A> > + if (pkt->dn_dir == (DIR_OUT | PROTO_LAYER2) && > A> > + pkt->ifp == NULL) { > A> > + dst = DIR_DROP; > A> > + } else { > A> > + dst = pkt->dn_dir; > A> > + ifp = pkt->ifp; > A> > + tag->m_tag_cookie = MTAG_IPFW_RULE; > A> > + tag->m_tag_id = 0; > A> > + } > A> > } > A> > > A> > switch (dst) { > A> > > A> > Ok, moving off to freebsd-net. How should we proceded with debugging further? sean bcc src-all src-head From owner-freebsd-net@FreeBSD.ORG Thu Sep 25 11:31:22 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7CD8B07 for ; Thu, 25 Sep 2014 11:31:22 +0000 (UTC) Received: from support.denonn.eu (support.denonn.eu [185.63.253.171]) by mx1.freebsd.org (Postfix) with ESMTP id 3BA22E71 for ; Thu, 25 Sep 2014 11:31:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=dkim; d=denonn.eu; h=MIME-Version:Content-Type:Message-Id:Date:From:To:Subject; i=coarser@denonn.eu; bh=/Rg8ixRwHKwPMsaf1Mk2gB4PUjQ=; b=x00X6Bwic8TSbVdhT1O+V21taKbX1Tm2ioL0zr9a8l5nTUXJxTpQj27WVxkrupwSYs3Ee9rDQ6XP 5klD1m6fdpYnaf3wikhPmPk3GzzaXHbDFz4jeAFnURX0NujPcmomqjo1VWOFVp54BJx4H9g0clHy lCW5uIXraN5zCF2rHU0= Received: by support.denonn.eu id h4fuhq0001gu for ; Thu, 25 Sep 2014 11:30:51 +0000 (envelope-from ) MIME-Version: 1.0 Message-Id: Date: Thu, 25 Sep 2014 11:30:51 +0000 From: Hello office@hc-knights.at To: net@freebsd.org Subject: Hello net@freebsd.org 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: Thu, 25 Sep 2014 11:31:22 -0000 Hi, I wanted to check how you feel today? From owner-freebsd-net@FreeBSD.ORG Thu Sep 25 12:08:15 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2C5A67A for ; Thu, 25 Sep 2014 12:08:15 +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 56A7122C for ; Thu, 25 Sep 2014 12:08:14 +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 s8PC8Aeg040599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 25 Sep 2014 16:08:10 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id s8PC8AnY040598; Thu, 25 Sep 2014 16:08:10 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 25 Sep 2014 16:08:10 +0400 From: Gleb Smirnoff To: Ryan Stone Subject: Re: [PATCH] Convert ixl(4) and ixlv(4) to ifcounters, and fix some counter bugs Message-ID: <20140925120810.GA884@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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, 25 Sep 2014 12:08:15 -0000 On Tue, Sep 23, 2014 at 07:18:51PM -0400, Ryan Stone wrote: R> The patch below converts the ixl(4) and ixlv(4) drivers to use the new R> ifcounter interface. I've hidden the interface behind some macros to R> ensure that the driver continues to compile for FreeBSD 10 and R> earlier. The result of the macros is that the ifcounter R> implementation is somewhat clunkier than I would have liked, but I R> preferred to try and share as much code between the legacy counter R> implementation and the ifcounter implementation. R> R> I have tested the ixl driver with head. I have only compile-tested it R> for stable/10. R> R> This patch also fixes some counter bugs: R> R> - Ensure that tx discards are reported R> - There are actually two types of rx discard counters in the hardware. R> Currently the driver is only reporting discards from one of the two R> counters, so I fixed that R> - The ipackets and opackets counters were being unnecessarily R> incremented in the rx and tx paths. This was racy, unnecessary (the R> counters also get explicitly set based on the values in HW counters) R> and very bad for performance -- the cacheline contained the counters R> was constantly bouncing between CPUs. I saw this even with only one R> queue active, probably due to false sharing with some other field in R> the ifnet struct. R> R> https://people.freebsd.org/~rstone/patches/ixl/0005-Convert-ixl-and-ixlv-drivers-to-use-new-ifcounter-in.patch Thanks, Ryan! I'd suggest to use check against __FreeBSD_version >= 1100036. Can you please commit this? Navdeep promised to do cxgbe(4), Alexander is working on ixgbe. After that we can go forward with making counters in struct ifnet non-racy and cheap counter(9). -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Thu Sep 25 13:10:01 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27D6CC5B for ; Thu, 25 Sep 2014 13:10:01 +0000 (UTC) Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) (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 98B5DADE for ; Thu, 25 Sep 2014 13:10:00 +0000 (UTC) Received: from unknown [12.187.104.25] (EHLO webmail.solarflare.com) by nbfkord-smmo03.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 82414245.2b15c8dfc940.787602.00-2478.1999667.nbfkord-smmo03.seg.att.com (envelope-from ); Thu, 25 Sep 2014 13:10:00 +0000 (UTC) X-MXL-Hash: 5424142811fd42b3-e3819cb0188b0efb9a6ae39db0ec8f28317a8101 Received: from unknown [12.187.104.25] (EHLO webmail.solarflare.com) by nbfkord-smmo03.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 90314245.0.786957.00-2353.1997836.nbfkord-smmo03.seg.att.com (envelope-from ); Thu, 25 Sep 2014 13:05:15 +0000 (UTC) X-MXL-Hash: 5424130b698d365c-c64cc028743d6cc5ec277572357195aa8b6fe4fa 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; Thu, 25 Sep 2014 06:04:35 -0700 Message-ID: <54241304.1000507@solarflare.com> Date: Thu, 25 Sep 2014 17:05:08 +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: [PATCH 2/4] sfxge: Make size of Tx and Rx rings configurable Content-Type: multipart/mixed; boundary="------------090409080003090404050806" X-Originating-IP: [84.52.89.52] X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-20974.005 X-TM-AS-Result: No--7.191200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-AnalysisOut: [v=2.0 cv=Lb2LHEji c=1 sm=1 a=MkjXnYnS3dyNWGSWLXxFFQ==:17 a] X-AnalysisOut: [=Ozv50jBIw7UA:10 a=iZEowUNkIMIA:10 a=ZUGRjKkAJfQA:10 a=4ox] X-AnalysisOut: [owH2qkH0A:10 a=RB3BGLmKESwA:10 a=BLceEmwcHowA:10 a=zRKbQ67] X-AnalysisOut: [AAAAA:8 a=qg_zykTt5_OaQZwxDF0A:9 a=wPNLvfGTeEIA:10 a=s9qa1] X-AnalysisOut: [pk-s7gA:10 a=RTbKrukmD4XZ65bIP10A:9 a=QEXdDO2ut3YA:10 a=Ld] X-AnalysisOut: [izJReNRDyliNLV:21 a=jYr18rz219Sef4Lx:21] 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: Thu, 25 Sep 2014 13:10:01 -0000 --------------090409080003090404050806 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Make size of Tx and Rx rings configurable Required size of event queue is calculated now. Submitted by: Andrew Rybchenko Sponsored by: Solarflare Communications, Inc. 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. --------------090409080003090404050806 Content-Type: text/plain; charset="UTF-8"; name="rx_tx_ring" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="rx_tx_ring" Make size of Tx and Rx rings configurable Required size of event queue is calculated now. Submitted by: Andrew Rybchenko Sponsored by: Solarflare Communications, Inc. diff -r abfcbc1ff6b9 share/man/man4/sfxge.4 --- a/share/man/man4/sfxge.4 Thu Sep 25 15:59:36 2014 +0400 +++ b/share/man/man4/sfxge.4 Thu Sep 25 16:06:37 2014 +0400 @@ -76,6 +76,32 @@ .Nm driver supports all 10Gb Ethernet adapters based on Solarflare SFC9000 family controllers. +.Sh LOADER TUNABLES +Tunables can be set at the +.Xr loader 8 +prompt before booting the kernel or stored in +.Xr loader.conf 5 . +Actual values can be obtained using +.Xr sysctl 8 . +.Bl -tag -width indent +.It Va hw.sfxge.rx_ring +Maximum number of descriptors in a receive queue ring. +Supported values are: 512, 1024, 2048 and 4096. +.It Va hw.sfxge.tx_ring +Maximum number of descriptors in a transmit queue ring. +Supported values are: 512, 1024, 2048 and 4096. +.It Va hw.sfxge.tx_dpl_get_max +The maximum length of the deferred packet 'get-list' for queued transmit +packets, used only if the transmit queue lock can be acquired. +If packet is dropped, \fItx_early_drops\fR counter grows and local sender +gets ENOBUFS error. +Value must be greater than 0. +.It Va hw.sfxge.tx_dpl_put_max +The maximum length of the deferred packet 'put-list' for queued transmit +packets, used if the transmit queue lock cannot be acquired. +If packet is dropped, \fItx_early_drops\fR counter grows and local sender +gets ENOBUFS error. +Value must be greater or equal to 0. .Sh SUPPORT For general information and support, go to the Solarflare support website at: diff -r abfcbc1ff6b9 sys/dev/sfxge/sfxge.c --- a/sys/dev/sfxge/sfxge.c Thu Sep 25 15:59:36 2014 +0400 +++ b/sys/dev/sfxge/sfxge.c Thu Sep 25 16:06:37 2014 +0400 @@ -42,6 +42,7 @@ #include #include #include +#include #include #include @@ -67,6 +68,25 @@ MALLOC_DEFINE(M_SFXGE, "sfxge", "Solarflare 10GigE driver"); + +SYSCTL_NODE(_hw, OID_AUTO, sfxge, CTLFLAG_RD, 0, + "SFXGE driver parameters"); + +#define SFXGE_PARAM_RX_RING SFXGE_PARAM(rx_ring) +static int sfxge_rx_ring_entries = SFXGE_NDESCS; +TUNABLE_INT(SFXGE_PARAM_RX_RING, &sfxge_rx_ring_entries); +SYSCTL_INT(_hw_sfxge, OID_AUTO, rx_ring, CTLFLAG_RDTUN, + &sfxge_rx_ring_entries, 0, + "Maximum number of descriptors in a receive ring"); + +#define SFXGE_PARAM_TX_RING SFXGE_PARAM(tx_ring) +static int sfxge_tx_ring_entries = SFXGE_NDESCS; +TUNABLE_INT(SFXGE_PARAM_TX_RING, &sfxge_tx_ring_entries); +SYSCTL_INT(_hw_sfxge, OID_AUTO, tx_ring, CTLFLAG_RDTUN, + &sfxge_tx_ring_entries, 0, + "Maximum number of descriptors in a transmit ring"); + + static void sfxge_reset(void *arg, int npending); @@ -314,8 +334,8 @@ ifp->if_qflush = sfxge_if_qflush; #else ifp->if_start = sfxge_if_start; - IFQ_SET_MAXLEN(&ifp->if_snd, SFXGE_NDESCS - 1); - ifp->if_snd.ifq_drv_maxlen = SFXGE_NDESCS - 1; + IFQ_SET_MAXLEN(&ifp->if_snd, sc->txq_entries - 1); + ifp->if_snd.ifq_drv_maxlen = sc->txq_entries - 1; IFQ_SET_READY(&ifp->if_snd); mtx_init(&sc->tx_lock, "txq", NULL, MTX_DEF); @@ -414,6 +434,26 @@ goto fail3; sc->enp = enp; + if (!ISP2(sfxge_rx_ring_entries) || + !(sfxge_rx_ring_entries & EFX_RXQ_NDESCS_MASK)) { + log(LOG_ERR, "%s=%d must be power of 2 from %u to %u", + SFXGE_PARAM_RX_RING, sfxge_rx_ring_entries, + EFX_RXQ_MINNDESCS, EFX_RXQ_MAXNDESCS); + error = EINVAL; + goto fail_rx_ring_entries; + } + sc->rxq_entries = sfxge_rx_ring_entries; + + if (!ISP2(sfxge_tx_ring_entries) || + !(sfxge_tx_ring_entries & EFX_TXQ_NDESCS_MASK)) { + log(LOG_ERR, "%s=%d must be power of 2 from %u to %u", + SFXGE_PARAM_TX_RING, sfxge_tx_ring_entries, + EFX_TXQ_MINNDESCS, EFX_TXQ_MAXNDESCS); + error = EINVAL; + goto fail_tx_ring_entries; + } + sc->txq_entries = sfxge_tx_ring_entries; + /* Initialize MCDI to talk to the microcontroller. */ if ((error = sfxge_mcdi_init(sc)) != 0) goto fail4; @@ -486,6 +526,8 @@ sfxge_mcdi_fini(sc); fail4: +fail_tx_ring_entries: +fail_rx_ring_entries: sc->enp = NULL; efx_nic_destroy(enp); mtx_destroy(&sc->enp_lock); diff -r abfcbc1ff6b9 sys/dev/sfxge/sfxge.h --- a/sys/dev/sfxge/sfxge.h Thu Sep 25 15:59:36 2014 +0400 +++ b/sys/dev/sfxge/sfxge.h Thu Sep 25 16:06:37 2014 +0400 @@ -87,6 +87,8 @@ #include "sfxge_rx.h" #include "sfxge_tx.h" +#define ROUNDUP_POW_OF_TWO(_n) (1ULL << flsl((_n) - 1)) + #define SFXGE_IP_ALIGN 2 #define SFXGE_ETHERTYPE_LOOPBACK 0x9000 /* Xerox loopback */ @@ -106,6 +108,7 @@ enum sfxge_evq_state init_state; unsigned int index; + unsigned int entries; efsys_mem_t mem; unsigned int buf_base_id; @@ -121,7 +124,6 @@ struct sfxge_txq **txqs; }; -#define SFXGE_NEVS 4096 #define SFXGE_NDESCS 1024 #define SFXGE_MODERATION 30 @@ -209,6 +211,9 @@ efx_nic_t *enp; struct mtx enp_lock; + unsigned int rxq_entries; + unsigned int txq_entries; + bus_dma_tag_t parent_dma_tag; efsys_bar_t bar; @@ -246,6 +251,10 @@ #define SFXGE_LINK_UP(sc) ((sc)->port.link_mode != EFX_LINK_DOWN) #define SFXGE_RUNNING(sc) ((sc)->ifnet->if_drv_flags & IFF_DRV_RUNNING) +#define SFXGE_PARAM(_name) "hw.sfxge." #_name + +SYSCTL_DECL(_hw_sfxge); + /* * From sfxge.c. */ diff -r abfcbc1ff6b9 sys/dev/sfxge/sfxge_ev.c --- a/sys/dev/sfxge/sfxge_ev.c Thu Sep 25 15:59:36 2014 +0400 +++ b/sys/dev/sfxge/sfxge_ev.c Thu Sep 25 16:06:37 2014 +0400 @@ -102,7 +102,7 @@ if (rxq->init_state != SFXGE_RXQ_STARTED) goto done; - expected = rxq->pending++ & (SFXGE_NDESCS - 1); + expected = rxq->pending++ & rxq->ptr_mask; if (id != expected) { evq->exception = B_TRUE; @@ -247,10 +247,10 @@ if (txq->init_state != SFXGE_TXQ_STARTED) goto done; - stop = (id + 1) & (SFXGE_NDESCS - 1); - id = txq->pending & (SFXGE_NDESCS - 1); + stop = (id + 1) & txq->ptr_mask; + id = txq->pending & txq->ptr_mask; - delta = (stop >= id) ? (stop - id) : (SFXGE_NDESCS - id + stop); + delta = (stop >= id) ? (stop - id) : (txq->entries - id + stop); txq->pending += delta; evq->tx_done++; @@ -635,7 +635,7 @@ efx_ev_qdestroy(evq->common); efx_sram_buf_tbl_clear(sc->enp, evq->buf_base_id, - EFX_EVQ_NBUFS(SFXGE_NEVS)); + EFX_EVQ_NBUFS(evq->entries)); mtx_unlock(&evq->lock); } @@ -654,15 +654,15 @@ ("evq->init_state != SFXGE_EVQ_INITIALIZED")); /* Clear all events. */ - (void)memset(esmp->esm_base, 0xff, EFX_EVQ_SIZE(SFXGE_NEVS)); + (void)memset(esmp->esm_base, 0xff, EFX_EVQ_SIZE(evq->entries)); /* Program the buffer table. */ if ((rc = efx_sram_buf_tbl_set(sc->enp, evq->buf_base_id, esmp, - EFX_EVQ_NBUFS(SFXGE_NEVS))) != 0) - return rc; + EFX_EVQ_NBUFS(evq->entries))) != 0) + return (rc); /* Create the common code event queue. */ - if ((rc = efx_ev_qcreate(sc->enp, index, esmp, SFXGE_NEVS, + if ((rc = efx_ev_qcreate(sc->enp, index, esmp, evq->entries, evq->buf_base_id, &evq->common)) != 0) goto fail; @@ -705,7 +705,7 @@ efx_ev_qdestroy(evq->common); fail: efx_sram_buf_tbl_clear(sc->enp, evq->buf_base_id, - EFX_EVQ_NBUFS(SFXGE_NEVS)); + EFX_EVQ_NBUFS(evq->entries)); return (rc); } @@ -802,15 +802,31 @@ sc->evq[index] = evq; esmp = &evq->mem; + /* Build an event queue with room for one event per tx and rx buffer, + * plus some extra for link state events and MCDI completions. + * There are three tx queues in the first event queue and one in + * other. + */ + if (index == 0) + evq->entries = + ROUNDUP_POW_OF_TWO(sc->rxq_entries + + 3 * sc->txq_entries + + 128); + else + evq->entries = + ROUNDUP_POW_OF_TWO(sc->rxq_entries + + sc->txq_entries + + 128); + /* Initialise TX completion list */ evq->txqs = &evq->txq; /* Allocate DMA space. */ - if ((rc = sfxge_dma_alloc(sc, EFX_EVQ_SIZE(SFXGE_NEVS), esmp)) != 0) + if ((rc = sfxge_dma_alloc(sc, EFX_EVQ_SIZE(evq->entries), esmp)) != 0) return (rc); /* Allocate buffer table entries. */ - sfxge_sram_buf_tbl_alloc(sc, EFX_EVQ_NBUFS(SFXGE_NEVS), + sfxge_sram_buf_tbl_alloc(sc, EFX_EVQ_NBUFS(evq->entries), &evq->buf_base_id); mtx_init(&evq->lock, "evq", NULL, MTX_DEF); diff -r abfcbc1ff6b9 sys/dev/sfxge/sfxge_rx.c --- a/sys/dev/sfxge/sfxge_rx.c Thu Sep 25 15:59:36 2014 +0400 +++ b/sys/dev/sfxge/sfxge_rx.c Thu Sep 25 16:06:37 2014 +0400 @@ -54,8 +54,7 @@ #include "sfxge.h" #include "sfxge_rx.h" -#define RX_REFILL_THRESHOLD (EFX_RXQ_LIMIT(SFXGE_NDESCS) * 9 / 10) -#define RX_REFILL_THRESHOLD_2 (RX_REFILL_THRESHOLD / 2) +#define RX_REFILL_THRESHOLD(_entries) (EFX_RXQ_LIMIT(_entries) * 9 / 10) /* Size of the LRO hash table. Must be a power of 2. A larger table * means we can accelerate a larger number of streams. @@ -214,11 +213,11 @@ return; rxfill = rxq->added - rxq->completed; - KASSERT(rxfill <= EFX_RXQ_LIMIT(SFXGE_NDESCS), - ("rxfill > EFX_RXQ_LIMIT(SFXGE_NDESCS)")); - ntodo = min(EFX_RXQ_LIMIT(SFXGE_NDESCS) - rxfill, target); - KASSERT(ntodo <= EFX_RXQ_LIMIT(SFXGE_NDESCS), - ("ntodo > EFX_RQX_LIMIT(SFXGE_NDESCS)")); + KASSERT(rxfill <= EFX_RXQ_LIMIT(rxq->entries), + ("rxfill > EFX_RXQ_LIMIT(rxq->entries)")); + ntodo = min(EFX_RXQ_LIMIT(rxq->entries) - rxfill, target); + KASSERT(ntodo <= EFX_RXQ_LIMIT(rxq->entries), + ("ntodo > EFX_RQX_LIMIT(rxq->entries)")); if (ntodo == 0) return; @@ -231,7 +230,7 @@ bus_dma_segment_t seg; struct mbuf *m; - id = (rxq->added + batch) & (SFXGE_NDESCS - 1); + id = (rxq->added + batch) & rxq->ptr_mask; rx_desc = &rxq->queue[id]; KASSERT(rx_desc->mbuf == NULL, ("rx_desc->mbuf != NULL")); @@ -274,7 +273,7 @@ return; /* Make sure the queue is full */ - sfxge_rx_qfill(rxq, EFX_RXQ_LIMIT(SFXGE_NDESCS), B_TRUE); + sfxge_rx_qfill(rxq, EFX_RXQ_LIMIT(rxq->entries), B_TRUE); } static void __sfxge_rx_deliver(struct sfxge_softc *sc, struct mbuf *m) @@ -757,7 +756,7 @@ unsigned int id; struct sfxge_rx_sw_desc *rx_desc; - id = completed++ & (SFXGE_NDESCS - 1); + id = completed++ & rxq->ptr_mask; rx_desc = &rxq->queue[id]; m = rx_desc->mbuf; @@ -821,8 +820,8 @@ sfxge_lro_end_of_burst(rxq); /* Top up the queue if necessary */ - if (level < RX_REFILL_THRESHOLD) - sfxge_rx_qfill(rxq, EFX_RXQ_LIMIT(SFXGE_NDESCS), B_FALSE); + if (level < rxq->refill_threshold) + sfxge_rx_qfill(rxq, EFX_RXQ_LIMIT(rxq->entries), B_FALSE); } static void @@ -884,7 +883,7 @@ efx_rx_qdestroy(rxq->common); efx_sram_buf_tbl_clear(sc->enp, rxq->buf_base_id, - EFX_RXQ_NBUFS(SFXGE_NDESCS)); + EFX_RXQ_NBUFS(sc->rxq_entries)); mtx_unlock(&evq->lock); } @@ -908,12 +907,12 @@ /* Program the buffer table. */ if ((rc = efx_sram_buf_tbl_set(sc->enp, rxq->buf_base_id, esmp, - EFX_RXQ_NBUFS(SFXGE_NDESCS))) != 0) - return rc; + EFX_RXQ_NBUFS(sc->rxq_entries))) != 0) + return (rc); /* Create the common code receive queue. */ if ((rc = efx_rx_qcreate(sc->enp, index, index, EFX_RXQ_TYPE_DEFAULT, - esmp, SFXGE_NDESCS, rxq->buf_base_id, evq->common, + esmp, sc->rxq_entries, rxq->buf_base_id, evq->common, &rxq->common)) != 0) goto fail; @@ -925,7 +924,7 @@ rxq->init_state = SFXGE_RXQ_STARTED; /* Try to fill the queue from the pool. */ - sfxge_rx_qfill(rxq, EFX_RXQ_LIMIT(SFXGE_NDESCS), B_FALSE); + sfxge_rx_qfill(rxq, EFX_RXQ_LIMIT(sc->rxq_entries), B_FALSE); mtx_unlock(&evq->lock); @@ -933,8 +932,8 @@ fail: efx_sram_buf_tbl_clear(sc->enp, rxq->buf_base_id, - EFX_RXQ_NBUFS(SFXGE_NDESCS)); - return rc; + EFX_RXQ_NBUFS(sc->rxq_entries)); + return (rc); } void @@ -1105,6 +1104,9 @@ rxq = malloc(sizeof(struct sfxge_rxq), M_SFXGE, M_ZERO | M_WAITOK); rxq->sc = sc; rxq->index = index; + rxq->entries = sc->rxq_entries; + rxq->ptr_mask = rxq->entries - 1; + rxq->refill_threshold = RX_REFILL_THRESHOLD(rxq->entries); sc->rxq[index] = rxq; esmp = &rxq->mem; @@ -1112,16 +1114,16 @@ evq = sc->evq[index]; /* Allocate and zero DMA space. */ - if ((rc = sfxge_dma_alloc(sc, EFX_RXQ_SIZE(SFXGE_NDESCS), esmp)) != 0) + if ((rc = sfxge_dma_alloc(sc, EFX_RXQ_SIZE(sc->rxq_entries), esmp)) != 0) return (rc); - (void)memset(esmp->esm_base, 0, EFX_RXQ_SIZE(SFXGE_NDESCS)); + (void)memset(esmp->esm_base, 0, EFX_RXQ_SIZE(sc->rxq_entries)); /* Allocate buffer table entries. */ - sfxge_sram_buf_tbl_alloc(sc, EFX_RXQ_NBUFS(SFXGE_NDESCS), + sfxge_sram_buf_tbl_alloc(sc, EFX_RXQ_NBUFS(sc->rxq_entries), &rxq->buf_base_id); /* Allocate the context array and the flow table. */ - rxq->queue = malloc(sizeof(struct sfxge_rx_sw_desc) * SFXGE_NDESCS, + rxq->queue = malloc(sizeof(struct sfxge_rx_sw_desc) * sc->rxq_entries, M_SFXGE, M_WAITOK | M_ZERO); sfxge_lro_init(rxq); diff -r abfcbc1ff6b9 sys/dev/sfxge/sfxge_rx.h --- a/sys/dev/sfxge/sfxge_rx.h Thu Sep 25 15:59:36 2014 +0400 +++ b/sys/dev/sfxge/sfxge_rx.h Thu Sep 25 16:06:37 2014 +0400 @@ -159,6 +159,8 @@ efsys_mem_t mem; unsigned int buf_base_id; enum sfxge_rxq_state init_state; + unsigned int entries; + unsigned int ptr_mask; struct sfxge_rx_sw_desc *queue __aligned(CACHE_LINE_SIZE); unsigned int added; @@ -166,6 +168,7 @@ unsigned int completed; unsigned int loopback; struct sfxge_lro_state lro; + unsigned int refill_threshold; struct callout refill_callout; unsigned int refill_delay; diff -r abfcbc1ff6b9 sys/dev/sfxge/sfxge_tx.c --- a/sys/dev/sfxge/sfxge_tx.c Thu Sep 25 15:59:36 2014 +0400 +++ b/sys/dev/sfxge/sfxge_tx.c Thu Sep 25 16:06:37 2014 +0400 @@ -75,7 +75,7 @@ * minimum MSS of 512. */ #define SFXGE_TSO_MAX_DESC ((65535 / 512) * 2 + SFXGE_TX_MAPPING_MAX_SEG - 1) -#define SFXGE_TXQ_BLOCK_LEVEL (SFXGE_NDESCS - SFXGE_TSO_MAX_DESC) +#define SFXGE_TXQ_BLOCK_LEVEL(_entries) ((_entries) - SFXGE_TSO_MAX_DESC) /* Forward declarations. */ static inline void sfxge_tx_qdpl_service(struct sfxge_txq *txq); @@ -101,7 +101,7 @@ struct sfxge_tx_mapping *stmp; unsigned int id; - id = completed++ & (SFXGE_NDESCS - 1); + id = completed++ & txq->ptr_mask; stmp = &txq->stmp[id]; if (stmp->flags & TX_BUF_UNMAP) { @@ -125,7 +125,7 @@ unsigned int level; level = txq->added - txq->completed; - if (level <= SFXGE_TXQ_UNBLOCK_LEVEL) + if (level <= SFXGE_TXQ_UNBLOCK_LEVEL(txq->entries)) sfxge_tx_qunblock(txq); } } @@ -218,19 +218,19 @@ ("efx_tx_qpost() refragmented descriptors")); level = txq->added - txq->reaped; - KASSERT(level <= SFXGE_NDESCS, ("overfilled TX queue")); + KASSERT(level <= txq->entries, ("overfilled TX queue")); /* Clear the fragment list. */ txq->n_pend_desc = 0; /* Have we reached the block level? */ - if (level < SFXGE_TXQ_BLOCK_LEVEL) + if (level < SFXGE_TXQ_BLOCK_LEVEL(txq->entries)) return; /* Reap, and check again */ sfxge_tx_qreap(txq); level = txq->added - txq->reaped; - if (level < SFXGE_TXQ_BLOCK_LEVEL) + if (level < SFXGE_TXQ_BLOCK_LEVEL(txq->entries)) return; txq->blocked = 1; @@ -242,7 +242,7 @@ mb(); sfxge_tx_qreap(txq); level = txq->added - txq->reaped; - if (level < SFXGE_TXQ_BLOCK_LEVEL) { + if (level < SFXGE_TXQ_BLOCK_LEVEL(txq->entries)) { mb(); txq->blocked = 0; } @@ -271,7 +271,7 @@ } /* Load the packet for DMA. */ - id = txq->added & (SFXGE_NDESCS - 1); + id = txq->added & txq->ptr_mask; stmp = &txq->stmp[id]; rc = bus_dmamap_load_mbuf_sg(txq->packet_dma_tag, stmp->map, mbuf, dma_seg, &n_dma_seg, 0); @@ -318,7 +318,7 @@ stmp->flags = 0; if (__predict_false(stmp == - &txq->stmp[SFXGE_NDESCS - 1])) + &txq->stmp[txq->ptr_mask])) stmp = &txq->stmp[0]; else stmp++; @@ -762,20 +762,22 @@ * a TSO header buffer, since they must always be followed by a * payload descriptor referring to an mbuf. */ -#define TSOH_COUNT (SFXGE_NDESCS / 2u) +#define TSOH_COUNT(_txq_entries) ((_txq_entries) / 2u) #define TSOH_PER_PAGE (PAGE_SIZE / TSOH_STD_SIZE) -#define TSOH_PAGE_COUNT ((TSOH_COUNT + TSOH_PER_PAGE - 1) / TSOH_PER_PAGE) +#define TSOH_PAGE_COUNT(_txq_entries) \ + ((TSOH_COUNT(_txq_entries) + TSOH_PER_PAGE - 1) / TSOH_PER_PAGE) static int tso_init(struct sfxge_txq *txq) { struct sfxge_softc *sc = txq->sc; + unsigned int tsoh_page_count = TSOH_PAGE_COUNT(sc->txq_entries); int i, rc; /* Allocate TSO header buffers */ - txq->tsoh_buffer = malloc(TSOH_PAGE_COUNT * sizeof(txq->tsoh_buffer[0]), + txq->tsoh_buffer = malloc(tsoh_page_count * sizeof(txq->tsoh_buffer[0]), M_SFXGE, M_WAITOK); - for (i = 0; i < TSOH_PAGE_COUNT; i++) { + for (i = 0; i < tsoh_page_count; i++) { rc = sfxge_dma_alloc(sc, PAGE_SIZE, &txq->tsoh_buffer[i]); if (rc != 0) goto fail; @@ -796,7 +798,7 @@ int i; if (txq->tsoh_buffer != NULL) { - for (i = 0; i < TSOH_PAGE_COUNT; i++) + for (i = 0; i < TSOH_PAGE_COUNT(txq->sc->txq_entries); i++) sfxge_dma_free(&txq->tsoh_buffer[i]); free(txq->tsoh_buffer, M_SFXGE); } @@ -1010,12 +1012,12 @@ tso.dma_addr = dma_seg->ds_addr + tso.header_len; } - id = txq->added & (SFXGE_NDESCS - 1); + id = txq->added & txq->ptr_mask; if (__predict_false(tso_start_new_packet(txq, &tso, id))) - return -1; + return (-1); while (1) { - id = (id + 1) & (SFXGE_NDESCS - 1); + id = (id + 1) & txq->ptr_mask; tso_fill_packet_with_fragment(txq, &tso); /* Move onto the next fragment? */ @@ -1038,7 +1040,7 @@ if (txq->n_pend_desc > SFXGE_TSO_MAX_DESC - (1 + SFXGE_TX_MAPPING_MAX_SEG)) break; - next_id = (id + 1) & (SFXGE_NDESCS - 1); + next_id = (id + 1) & txq->ptr_mask; if (__predict_false(tso_start_new_packet(txq, &tso, next_id))) break; @@ -1070,7 +1072,7 @@ unsigned int level; level = txq->added - txq->completed; - if (level <= SFXGE_TXQ_UNBLOCK_LEVEL) + if (level <= SFXGE_TXQ_UNBLOCK_LEVEL(txq->entries)) txq->blocked = 0; } @@ -1146,7 +1148,7 @@ txq->common = NULL; efx_sram_buf_tbl_clear(sc->enp, txq->buf_base_id, - EFX_TXQ_NBUFS(SFXGE_NDESCS)); + EFX_TXQ_NBUFS(sc->txq_entries)); mtx_unlock(&evq->lock); mtx_unlock(SFXGE_TXQ_LOCK(txq)); @@ -1172,8 +1174,8 @@ /* Program the buffer table. */ if ((rc = efx_sram_buf_tbl_set(sc->enp, txq->buf_base_id, esmp, - EFX_TXQ_NBUFS(SFXGE_NDESCS))) != 0) - return rc; + EFX_TXQ_NBUFS(sc->txq_entries))) != 0) + return (rc); /* Determine the kind of queue we are creating. */ switch (txq->type) { @@ -1194,7 +1196,7 @@ /* Create the common code transmit queue. */ if ((rc = efx_tx_qcreate(sc->enp, index, txq->type, esmp, - SFXGE_NDESCS, txq->buf_base_id, flags, evq->common, + sc->txq_entries, txq->buf_base_id, flags, evq->common, &txq->common)) != 0) goto fail; @@ -1211,8 +1213,8 @@ fail: efx_sram_buf_tbl_clear(sc->enp, txq->buf_base_id, - EFX_TXQ_NBUFS(SFXGE_NDESCS)); - return rc; + EFX_TXQ_NBUFS(sc->txq_entries)); + return (rc); } void @@ -1280,7 +1282,7 @@ sfxge_tx_qfini(struct sfxge_softc *sc, unsigned int index) { struct sfxge_txq *txq; - unsigned int nmaps = SFXGE_NDESCS; + unsigned int nmaps; txq = sc->txq[index]; @@ -1292,6 +1294,7 @@ /* Free the context arrays. */ free(txq->pend_desc, M_SFXGE); + nmaps = sc->txq_entries; while (nmaps-- != 0) bus_dmamap_destroy(txq->packet_dma_tag, txq->stmp[nmaps].map); free(txq->stmp, M_SFXGE); @@ -1323,6 +1326,8 @@ txq = malloc(sizeof(struct sfxge_txq), M_SFXGE, M_ZERO | M_WAITOK); txq->sc = sc; + txq->entries = sc->txq_entries; + txq->ptr_mask = txq->entries - 1; sc->txq[txq_index] = txq; esmp = &txq->mem; @@ -1330,12 +1335,12 @@ evq = sc->evq[evq_index]; /* Allocate and zero DMA space for the descriptor ring. */ - if ((rc = sfxge_dma_alloc(sc, EFX_TXQ_SIZE(SFXGE_NDESCS), esmp)) != 0) + if ((rc = sfxge_dma_alloc(sc, EFX_TXQ_SIZE(sc->txq_entries), esmp)) != 0) return (rc); - (void)memset(esmp->esm_base, 0, EFX_TXQ_SIZE(SFXGE_NDESCS)); + (void)memset(esmp->esm_base, 0, EFX_TXQ_SIZE(sc->txq_entries)); /* Allocate buffer table entries. */ - sfxge_sram_buf_tbl_alloc(sc, EFX_TXQ_NBUFS(SFXGE_NDESCS), + sfxge_sram_buf_tbl_alloc(sc, EFX_TXQ_NBUFS(sc->txq_entries), &txq->buf_base_id); /* Create a DMA tag for packet mappings. */ @@ -1349,13 +1354,13 @@ } /* Allocate pending descriptor array for batching writes. */ - txq->pend_desc = malloc(sizeof(efx_buffer_t) * SFXGE_NDESCS, + txq->pend_desc = malloc(sizeof(efx_buffer_t) * sc->txq_entries, M_SFXGE, M_ZERO | M_WAITOK); /* Allocate and initialise mbuf DMA mapping array. */ - txq->stmp = malloc(sizeof(struct sfxge_tx_mapping) * SFXGE_NDESCS, + txq->stmp = malloc(sizeof(struct sfxge_tx_mapping) * sc->txq_entries, M_SFXGE, M_ZERO | M_WAITOK); - for (nmaps = 0; nmaps < SFXGE_NDESCS; nmaps++) { + for (nmaps = 0; nmaps < sc->txq_entries; nmaps++) { rc = bus_dmamap_create(txq->packet_dma_tag, 0, &txq->stmp[nmaps].map); if (rc != 0) diff -r abfcbc1ff6b9 sys/dev/sfxge/sfxge_tx.h --- a/sys/dev/sfxge/sfxge_tx.h Thu Sep 25 15:59:36 2014 +0400 +++ b/sys/dev/sfxge/sfxge_tx.h Thu Sep 25 16:06:37 2014 +0400 @@ -106,7 +106,7 @@ SFXGE_TXQ_NTYPES }; -#define SFXGE_TXQ_UNBLOCK_LEVEL (EFX_TXQ_LIMIT(SFXGE_NDESCS) / 4) +#define SFXGE_TXQ_UNBLOCK_LEVEL(_entries) (EFX_TXQ_LIMIT(_entries) / 4) #define SFXGE_TX_BATCH 64 @@ -128,6 +128,8 @@ unsigned int evq_index; efsys_mem_t mem; unsigned int buf_base_id; + unsigned int entries; + unsigned int ptr_mask; struct sfxge_tx_mapping *stmp; /* Packets in flight. */ bus_dma_tag_t packet_dma_tag; --------------090409080003090404050806-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 25 13:14:13 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC396E20 for ; Thu, 25 Sep 2014 13:14:13 +0000 (UTC) Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) (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 441DDBC3 for ; Thu, 25 Sep 2014 13:14:13 +0000 (UTC) Received: from unknown [12.187.104.25] (EHLO webmail.solarflare.com) by nbfkord-smmo03.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 52514245.2b15b39da940.788207.00-2490.2001331.nbfkord-smmo03.seg.att.com (envelope-from ); Thu, 25 Sep 2014 13:14:13 +0000 (UTC) X-MXL-Hash: 54241525753bf69d-6ae4343d6648da81f33d8cb0f745348446e534ea Received: from unknown [12.187.104.25] (EHLO webmail.solarflare.com) by nbfkord-smmo03.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id f0514245.0.788166.00-2385.2001206.nbfkord-smmo03.seg.att.com (envelope-from ); Thu, 25 Sep 2014 13:13:56 +0000 (UTC) X-MXL-Hash: 5424151406cdc755-acd2e0d0c1678773b02009735e699851c2ed2565 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; Thu, 25 Sep 2014 06:13:15 -0700 Message-ID: <5424150B.2000606@solarflare.com> Date: Thu, 25 Sep 2014 17:13:47 +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: [PATCH 3/4] sfxge: Add sysctl to get Tx queue deferred packet get-list counter Content-Type: multipart/mixed; boundary="------------010403060201090708090203" X-Originating-IP: [84.52.89.52] X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-20974.005 X-TM-AS-Result: No--1.093600-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-AnalysisOut: [v=2.0 cv=Lb2LHEji c=1 sm=1 a=MkjXnYnS3dyNWGSWLXxFFQ==:17 a] X-AnalysisOut: [=Ozv50jBIw7UA:10 a=oDRzG1I58OgA:10 a=Ya0UbulxNOQA:10 a=4ox] X-AnalysisOut: [owH2qkH0A:10 a=RB3BGLmKESwA:10 a=BLceEmwcHowA:10 a=zRKbQ67] X-AnalysisOut: [AAAAA:8 a=qg_zykTt5_OaQZwxDF0A:9 a=wPNLvfGTeEIA:10 a=ciaWO] X-AnalysisOut: [uxtwEfcaP39IWEA:9 a=QEXdDO2ut3YA:10 a=s9qa1pk-s7gA: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: Thu, 25 Sep 2014 13:14:13 -0000 --------------010403060201090708090203 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable The patch allows to check state of the software Tx queues in run time. 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. --------------010403060201090708090203 Content-Type: text/plain; charset="UTF-8"; name="get_count_show" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="get_count_show" Add sysctl to get Tx queue deferred packet get-list counter Submitted by: Andrew Rybchenko Sponsored by: Solarflare Communications, Inc. diff -r 099f556d39e0 sys/dev/sfxge/sfxge.h --- a/sys/dev/sfxge/sfxge.h Thu Sep 25 16:24:14 2014 +0400 +++ b/sys/dev/sfxge/sfxge.h Thu Sep 25 16:30:30 2014 +0400 @@ -202,6 +202,7 @@ struct ifnet *ifnet; unsigned int if_flags; struct sysctl_oid *stats_node; + struct sysctl_oid *txqs_node; struct task task_reset; diff -r 099f556d39e0 sys/dev/sfxge/sfxge_tx.c --- a/sys/dev/sfxge/sfxge_tx.c Thu Sep 25 16:24:14 2014 +0400 +++ b/sys/dev/sfxge/sfxge_tx.c Thu Sep 25 16:30:30 2014 +0400 @@ -176,7 +176,7 @@ KASSERT(*get_tailp == NULL, ("*get_tailp != NULL")); *stdp->std_getp = get_next; stdp->std_getp = get_tailp; - stdp->std_count += count; + stdp->std_get_count += count; } #endif /* SFXGE_HAVE_MQ */ @@ -380,7 +380,7 @@ prefetch_read_many(txq->common); mbuf = stdp->std_get; - count = stdp->std_count; + count = stdp->std_get_count; while (count != 0) { KASSERT(mbuf != NULL, ("mbuf == NULL")); @@ -412,17 +412,17 @@ if (count == 0) { KASSERT(mbuf == NULL, ("mbuf != NULL")); stdp->std_get = NULL; - stdp->std_count = 0; + stdp->std_get_count = 0; stdp->std_getp = &stdp->std_get; } else { stdp->std_get = mbuf; - stdp->std_count = count; + stdp->std_get_count = count; } if (txq->added != pushed) efx_tx_qpush(txq->common, txq->added); - KASSERT(txq->blocked || stdp->std_count == 0, + KASSERT(txq->blocked || stdp->std_get_count == 0, ("queue unblocked but count is non-zero")); } @@ -476,12 +476,12 @@ sfxge_tx_qdpl_swizzle(txq); - if (stdp->std_count >= SFXGE_TX_DPL_GET_PKT_LIMIT_DEFAULT) + if (stdp->std_get_count >= SFXGE_TX_DPL_GET_PKT_LIMIT_DEFAULT) return (ENOBUFS); *(stdp->std_getp) = mbuf; stdp->std_getp = &mbuf->m_nextpkt; - stdp->std_count++; + stdp->std_get_count++; } else { volatile uintptr_t *putp; uintptr_t old; @@ -575,7 +575,7 @@ m_freem(mbuf); } stdp->std_get = NULL; - stdp->std_count = 0; + stdp->std_get_count = 0; stdp->std_getp = &stdp->std_get; mtx_unlock(&txq->lock); @@ -1315,6 +1315,8 @@ sfxge_tx_qinit(struct sfxge_softc *sc, unsigned int txq_index, enum sfxge_txq_type type, unsigned int evq_index) { + char name[16]; + struct sysctl_oid *txq_node; struct sfxge_txq *txq; struct sfxge_evq *evq; #ifdef SFXGE_HAVE_MQ @@ -1367,6 +1369,16 @@ goto fail2; } + snprintf(name, sizeof(name), "%u", txq_index); + txq_node = SYSCTL_ADD_NODE( + device_get_sysctl_ctx(sc->dev), + SYSCTL_CHILDREN(sc->txqs_node), + OID_AUTO, name, CTLFLAG_RD, NULL, ""); + if (txq_node == NULL) { + rc = ENOMEM; + goto fail_txq_node; + } + if (type == SFXGE_TXQ_IP_TCP_UDP_CKSUM && (rc = tso_init(txq)) != 0) goto fail3; @@ -1377,6 +1389,11 @@ stdp->std_getp = &stdp->std_get; mtx_init(&txq->lock, "txq", NULL, MTX_DEF); + + SYSCTL_ADD_UINT(device_get_sysctl_ctx(sc->dev), + SYSCTL_CHILDREN(txq_node), OID_AUTO, + "dpl_get_count", CTLFLAG_RD | CTLFLAG_STATS, + &stdp->std_get_count, 0, ""); #endif txq->type = type; @@ -1387,6 +1404,7 @@ return (0); fail3: +fail_txq_node: free(txq->pend_desc, M_SFXGE); fail2: while (nmaps-- != 0) @@ -1480,6 +1498,15 @@ KASSERT(intr->state == SFXGE_INTR_INITIALIZED, ("intr->state != SFXGE_INTR_INITIALIZED")); + sc->txqs_node = SYSCTL_ADD_NODE( + device_get_sysctl_ctx(sc->dev), + SYSCTL_CHILDREN(device_get_sysctl_tree(sc->dev)), + OID_AUTO, "txq", CTLFLAG_RD, NULL, "Tx queues"); + if (sc->txqs_node == NULL) { + rc = ENOMEM; + goto fail_txq_node; + } + /* Initialize the transmit queues */ if ((rc = sfxge_tx_qinit(sc, SFXGE_TXQ_NON_CKSUM, SFXGE_TXQ_NON_CKSUM, 0)) != 0) @@ -1509,5 +1536,6 @@ sfxge_tx_qfini(sc, SFXGE_TXQ_NON_CKSUM); fail: +fail_txq_node: return (rc); } diff -r 099f556d39e0 sys/dev/sfxge/sfxge_tx.h --- a/sys/dev/sfxge/sfxge_tx.h Thu Sep 25 16:24:14 2014 +0400 +++ b/sys/dev/sfxge/sfxge_tx.h Thu Sep 25 16:30:30 2014 +0400 @@ -82,10 +82,10 @@ * Deferred packet list. */ struct sfxge_tx_dpl { - uintptr_t std_put; /* Head of put list. */ - struct mbuf *std_get; /* Head of get list. */ - struct mbuf **std_getp; /* Tail of get list. */ - unsigned int std_count; /* Count of packets. */ + uintptr_t std_put; /* Head of put list. */ + struct mbuf *std_get; /* Head of get list. */ + struct mbuf **std_getp; /* Tail of get list. */ + unsigned int std_get_count; /* Packets in get list. */ }; --------------010403060201090708090203-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 25 13:17: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D50EEF4 for ; Thu, 25 Sep 2014 13:17:15 +0000 (UTC) Received: from nbfkord-smmo01.seg.att.com (nbfkord-smmo01.seg.att.com [209.65.160.76]) (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 D751CBF0 for ; Thu, 25 Sep 2014 13:17:14 +0000 (UTC) Received: from unknown [12.187.104.25] (EHLO webmail.solarflare.com) by nbfkord-smmo01.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id ad514245.2b41ef9a1940.5762.00-2499.11470.nbfkord-smmo01.seg.att.com (envelope-from ); Thu, 25 Sep 2014 13:17:14 +0000 (UTC) X-MXL-Hash: 542415da7b35fe58-732054f36b02073bf7f0a2eadf708878b5819c23 Received: from unknown [12.187.104.25] (EHLO webmail.solarflare.com) by nbfkord-smmo01.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 8f114245.0.727.00-2380.1260.nbfkord-smmo01.seg.att.com (envelope-from ); Thu, 25 Sep 2014 13:00:45 +0000 (UTC) X-MXL-Hash: 542411fd41896d10-1dd6e67cab37ab7383b29c7b8fc07a1f5c17d54c 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; Thu, 25 Sep 2014 06:00:04 -0700 Message-ID: <542411F4.6050404@solarflare.com> Date: Thu, 25 Sep 2014 17:00:36 +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: [PATCH 1/4] sfxge: cleanup: code style fixes Content-Type: multipart/mixed; boundary="------------000900020605040502010202" X-Originating-IP: [84.52.89.52] X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-20974.005 X-TM-AS-Result: No--6.622800-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-AnalysisOut: [v=2.0 cv=bdHcppzB c=1 sm=1 a=MkjXnYnS3dyNWGSWLXxFFQ==:17 a] X-AnalysisOut: [=Ozv50jBIw7UA:10 a=sOSmOZvzYpsA:10 a=jJKnQX15q-cA:10 a=4ox] X-AnalysisOut: [owH2qkH0A:10 a=RB3BGLmKESwA:10 a=BLceEmwcHowA:10 a=zRKbQ67] X-AnalysisOut: [AAAAA:8 a=qg_zykTt5_OaQZwxDF0A:9 a=wPNLvfGTeEIA:10 a=s9qa1] X-AnalysisOut: [pk-s7gA:10 a=0XUAfFN47ZxevexDWRoA:9 a=QEXdDO2ut3YA:10 a=SL] X-AnalysisOut: [Xm6D6uGZOTnXR_:21 a=cCbRZeE_8OnCNq1O:21] 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: Thu, 25 Sep 2014 13:17:15 -0000 --------------000900020605040502010202 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Remove trailing whitespaces and tabs. Enclose value in return statements in parentheses. Use tabs after #define. Do not skip comparison with 0/NULL in boolean expressions. Submitted by: Andrew Rybchenko Sponsored by: Solarflare Communications, Inc. 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. --------------000900020605040502010202 Content-Type: text/plain; charset="UTF-8"; name="cleanup" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cleanup" cleanup: code style fixes Remove trailing whitespaces and tabs. Enclose value in return statements in parentheses. Use tabs after #define. Do not skip comparison with 0/NULL in boolean expressions. Submitted by: Andrew Rybchenko Sponsored by: Solarflare Communications, Inc. diff -r e7f6237a8d92 sys/dev/sfxge/common/efsys.h --- a/sys/dev/sfxge/common/efsys.h Thu Sep 25 12:25:30 2014 +0400 +++ b/sys/dev/sfxge/common/efsys.h Thu Sep 25 15:59:36 2014 +0400 @@ -53,44 +53,44 @@ #define EFSYS_HAS_UINT64 1 #define EFSYS_USE_UINT64 0 #if _BYTE_ORDER == _BIG_ENDIAN -#define EFSYS_IS_BIG_ENDIAN 1 -#define EFSYS_IS_LITTLE_ENDIAN 0 +#define EFSYS_IS_BIG_ENDIAN 1 +#define EFSYS_IS_LITTLE_ENDIAN 0 #elif _BYTE_ORDER == _LITTLE_ENDIAN -#define EFSYS_IS_BIG_ENDIAN 0 -#define EFSYS_IS_LITTLE_ENDIAN 1 +#define EFSYS_IS_BIG_ENDIAN 0 +#define EFSYS_IS_LITTLE_ENDIAN 1 #endif #include "efx_types.h" /* Common code requires this */ #if __FreeBSD_version < 800068 -#define memmove(d, s, l) bcopy(s, d, l) +#define memmove(d, s, l) bcopy(s, d, l) #endif - + /* FreeBSD equivalents of Solaris things */ #ifndef _NOTE -#define _NOTE(s) +#define _NOTE(s) #endif #ifndef B_FALSE -#define B_FALSE FALSE +#define B_FALSE FALSE #endif #ifndef B_TRUE -#define B_TRUE TRUE +#define B_TRUE TRUE #endif #ifndef IS_P2ALIGNED -#define IS_P2ALIGNED(v, a) ((((uintptr_t)(v)) & ((uintptr_t)(a) - 1)) == 0) +#define IS_P2ALIGNED(v, a) ((((uintptr_t)(v)) & ((uintptr_t)(a) - 1)) == 0) #endif #ifndef P2ROUNDUP -#define P2ROUNDUP(x, align) (-(-(x) & -(align))) +#define P2ROUNDUP(x, align) (-(-(x) & -(align))) #endif #ifndef IS2P -#define ISP2(x) (((x) & ((x) - 1)) == 0) +#define ISP2(x) (((x) & ((x) - 1)) == 0) #endif -#define ENOTACTIVE EINVAL +#define ENOTACTIVE EINVAL /* Memory type to use on FreeBSD */ MALLOC_DECLARE(M_SFXGE); @@ -242,7 +242,7 @@ #define EFSYS_OPT_PHY_PROPS 0 #define EFSYS_OPT_PHY_BIST 1 #define EFSYS_OPT_PHY_LED_CONTROL 1 -#define EFSYS_OPT_PHY_FLAGS 0 +#define EFSYS_OPT_PHY_FLAGS 0 #define EFSYS_OPT_VPD 1 #define EFSYS_OPT_NVRAM 1 @@ -256,8 +256,8 @@ #define EFSYS_OPT_WOL 1 #define EFSYS_OPT_RX_SCALE 1 #define EFSYS_OPT_QSTATS 1 -#define EFSYS_OPT_FILTER 0 -#define EFSYS_OPT_RX_SCATTER 0 +#define EFSYS_OPT_FILTER 0 +#define EFSYS_OPT_RX_SCATTER 0 #define EFSYS_OPT_RX_HDR_SPLIT 0 #define EFSYS_OPT_EV_PREFETCH 0 @@ -272,7 +272,7 @@ #ifndef DTRACE_PROBE -#define EFSYS_PROBE(_name) +#define EFSYS_PROBE(_name) #define EFSYS_PROBE1(_name, _type1, _arg1) @@ -815,16 +815,16 @@ panic(#_exp); \ } while (0) -#define EFSYS_ASSERT3(_x, _op, _y, _t) do { \ +#define EFSYS_ASSERT3(_x, _op, _y, _t) do { \ const _t __x = (_t)(_x); \ const _t __y = (_t)(_y); \ if (!(__x _op __y)) \ - panic("assertion failed at %s:%u", __FILE__, __LINE__); \ + panic("assertion failed at %s:%u", __FILE__, __LINE__); \ } while(0) -#define EFSYS_ASSERT3U(_x, _op, _y) EFSYS_ASSERT3(_x, _op, _y, uint64_t) -#define EFSYS_ASSERT3S(_x, _op, _y) EFSYS_ASSERT3(_x, _op, _y, int64_t) -#define EFSYS_ASSERT3P(_x, _op, _y) EFSYS_ASSERT3(_x, _op, _y, uintptr_t) +#define EFSYS_ASSERT3U(_x, _op, _y) EFSYS_ASSERT3(_x, _op, _y, uint64_t) +#define EFSYS_ASSERT3S(_x, _op, _y) EFSYS_ASSERT3(_x, _op, _y, int64_t) +#define EFSYS_ASSERT3P(_x, _op, _y) EFSYS_ASSERT3(_x, _op, _y, uintptr_t) #ifdef __cplusplus } diff -r e7f6237a8d92 sys/dev/sfxge/sfxge.c --- a/sys/dev/sfxge/sfxge.c Thu Sep 25 12:25:30 2014 +0400 +++ b/sys/dev/sfxge/sfxge.c Thu Sep 25 15:59:36 2014 +0400 @@ -57,12 +57,12 @@ #include "sfxge.h" #include "sfxge_rx.h" -#define SFXGE_CAP (IFCAP_VLAN_MTU | \ +#define SFXGE_CAP (IFCAP_VLAN_MTU | \ IFCAP_HWCSUM | IFCAP_VLAN_HWCSUM | IFCAP_TSO | \ IFCAP_JUMBO_MTU | IFCAP_LRO | \ IFCAP_VLAN_HWTSO | IFCAP_LINKSTATE) -#define SFXGE_CAP_ENABLE SFXGE_CAP -#define SFXGE_CAP_FIXED (IFCAP_VLAN_MTU | IFCAP_HWCSUM | IFCAP_VLAN_HWCSUM | \ +#define SFXGE_CAP_ENABLE SFXGE_CAP +#define SFXGE_CAP_FIXED (IFCAP_VLAN_MTU | IFCAP_HWCSUM | IFCAP_VLAN_HWCSUM | \ IFCAP_JUMBO_MTU | IFCAP_LINKSTATE) MALLOC_DEFINE(M_SFXGE, "sfxge", "Solarflare 10GigE driver"); @@ -78,7 +78,7 @@ sx_assert(&sc->softc_lock, LA_XLOCKED); if (sc->init_state == SFXGE_STARTED) - return 0; + return (0); if (sc->init_state != SFXGE_REGISTERED) { rc = EINVAL; @@ -223,7 +223,7 @@ ifp->if_mtu = ifr->ifr_mtu; error = sfxge_start(sc); sx_xunlock(&sc->softc_lock); - if (error) { + if (error != 0) { ifp->if_flags &= ~IFF_UP; ifp->if_drv_flags &= ~IFF_DRV_RUNNING; if_down(ifp); @@ -287,7 +287,7 @@ if_free(ifp); } -static int +static int sfxge_ifnet_init(struct ifnet *ifp, struct sfxge_softc *sc) { const efx_nic_cfg_t *encp = efx_nic_cfg_get(sc->enp); @@ -324,11 +324,11 @@ if ((rc = sfxge_port_ifmedia_init(sc)) != 0) goto fail; - return 0; + return (0); fail: ether_ifdetach(sc->ifnet); - return rc; + return (rc); } void @@ -347,7 +347,7 @@ { efsys_bar_t *esbp = &sc->bar; - esbp->esb_rid = PCIR_BAR(EFX_MEM_BAR); + esbp->esb_rid = PCIR_BAR(EFX_MEM_BAR); if ((esbp->esb_res = bus_alloc_resource_any(sc->dev, SYS_RES_MEMORY, &esbp->esb_rid, RF_ACTIVE)) == NULL) { device_printf(sc->dev, "Cannot allocate BAR region %d\n", @@ -386,7 +386,7 @@ device_get_sysctl_ctx(dev), SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO, "stats", CTLFLAG_RD, NULL, "Statistics"); - if (!sc->stats_node) { + if (sc->stats_node == NULL) { error = ENOMEM; goto fail; } @@ -554,14 +554,14 @@ struct sfxge_softc *sc = arg1; efx_vpd_value_t value; int rc; - + value.evv_tag = arg2 >> 16; value.evv_keyword = arg2 & 0xffff; if ((rc = efx_vpd_get(sc->enp, sc->vpd_data, sc->vpd_size, &value)) != 0) - return rc; + return (rc); - return SYSCTL_OUT(req, value.evv_value, value.evv_length); + return (SYSCTL_OUT(req, value.evv_value, value.evv_length)); } static void @@ -623,12 +623,12 @@ for (keyword[1] = 'A'; keyword[1] <= 'Z'; keyword[1]++) sfxge_vpd_try_add(sc, vpd_list, EFX_VPD_RO, keyword); - return 0; - + return (0); + fail2: free(sc->vpd_data, M_SFXGE); fail: - return rc; + return (rc); } static void @@ -745,12 +745,12 @@ pci_device_id = pci_get_device(dev); rc = efx_family(pci_vendor_id, pci_device_id, &family); - if (rc) - return ENXIO; + if (rc != 0) + return (ENXIO); KASSERT(family == EFX_FAMILY_SIENA, ("impossible controller family")); device_set_desc(dev, "Solarflare SFC9000 family"); - return 0; + return (0); } static device_method_t sfxge_methods[] = { diff -r e7f6237a8d92 sys/dev/sfxge/sfxge.h --- a/sys/dev/sfxge/sfxge.h Thu Sep 25 12:25:30 2014 +0400 +++ b/sys/dev/sfxge/sfxge.h Thu Sep 25 15:59:36 2014 +0400 @@ -30,7 +30,7 @@ */ #ifndef _SFXGE_H -#define _SFXGE_H +#define _SFXGE_H #include #include @@ -53,43 +53,43 @@ /* This should be right on most machines the driver will be used on, and * we needn't care too much about wasting a few KB per interface. */ -#define CACHE_LINE_SIZE 128 +#define CACHE_LINE_SIZE 128 #endif #ifndef IFCAP_LINKSTATE -#define IFCAP_LINKSTATE 0 +#define IFCAP_LINKSTATE 0 #endif #ifndef IFCAP_VLAN_HWTSO -#define IFCAP_VLAN_HWTSO 0 +#define IFCAP_VLAN_HWTSO 0 #endif #ifndef IFM_10G_T -#define IFM_10G_T IFM_UNKNOWN +#define IFM_10G_T IFM_UNKNOWN #endif #ifndef IFM_10G_KX4 -#define IFM_10G_KX4 IFM_10G_CX4 +#define IFM_10G_KX4 IFM_10G_CX4 #endif #if __FreeBSD_version >= 800054 /* Networking core is multiqueue aware. We can manage our own TX * queues and use m_pkthdr.flowid. */ -#define SFXGE_HAVE_MQ +#define SFXGE_HAVE_MQ #endif #if (__FreeBSD_version >= 800501 && __FreeBSD_version < 900000) || \ __FreeBSD_version >= 900003 -#define SFXGE_HAVE_DESCRIBE_INTR +#define SFXGE_HAVE_DESCRIBE_INTR #endif #ifdef IFM_ETH_RXPAUSE -#define SFXGE_HAVE_PAUSE_MEDIAOPTS +#define SFXGE_HAVE_PAUSE_MEDIAOPTS #endif #ifndef CTLTYPE_U64 -#define CTLTYPE_U64 CTLTYPE_QUAD +#define CTLTYPE_U64 CTLTYPE_QUAD #endif #include "sfxge_rx.h" #include "sfxge_tx.h" -#define SFXGE_IP_ALIGN 2 +#define SFXGE_IP_ALIGN 2 -#define SFXGE_ETHERTYPE_LOOPBACK 0x9000 /* Xerox loopback */ +#define SFXGE_ETHERTYPE_LOOPBACK 0x9000 /* Xerox loopback */ enum sfxge_evq_state { SFXGE_EVQ_UNINITIALIZED = 0, @@ -133,9 +133,9 @@ }; struct sfxge_intr_hdl { - int eih_rid; - void *eih_tag; - struct resource *eih_res; + int eih_rid; + void *eih_tag; + struct resource *eih_res; }; struct sfxge_intr { @@ -197,7 +197,7 @@ device_t dev; struct sx softc_lock; enum sfxge_softc_state init_state; - struct ifnet *ifnet; + struct ifnet *ifnet; unsigned int if_flags; struct sysctl_oid *stats_node; @@ -209,7 +209,7 @@ efx_nic_t *enp; struct mtx enp_lock; - bus_dma_tag_t parent_dma_tag; + bus_dma_tag_t parent_dma_tag; efsys_bar_t bar; struct sfxge_intr intr; @@ -243,8 +243,8 @@ #endif }; -#define SFXGE_LINK_UP(sc) ((sc)->port.link_mode != EFX_LINK_DOWN) -#define SFXGE_RUNNING(sc) ((sc)->ifnet->if_drv_flags & IFF_DRV_RUNNING) +#define SFXGE_LINK_UP(sc) ((sc)->port.link_mode != EFX_LINK_DOWN) +#define SFXGE_RUNNING(sc) ((sc)->ifnet->if_drv_flags & IFF_DRV_RUNNING) /* * From sfxge.c. @@ -299,6 +299,6 @@ extern int sfxge_mac_filter_set(struct sfxge_softc *sc); extern int sfxge_port_ifmedia_init(struct sfxge_softc *sc); -#define SFXGE_MAX_MTU (9 * 1024) +#define SFXGE_MAX_MTU (9 * 1024) #endif /* _SFXGE_H */ diff -r e7f6237a8d92 sys/dev/sfxge/sfxge_dma.c --- a/sys/dev/sfxge/sfxge_dma.c Thu Sep 25 12:25:30 2014 +0400 +++ b/sys/dev/sfxge/sfxge_dma.c Thu Sep 25 15:59:36 2014 +0400 @@ -50,7 +50,7 @@ addr = arg; - if (error) { + if (error != 0) { *addr = 0; return; } @@ -82,7 +82,7 @@ return (0); } #if defined(__i386__) || defined(__amd64__) - while (m && seg_count < maxsegs) { + while (m != NULL && seg_count < maxsegs) { /* * firmware doesn't like empty segments */ @@ -197,7 +197,7 @@ BUS_SPACE_MAXSIZE_32BIT, /* maxsegsize */ 0, /* flags */ NULL, NULL, /* lock, lockarg */ - &sc->parent_dma_tag)) { + &sc->parent_dma_tag) != 0) { device_printf(sc->dev, "Cannot allocate parent DMA tag\n"); return (ENOMEM); } diff -r e7f6237a8d92 sys/dev/sfxge/sfxge_ev.c --- a/sys/dev/sfxge/sfxge_ev.c Thu Sep 25 12:25:30 2014 +0400 +++ b/sys/dev/sfxge/sfxge_ev.c Thu Sep 25 15:59:36 2014 +0400 @@ -226,7 +226,7 @@ KASSERT((evq->index == 0 && label < SFXGE_TXQ_NTYPES) || (label == SFXGE_TXQ_IP_TCP_UDP_CKSUM), ("unexpected txq label")); index = (evq->index == 0) ? label : (evq->index - 1 + SFXGE_TXQ_NTYPES); - return evq->sc->txq[index]; + return (evq->sc->txq[index]); } static boolean_t @@ -443,7 +443,7 @@ sfxge_ev_stat_update(sc); - return SYSCTL_OUT(req, &sc->ev_stats[id], sizeof(sc->ev_stats[id])); + return (SYSCTL_OUT(req, &sc->ev_stats[id], sizeof(sc->ev_stats[id]))); } static void @@ -493,7 +493,7 @@ sx_xlock(&sc->softc_lock); - if (req->newptr) { + if (req->newptr != NULL) { if ((error = SYSCTL_IN(req, &moderation, sizeof(moderation))) != 0) goto out; @@ -520,14 +520,14 @@ out: sx_xunlock(&sc->softc_lock); - return error; + return (error); } static boolean_t sfxge_ev_initialized(void *arg) { struct sfxge_evq *evq; - + evq = (struct sfxge_evq *)arg; KASSERT(evq->init_state == SFXGE_EVQ_STARTING, @@ -746,7 +746,7 @@ /* Initialize the event module */ if ((rc = efx_ev_init(sc->enp)) != 0) - return rc; + return (rc); /* Start the event queues */ for (index = 0; index < intr->n_alloc; index++) { diff -r e7f6237a8d92 sys/dev/sfxge/sfxge_intr.c --- a/sys/dev/sfxge/sfxge_intr.c Thu Sep 25 12:25:30 2014 +0400 +++ b/sys/dev/sfxge/sfxge_intr.c Thu Sep 25 15:59:36 2014 +0400 @@ -70,19 +70,19 @@ ("intr->type != EFX_INTR_LINE")); if (intr->state != SFXGE_INTR_STARTED) - return FILTER_STRAY; + return (FILTER_STRAY); (void)efx_intr_status_line(enp, &fatal, &qmask); if (fatal) { (void) efx_intr_disable(enp); (void) efx_intr_fatal(enp); - return FILTER_HANDLED; + return (FILTER_HANDLED); } if (qmask != 0) { intr->zero_count = 0; - return FILTER_SCHEDULE_THREAD; + return (FILTER_SCHEDULE_THREAD); } /* SF bug 15783: If the function is not asserting its IRQ and @@ -97,13 +97,13 @@ if (intr->zero_count++ == 0) { if (evq->init_state == SFXGE_EVQ_STARTED) { if (efx_ev_qpending(evq->common, evq->read_ptr)) - return FILTER_SCHEDULE_THREAD; + return (FILTER_SCHEDULE_THREAD); efx_ev_qprime(evq->common, evq->read_ptr); - return FILTER_HANDLED; + return (FILTER_HANDLED); } } - return FILTER_STRAY; + return (FILTER_STRAY); } static void @@ -175,7 +175,7 @@ default: KASSERT(0, ("Invalid interrupt type")); - return EINVAL; + return (EINVAL); } /* Try to add the handlers */ @@ -254,7 +254,7 @@ table[i].eih_res = res; } - if (error) { + if (error != 0) { count = i - 1; for (i = 0; i < count; i++) bus_release_resource(dev, SYS_RES_IRQ, @@ -349,7 +349,7 @@ if (count == 0) return (EINVAL); - if ((error = pci_alloc_msi(dev, &count)) != 0) + if ((error = pci_alloc_msi(dev, &count)) != 0) return (ENOMEM); /* Allocate interrupt handler. */ @@ -424,7 +424,7 @@ sfxge_intr_stop(struct sfxge_softc *sc) { struct sfxge_intr *intr; - + intr = &sc->intr; KASSERT(intr->state == SFXGE_INTR_STARTED, diff -r e7f6237a8d92 sys/dev/sfxge/sfxge_port.c --- a/sys/dev/sfxge/sfxge_port.c Thu Sep 25 12:25:30 2014 +0400 +++ b/sys/dev/sfxge/sfxge_port.c Thu Sep 25 15:59:36 2014 +0400 @@ -74,7 +74,7 @@ /* Try to update the cached counters */ if ((rc = efx_mac_stats_update(sc->enp, esmp, - port->mac_stats.decode_buf, NULL)) != EAGAIN) + port->mac_stats.decode_buf, NULL)) != EAGAIN) goto out; DELAY(100); @@ -83,7 +83,7 @@ rc = ETIMEDOUT; out: mtx_unlock(&port->lock); - return rc; + return (rc); } static int @@ -94,11 +94,11 @@ int rc; if ((rc = sfxge_mac_stat_update(sc)) != 0) - return rc; + return (rc); - return SYSCTL_OUT(req, + return (SYSCTL_OUT(req, (uint64_t *)sc->port.mac_stats.decode_buf + id, - sizeof(uint64_t)); + sizeof(uint64_t))); } static void @@ -130,9 +130,9 @@ struct ifmedia_entry *ifm = sc->media.ifm_cur; if (ifm->ifm_media == (IFM_ETHER | IFM_AUTO)) - return EFX_FCNTL_RESPOND | EFX_FCNTL_GENERATE; - return ((ifm->ifm_media & IFM_ETH_RXPAUSE) ? EFX_FCNTL_RESPOND : 0) | - ((ifm->ifm_media & IFM_ETH_TXPAUSE) ? EFX_FCNTL_GENERATE : 0); + return (EFX_FCNTL_RESPOND | EFX_FCNTL_GENERATE); + return (((ifm->ifm_media & IFM_ETH_RXPAUSE) ? EFX_FCNTL_RESPOND : 0) | + ((ifm->ifm_media & IFM_ETH_TXPAUSE) ? EFX_FCNTL_GENERATE : 0)); } static unsigned int @@ -150,13 +150,13 @@ static unsigned int sfxge_port_wanted_fc(struct sfxge_softc *sc) { - return sc->port.wanted_fc; + return (sc->port.wanted_fc); } static unsigned int sfxge_port_link_fc_ifm(struct sfxge_softc *sc) { - return 0; + return (0); } static int @@ -172,7 +172,7 @@ mtx_lock(&port->lock); - if (req->newptr) { + if (req->newptr != NULL) { if ((error = SYSCTL_IN(req, &fcntl, sizeof(fcntl))) != 0) goto out; @@ -235,7 +235,7 @@ { struct sfxge_port *port; int link_state; - + port = &sc->port; if (port->link_mode == mode) @@ -289,7 +289,7 @@ /* Set promisc-unicast and broadcast filter bits */ if ((rc = efx_mac_filter_set(enp, !!(ifp->if_flags & IFF_PROMISC), B_TRUE)) != 0) - return rc; + return (rc); /* Set multicast hash filter */ if (ifp->if_flags & (IFF_PROMISC | IFF_ALLMULTI)) { @@ -311,7 +311,7 @@ } if_maddr_runlock(ifp); } - return efx_mac_hash_set(enp, bucket); + return (efx_mac_hash_set(enp, bucket)); } int @@ -336,7 +336,7 @@ else rc = 0; mtx_unlock(&port->lock); - return rc; + return (rc); } void @@ -413,7 +413,7 @@ /* Update MAC stats by DMA every second */ if ((rc = efx_mac_stats_periodic(enp, &port->mac_stats.dma_buf, - 1000, B_FALSE)) != 0) + 1000, B_FALSE)) != 0) goto fail2; if ((rc = efx_mac_drain(enp, B_FALSE)) != 0) @@ -435,7 +435,7 @@ (void)efx_mac_drain(enp, B_TRUE); fail3: (void)efx_mac_stats_periodic(enp, &port->mac_stats.dma_buf, - 0, B_FALSE); + 0, B_FALSE); fail2: efx_port_fini(sc->enp); fail: @@ -488,7 +488,7 @@ rc = ETIMEDOUT; out: mtx_unlock(&port->lock); - return rc; + return (rc); } static int @@ -499,11 +499,11 @@ int rc; if ((rc = sfxge_phy_stat_update(sc)) != 0) - return rc; + return (rc); - return SYSCTL_OUT(req, + return (SYSCTL_OUT(req, (uint32_t *)sc->port.phy_stats.decode_buf + id, - sizeof(uint32_t)); + sizeof(uint32_t))); } static void @@ -619,7 +619,7 @@ free(port->phy_stats.decode_buf, M_SFXGE); (void)mtx_destroy(&port->lock); port->sc = NULL; - return rc; + return (rc); } static int sfxge_link_mode[EFX_PHY_MEDIA_NTYPES][EFX_LINK_NMODES] = { @@ -697,9 +697,9 @@ rc = efx_phy_adv_cap_set(sc->enp, ifm->ifm_data); out: - sx_xunlock(&sc->softc_lock); + sx_xunlock(&sc->softc_lock); - return rc; + return (rc); } int sfxge_port_ifmedia_init(struct sfxge_softc *sc) @@ -788,7 +788,7 @@ best_mode_ifm = mode_ifm; } - if (best_mode_ifm) + if (best_mode_ifm != 0) ifmedia_set(&sc->media, best_mode_ifm); /* Now discard port state until interface is started. */ @@ -796,5 +796,5 @@ out2: efx_nic_fini(sc->enp); out: - return rc; + return (rc); } diff -r e7f6237a8d92 sys/dev/sfxge/sfxge_rx.c --- a/sys/dev/sfxge/sfxge_rx.c Thu Sep 25 12:25:30 2014 +0400 +++ b/sys/dev/sfxge/sfxge_rx.c Thu Sep 25 15:59:36 2014 +0400 @@ -54,8 +54,8 @@ #include "sfxge.h" #include "sfxge_rx.h" -#define RX_REFILL_THRESHOLD (EFX_RXQ_LIMIT(SFXGE_NDESCS) * 9 / 10) -#define RX_REFILL_THRESHOLD_2 (RX_REFILL_THRESHOLD / 2) +#define RX_REFILL_THRESHOLD (EFX_RXQ_LIMIT(SFXGE_NDESCS) * 9 / 10) +#define RX_REFILL_THRESHOLD_2 (RX_REFILL_THRESHOLD / 2) /* Size of the LRO hash table. Must be a power of 2. A larger table * means we can accelerate a larger number of streams. @@ -87,10 +87,10 @@ static int lro_loss_packets = 20; /* Flags for sfxge_lro_conn::l2_id; must not collide with EVL_VLID_MASK */ -#define SFXGE_LRO_L2_ID_VLAN 0x4000 -#define SFXGE_LRO_L2_ID_IPV6 0x8000 -#define SFXGE_LRO_CONN_IS_VLAN_ENCAP(c) ((c)->l2_id & SFXGE_LRO_L2_ID_VLAN) -#define SFXGE_LRO_CONN_IS_TCPIPV4(c) (!((c)->l2_id & SFXGE_LRO_L2_ID_IPV6)) +#define SFXGE_LRO_L2_ID_VLAN 0x4000 +#define SFXGE_LRO_L2_ID_IPV6 0x8000 +#define SFXGE_LRO_CONN_IS_VLAN_ENCAP(c) ((c)->l2_id & SFXGE_LRO_L2_ID_VLAN) +#define SFXGE_LRO_CONN_IS_TCPIPV4(c) (!((c)->l2_id & SFXGE_LRO_L2_ID_IPV6)) /* Compare IPv6 addresses, avoiding conditional branches */ static __inline unsigned long ipv6_addr_cmp(const struct in6_addr *left, @@ -179,12 +179,12 @@ m = (struct mbuf *)uma_zalloc_arg(zone_mbuf, &args, M_NOWAIT); /* Allocate (and attach) packet buffer */ - if (m && !uma_zalloc_arg(sc->rx_buffer_zone, m, M_NOWAIT)) { + if (m != NULL && !uma_zalloc_arg(sc->rx_buffer_zone, m, M_NOWAIT)) { uma_zfree(zone_mbuf, m); m = NULL; } - return m; + return (m); } #define SFXGE_REFILL_BATCH 64 @@ -370,7 +370,7 @@ KASSERT(!c->mbuf, ("found orphaned mbuf")); - if (c->next_buf.mbuf) { + if (c->next_buf.mbuf != NULL) { sfxge_rx_deliver(rxq->sc, &c->next_buf); LIST_REMOVE(c, active_link); } @@ -510,7 +510,7 @@ if (__predict_false(th_seq != c->next_seq)) { /* Out-of-order, so start counting again. */ - if (c->mbuf) + if (c->mbuf != NULL) sfxge_lro_deliver(&rxq->lro, c); c->n_in_order_pkts -= lro_loss_packets; c->next_seq = th_seq + data_length; @@ -522,10 +522,10 @@ now = ticks; if (now - c->last_pkt_ticks > lro_idle_ticks) { ++rxq->lro.n_drop_idle; - if (c->mbuf) + if (c->mbuf != NULL) sfxge_lro_deliver(&rxq->lro, c); sfxge_lro_drop(rxq, c); - return 0; + return (0); } c->last_pkt_ticks = ticks; @@ -537,12 +537,12 @@ } if (__predict_false(dont_merge)) { - if (c->mbuf) + if (c->mbuf != NULL) sfxge_lro_deliver(&rxq->lro, c); if (th->th_flags & (TH_FIN | TH_RST)) { ++rxq->lro.n_drop_closed; sfxge_lro_drop(rxq, c); - return 0; + return (0); } goto deliver_buf_out; } @@ -563,11 +563,11 @@ } rx_buf->mbuf = NULL; - return 1; + return (1); deliver_buf_out: sfxge_rx_deliver(rxq->sc, rx_buf); - return 1; + return (1); } static void sfxge_lro_new_conn(struct sfxge_lro_state *st, uint32_t conn_hash, @@ -621,7 +621,7 @@ struct sfxge_lro_conn *c; uint16_t l2_id; uint16_t l3_proto; - void *nh; + void *nh; struct tcphdr *th; uint32_t conn_hash; unsigned bucket; @@ -671,7 +671,7 @@ continue; if ((c->source - th->th_sport) | (c->dest - th->th_dport)) continue; - if (c->mbuf) { + if (c->mbuf != NULL) { if (SFXGE_LRO_CONN_IS_TCPIPV4(c)) { struct ip *c_iph, *iph = nh; c_iph = c->nh; @@ -691,7 +691,7 @@ TAILQ_REMOVE(&rxq->lro.conns[bucket], c, link); TAILQ_INSERT_HEAD(&rxq->lro.conns[bucket], c, link); - if (c->next_buf.mbuf) { + if (c->next_buf.mbuf != NULL) { if (!sfxge_lro_try_merge(rxq, c)) goto deliver_now; } else { @@ -720,10 +720,10 @@ while (!LIST_EMPTY(&st->active_conns)) { c = LIST_FIRST(&st->active_conns); - if (!c->delivered && c->mbuf) + if (!c->delivered && c->mbuf != NULL) sfxge_lro_deliver(st, c); if (sfxge_lro_try_merge(rxq, c)) { - if (c->mbuf) + if (c->mbuf != NULL) sfxge_lro_deliver(st, c); LIST_REMOVE(c, active_link); } @@ -836,7 +836,7 @@ evq = sc->evq[index]; mtx_lock(&evq->lock); - + KASSERT(rxq->init_state == SFXGE_RXQ_STARTED, ("rxq not started")); @@ -881,7 +881,7 @@ rxq->loopback = 0; /* Destroy the common code receive queue. */ - efx_rx_qdestroy(rxq->common); + efx_rx_qdestroy(rxq->common); efx_sram_buf_tbl_clear(sc->enp, rxq->buf_base_id, EFX_RXQ_NBUFS(SFXGE_NDESCS)); @@ -1136,7 +1136,7 @@ const char *name; size_t offset; } sfxge_rx_stats[] = { -#define SFXGE_RX_STAT(name, member) \ +#define SFXGE_RX_STAT(name, member) \ { #name, offsetof(struct sfxge_rxq, member) } SFXGE_RX_STAT(lro_merges, lro.n_merges), SFXGE_RX_STAT(lro_bursts, lro.n_bursts), @@ -1161,7 +1161,7 @@ sum += *(unsigned int *)((caddr_t)sc->rxq[index] + sfxge_rx_stats[id].offset); - return SYSCTL_OUT(req, &sum, sizeof(sum)); + return (SYSCTL_OUT(req, &sum, sizeof(sum))); } static void diff -r e7f6237a8d92 sys/dev/sfxge/sfxge_rx.h --- a/sys/dev/sfxge/sfxge_rx.h Thu Sep 25 12:25:30 2014 +0400 +++ b/sys/dev/sfxge/sfxge_rx.h Thu Sep 25 15:59:36 2014 +0400 @@ -30,25 +30,25 @@ */ #ifndef _SFXGE_RX_H -#define _SFXGE_RX_H +#define _SFXGE_RX_H -#define SFXGE_MAGIC_RESERVED 0x8000 +#define SFXGE_MAGIC_RESERVED 0x8000 -#define SFXGE_MAGIC_DMAQ_LABEL_WIDTH 6 -#define SFXGE_MAGIC_DMAQ_LABEL_MASK \ - ((1 << SFXGE_MAGIC_DMAQ_LABEL_WIDTH) - 1) +#define SFXGE_MAGIC_DMAQ_LABEL_WIDTH 6 +#define SFXGE_MAGIC_DMAQ_LABEL_MASK \ + ((1 << SFXGE_MAGIC_DMAQ_LABEL_WIDTH) - 1) -#define SFXGE_MAGIC_RX_QFLUSH_DONE \ - (SFXGE_MAGIC_RESERVED | (1 << SFXGE_MAGIC_DMAQ_LABEL_WIDTH)) +#define SFXGE_MAGIC_RX_QFLUSH_DONE \ + (SFXGE_MAGIC_RESERVED | (1 << SFXGE_MAGIC_DMAQ_LABEL_WIDTH)) -#define SFXGE_MAGIC_RX_QFLUSH_FAILED \ - (SFXGE_MAGIC_RESERVED | (2 << SFXGE_MAGIC_DMAQ_LABEL_WIDTH)) +#define SFXGE_MAGIC_RX_QFLUSH_FAILED \ + (SFXGE_MAGIC_RESERVED | (2 << SFXGE_MAGIC_DMAQ_LABEL_WIDTH)) -#define SFXGE_MAGIC_RX_QREFILL \ - (SFXGE_MAGIC_RESERVED | (3 << SFXGE_MAGIC_DMAQ_LABEL_WIDTH)) +#define SFXGE_MAGIC_RX_QREFILL \ + (SFXGE_MAGIC_RESERVED | (3 << SFXGE_MAGIC_DMAQ_LABEL_WIDTH)) -#define SFXGE_MAGIC_TX_QFLUSH_DONE \ - (SFXGE_MAGIC_RESERVED | (4 << SFXGE_MAGIC_DMAQ_LABEL_WIDTH)) +#define SFXGE_MAGIC_TX_QFLUSH_DONE \ + (SFXGE_MAGIC_RESERVED | (4 << SFXGE_MAGIC_DMAQ_LABEL_WIDTH)) #define SFXGE_RX_SCALE_MAX EFX_MAXRSS diff -r e7f6237a8d92 sys/dev/sfxge/sfxge_tx.c --- a/sys/dev/sfxge/sfxge_tx.c Thu Sep 25 12:25:30 2014 +0400 +++ b/sys/dev/sfxge/sfxge_tx.c Thu Sep 25 15:59:36 2014 +0400 @@ -74,8 +74,8 @@ * the output at a packet boundary. Allow for a reasonable * minimum MSS of 512. */ -#define SFXGE_TSO_MAX_DESC ((65535 / 512) * 2 + SFXGE_TX_MAPPING_MAX_SEG - 1) -#define SFXGE_TXQ_BLOCK_LEVEL (SFXGE_NDESCS - SFXGE_TSO_MAX_DESC) +#define SFXGE_TSO_MAX_DESC ((65535 / 512) * 2 + SFXGE_TX_MAPPING_MAX_SEG - 1) +#define SFXGE_TXQ_BLOCK_LEVEL (SFXGE_NDESCS - SFXGE_TSO_MAX_DESC) /* Forward declarations. */ static inline void sfxge_tx_qdpl_service(struct sfxge_txq *txq); @@ -343,7 +343,7 @@ /* Post the fragment list. */ sfxge_tx_qlist_post(txq); - return 0; + return (0); reject_mapped: bus_dmamap_unload(txq->packet_dma_tag, *used_map); @@ -352,7 +352,7 @@ m_freem(mbuf); ++txq->drops; - return rc; + return (rc); } #ifdef SFXGE_HAVE_MQ @@ -426,8 +426,8 @@ ("queue unblocked but count is non-zero")); } -#define SFXGE_TX_QDPL_PENDING(_txq) \ - ((_txq)->dpl.std_put != 0) +#define SFXGE_TX_QDPL_PENDING(_txq) \ + ((_txq)->dpl.std_put != 0) /* * Service the deferred packet list. @@ -493,7 +493,7 @@ do { old = *putp; - if (old) { + if (old != 0) { struct mbuf *mp = (struct mbuf *)old; old_len = mp->m_pkthdr.csum_data; } else @@ -559,7 +559,6 @@ m_freem(m); atomic_add_long(&txq->early_drops, 1); return (rc); - } static void @@ -577,7 +576,7 @@ } stdp->std_get = NULL; stdp->std_count = 0; - stdp->std_getp = &stdp->std_get; + stdp->std_getp = &stdp->std_get; mtx_unlock(&txq->lock); } @@ -599,7 +598,7 @@ */ int sfxge_if_transmit(struct ifnet *ifp, struct mbuf *m) -{ +{ struct sfxge_softc *sc; struct sfxge_txq *txq; int rc; @@ -652,7 +651,7 @@ } while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { - IFQ_DRV_DEQUEUE(&ifp->if_snd, mbuf); + IFQ_DRV_DEQUEUE(&ifp->if_snd, mbuf); if (mbuf == NULL) break; @@ -757,15 +756,15 @@ /* Size of preallocated TSO header buffers. Larger blocks must be * allocated from the heap. */ -#define TSOH_STD_SIZE 128 +#define TSOH_STD_SIZE 128 /* At most half the descriptors in the queue at any time will refer to * a TSO header buffer, since they must always be followed by a * payload descriptor referring to an mbuf. */ -#define TSOH_COUNT (SFXGE_NDESCS / 2u) -#define TSOH_PER_PAGE (PAGE_SIZE / TSOH_STD_SIZE) -#define TSOH_PAGE_COUNT ((TSOH_COUNT + TSOH_PER_PAGE - 1) / TSOH_PER_PAGE) +#define TSOH_COUNT (SFXGE_NDESCS / 2u) +#define TSOH_PER_PAGE (PAGE_SIZE / TSOH_STD_SIZE) +#define TSOH_PAGE_COUNT ((TSOH_COUNT + TSOH_PER_PAGE - 1) / TSOH_PER_PAGE) static int tso_init(struct sfxge_txq *txq) { @@ -778,25 +777,25 @@ for (i = 0; i < TSOH_PAGE_COUNT; i++) { rc = sfxge_dma_alloc(sc, PAGE_SIZE, &txq->tsoh_buffer[i]); - if (rc) + if (rc != 0) goto fail; } - return 0; + return (0); fail: while (i-- > 0) sfxge_dma_free(&txq->tsoh_buffer[i]); free(txq->tsoh_buffer, M_SFXGE); txq->tsoh_buffer = NULL; - return rc; + return (rc); } static void tso_fini(struct sfxge_txq *txq) { int i; - if (txq->tsoh_buffer) { + if (txq->tsoh_buffer != NULL) { for (i = 0; i < TSOH_PAGE_COUNT; i++) sfxge_dma_free(&txq->tsoh_buffer[i]); free(txq->tsoh_buffer, M_SFXGE); @@ -925,7 +924,7 @@ /* We cannot use bus_dmamem_alloc() as that may sleep */ header = malloc(tso->header_len, M_SFXGE, M_NOWAIT); if (__predict_false(!header)) - return ENOMEM; + return (ENOMEM); rc = bus_dmamap_load(txq->packet_dma_tag, stmp->map, header, tso->header_len, tso_map_long_header, &dma_addr, @@ -938,7 +937,7 @@ rc = EINVAL; } free(header, M_SFXGE); - return rc; + return (rc); } map = stmp->map; @@ -987,7 +986,7 @@ desc->eb_size = tso->header_len; desc->eb_eop = 0; - return 0; + return (0); } static int @@ -1048,7 +1047,7 @@ } txq->tso_bursts++; - return id; + return (id); } static void @@ -1200,7 +1199,7 @@ goto fail; mtx_lock(SFXGE_TXQ_LOCK(txq)); - + /* Enable the transmit queue. */ efx_tx_qenable(txq->common); @@ -1229,7 +1228,7 @@ sfxge_tx_qstop(sc, SFXGE_TXQ_IP_CKSUM); encp = efx_nic_cfg_get(sc->enp); - sfxge_tx_qstop(sc, SFXGE_TXQ_NON_CKSUM); + sfxge_tx_qstop(sc, SFXGE_TXQ_NON_CKSUM); /* Tear down the transmit module */ efx_tx_fini(sc->enp); @@ -1266,7 +1265,7 @@ sfxge_tx_qstop(sc, SFXGE_TXQ_IP_CKSUM); fail2: - sfxge_tx_qstop(sc, SFXGE_TXQ_NON_CKSUM); + sfxge_tx_qstop(sc, SFXGE_TXQ_NON_CKSUM); fail: efx_tx_fini(sc->enp); @@ -1293,7 +1292,7 @@ /* Free the context arrays. */ free(txq->pend_desc, M_SFXGE); - while (nmaps--) + while (nmaps-- != 0) bus_dmamap_destroy(txq->packet_dma_tag, txq->stmp[nmaps].map); free(txq->stmp, M_SFXGE); @@ -1385,7 +1384,7 @@ fail3: free(txq->pend_desc, M_SFXGE); fail2: - while (nmaps--) + while (nmaps-- != 0) bus_dmamap_destroy(txq->packet_dma_tag, txq->stmp[nmaps].map); free(txq->stmp, M_SFXGE); bus_dma_tag_destroy(txq->packet_dma_tag); @@ -1400,7 +1399,7 @@ const char *name; size_t offset; } sfxge_tx_stats[] = { -#define SFXGE_TX_STAT(name, member) \ +#define SFXGE_TX_STAT(name, member) \ { #name, offsetof(struct sfxge_txq, member) } SFXGE_TX_STAT(tso_bursts, tso_bursts), SFXGE_TX_STAT(tso_packets, tso_packets), @@ -1426,7 +1425,7 @@ sum += *(unsigned long *)((caddr_t)sc->txq[index] + sfxge_tx_stats[id].offset); - return SYSCTL_OUT(req, &sum, sizeof(sum)); + return (SYSCTL_OUT(req, &sum, sizeof(sum))); } static void @@ -1460,7 +1459,7 @@ sfxge_tx_qfini(sc, SFXGE_TXQ_IP_TCP_UDP_CKSUM + index); sfxge_tx_qfini(sc, SFXGE_TXQ_IP_CKSUM); - sfxge_tx_qfini(sc, SFXGE_TXQ_NON_CKSUM); + sfxge_tx_qfini(sc, SFXGE_TXQ_NON_CKSUM); } diff -r e7f6237a8d92 sys/dev/sfxge/sfxge_tx.h --- a/sys/dev/sfxge/sfxge_tx.h Thu Sep 25 12:25:30 2014 +0400 +++ b/sys/dev/sfxge/sfxge_tx.h Thu Sep 25 15:59:36 2014 +0400 @@ -30,7 +30,7 @@ */ #ifndef _SFXGE_TX_H -#define _SFXGE_TX_H +#define _SFXGE_TX_H #include #include @@ -47,7 +47,7 @@ * could overlap all mbufs in the chain and also require an extra * segment for a TSO header. */ -#define SFXGE_TX_PACKET_MAX_SEG (SFXGE_TX_MAPPING_MAX_SEG + 1) +#define SFXGE_TX_PACKET_MAX_SEG (SFXGE_TX_MAPPING_MAX_SEG + 1) /* * Buffer mapping flags. @@ -111,11 +111,11 @@ #define SFXGE_TX_BATCH 64 #ifdef SFXGE_HAVE_MQ -#define SFXGE_TXQ_LOCK(txq) (&(txq)->lock) -#define SFXGE_TX_SCALE(sc) ((sc)->intr.n_alloc) +#define SFXGE_TXQ_LOCK(txq) (&(txq)->lock) +#define SFXGE_TX_SCALE(sc) ((sc)->intr.n_alloc) #else -#define SFXGE_TXQ_LOCK(txq) (&(txq)->sc->tx_lock) -#define SFXGE_TX_SCALE(sc) 1 +#define SFXGE_TXQ_LOCK(txq) (&(txq)->sc->tx_lock) +#define SFXGE_TX_SCALE(sc) 1 #endif struct sfxge_txq { --------------000900020605040502010202-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 25 13:19:55 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C444BFB2 for ; Thu, 25 Sep 2014 13:19:55 +0000 (UTC) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::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 5F642C10 for ; Thu, 25 Sep 2014 13:19:55 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id fb4so8918975wid.13 for ; Thu, 25 Sep 2014 06:19:53 -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=IysgEbLJx0vdNWGao9wvJm/cgAv3pMF2uoXprUtBq2o=; b=yzDg3KMUhUkirdmcoOE/5F/TmthLSUqv03Ya8mwE/GolOUaKZjJpEO/YU+bzqCd+HS qq+36jv4XeGvWu8XkrCWycDhCTy/Ph/PBS3cJRYtC+YqAnTVx/RZG7Xjz3GK30nuZ5tZ Xqh2okN7ZxZgtQDOUZcrs4Fd28GSbykoGTdwhtXf3C+l084/5nR3/ZgaMObayThN2S1P 5YwxLc+RNBuNY4JHjLq4waMoHEbVurxLzs3MBAoU7J1KtWmPE9Gi9wWQEgTKfENOGMfG PxuK6Kghl2c9zdL20zs7rqFhr/G0qbywE17kM9xDsBDQb7wSqGM4iXwXIyLDpwAkUmTL zG6Q== MIME-Version: 1.0 X-Received: by 10.194.119.9 with SMTP id kq9mr15374646wjb.25.1411651193703; Thu, 25 Sep 2014 06:19:53 -0700 (PDT) Received: by 10.27.129.67 with HTTP; Thu, 25 Sep 2014 06:19:53 -0700 (PDT) Date: Thu, 25 Sep 2014 16:19:53 +0300 Message-ID: Subject: [patch] netmap not building From: Daniel Peyrolon To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary=089e0118451ef2b34d0503e3a7fe 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, 25 Sep 2014 13:19:55 -0000 --089e0118451ef2b34d0503e3a7fe Content-Type: text/plain; charset=ISO-8859-1 Hello everyone, I've tried to build netmap on CURRENT, and to my surprise, I couldn't load the module. Thanks to Sean, I managed to find the cause. One file from the netmap code was not included as SRC. Patch attached. -- Daniel --089e0118451ef2b34d0503e3a7fe Content-Type: application/octet-stream; name=patchnetmap Content-Disposition: attachment; filename=patchnetmap Content-Transfer-Encoding: base64 X-Attachment-Id: f_i0i0cxx10 SW5kZXg6IHN5cy9tb2R1bGVzL25ldG1hcC9NYWtlZmlsZQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbW9k dWxlcy9uZXRtYXAvTWFrZWZpbGUJKHJldmlzaW9uIDI3MjA5NCkKKysrIHN5cy9tb2R1bGVzL25l dG1hcC9NYWtlZmlsZQkod29ya2luZyBjb3B5KQpAQCAtMTYsNSArMTYsNiBAQAogU1JDUwkrPSBu ZXRtYXBfZnJlZWJzZC5jCiBTUkNTCSs9IG5ldG1hcF9vZmZsb2FkaW5ncy5jCiBTUkNTCSs9IG5l dG1hcF9waXBlLmMKK1NSQ1MJKz0gbmV0bWFwX21vbml0b3IuYwogCiAuaW5jbHVkZSA8YnNkLmtt b2QubWs+Cg== --089e0118451ef2b34d0503e3a7fe-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 25 13:20:31 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 58E8EBD for ; Thu, 25 Sep 2014 13:20:31 +0000 (UTC) Received: from nbfkord-smmo01.seg.att.com (nbfkord-smmo01.seg.att.com [209.65.160.76]) (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 E9873C1F for ; Thu, 25 Sep 2014 13:20:30 +0000 (UTC) Received: from unknown [12.187.104.25] (EHLO webmail.solarflare.com) by nbfkord-smmo01.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id e9614245.2b423c81c940.6677.00-2491.13274.nbfkord-smmo01.seg.att.com (envelope-from ); Thu, 25 Sep 2014 13:20:30 +0000 (UTC) X-MXL-Hash: 5424169e623d36b7-de355a2bce70c77e5cf94d4da26b7039320068a4 Received: from unknown [12.187.104.25] (EHLO webmail.solarflare.com) by nbfkord-smmo01.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 67514245.0.5342.00-2363.10640.nbfkord-smmo01.seg.att.com (envelope-from ); Thu, 25 Sep 2014 13:15:35 +0000 (UTC) X-MXL-Hash: 542415772b0b65b6-4f8496eaa1e03e79e3bafb3e895634611c429835 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; Thu, 25 Sep 2014 06:14:57 -0700 Message-ID: <54241572.6000702@solarflare.com> Date: Thu, 25 Sep 2014 17:15:30 +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: [PATCH 4/4] sfxge: Support tunable to control Tx deferred packet list limits Content-Type: multipart/mixed; boundary="------------080104050708050209000103" X-Originating-IP: [84.52.89.52] X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-20974.005 X-TM-AS-Result: No--7.088200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-AnalysisOut: [v=2.0 cv=bdHcppzB c=1 sm=1 a=MkjXnYnS3dyNWGSWLXxFFQ==:17 a] X-AnalysisOut: [=Ozv50jBIw7UA:10 a=o_jm4JFojFsA:10 a=1UGWc0DeibYA:10 a=4ox] X-AnalysisOut: [owH2qkH0A:10 a=RB3BGLmKESwA:10 a=BLceEmwcHowA:10 a=zRKbQ67] X-AnalysisOut: [AAAAA:8 a=qg_zykTt5_OaQZwxDF0A:9 a=wPNLvfGTeEIA:10 a=mTkGQ] X-AnalysisOut: [3Rq-wFmDC5QAsQA:9 a=QEXdDO2ut3YA:10 a=s9qa1pk-s7gA:10 a=ax] X-AnalysisOut: [CjAnoL7aCeYB5-:21 a=Std5G_GjueEGEdi_:21] 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: Thu, 25 Sep 2014 13:20:31 -0000 --------------080104050708050209000103 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable 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 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. --------------080104050708050209000103 Content-Type: text/plain; charset="UTF-8"; name="dpl_max" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dpl_max" 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. Submitted by: Andrew Rybchenko Sponsored by: Solarflare Communications, Inc. diff -r 0c812cd721d6 sys/dev/sfxge/sfxge_tx.c --- a/sys/dev/sfxge/sfxge_tx.c Thu Sep 25 16:06:49 2014 +0400 +++ b/sys/dev/sfxge/sfxge_tx.c Thu Sep 25 16:06:56 2014 +0400 @@ -50,6 +50,7 @@ #include #include #include +#include #include #include @@ -77,6 +78,25 @@ #define SFXGE_TSO_MAX_DESC ((65535 / 512) * 2 + SFXGE_TX_MAPPING_MAX_SEG - 1) #define SFXGE_TXQ_BLOCK_LEVEL(_entries) ((_entries) - SFXGE_TSO_MAX_DESC) +#ifdef SFXGE_HAVE_MQ + +#define SFXGE_PARAM_TX_DPL_GET_MAX SFXGE_PARAM(tx_dpl_get_max) +static int sfxge_tx_dpl_get_max = SFXGE_TX_DPL_GET_PKT_LIMIT_DEFAULT; +TUNABLE_INT(SFXGE_PARAM_TX_DPL_GET_MAX, &sfxge_tx_dpl_get_max); +SYSCTL_INT(_hw_sfxge, OID_AUTO, tx_dpl_get_max, CTLFLAG_RDTUN, + &sfxge_tx_dpl_get_max, 0, + "Maximum number of packets in deferred packet get-list"); + +#define SFXGE_PARAM_TX_DPL_PUT_MAX SFXGE_PARAM(tx_dpl_put_max) +static int sfxge_tx_dpl_put_max = SFXGE_TX_DPL_PUT_PKT_LIMIT_DEFAULT; +TUNABLE_INT(SFXGE_PARAM_TX_DPL_PUT_MAX, &sfxge_tx_dpl_put_max); +SYSCTL_INT(_hw_sfxge, OID_AUTO, tx_dpl_put_max, CTLFLAG_RDTUN, + &sfxge_tx_dpl_put_max, 0, + "Maximum number of packets in deferred packet put-list"); + +#endif + + /* Forward declarations. */ static inline void sfxge_tx_qdpl_service(struct sfxge_txq *txq); static void sfxge_tx_qlist_post(struct sfxge_txq *txq); @@ -476,7 +496,7 @@ sfxge_tx_qdpl_swizzle(txq); - if (stdp->std_get_count >= SFXGE_TX_DPL_GET_PKT_LIMIT_DEFAULT) + if (stdp->std_get_count >= stdp->std_get_max) return (ENOBUFS); *(stdp->std_getp) = mbuf; @@ -498,7 +518,7 @@ old_len = mp->m_pkthdr.csum_data; } else old_len = 0; - if (old_len >= SFXGE_TX_DPL_PUT_PKT_LIMIT_DEFAULT) + if (old_len >= stdp->std_put_max) return (ENOBUFS); mbuf->m_pkthdr.csum_data = old_len + 1; mbuf->m_nextpkt = (void *)old; @@ -1384,8 +1404,23 @@ goto fail3; #ifdef SFXGE_HAVE_MQ + if (sfxge_tx_dpl_get_max <= 0) { + log(LOG_ERR, "%s=%d must be greater than 0", + SFXGE_PARAM_TX_DPL_GET_MAX, sfxge_tx_dpl_get_max); + rc = EINVAL; + goto fail_tx_dpl_get_max; + } + if (sfxge_tx_dpl_put_max < 0) { + log(LOG_ERR, "%s=%d must be greater or equal to 0", + SFXGE_PARAM_TX_DPL_PUT_MAX, sfxge_tx_dpl_put_max); + rc = EINVAL; + goto fail_tx_dpl_put_max; + } + /* Initialize the deferred packet list. */ stdp = &txq->dpl; + stdp->std_put_max = sfxge_tx_dpl_put_max; + stdp->std_get_max = sfxge_tx_dpl_get_max; stdp->std_getp = &stdp->std_get; mtx_init(&txq->lock, "txq", NULL, MTX_DEF); @@ -1403,6 +1438,8 @@ return (0); +fail_tx_dpl_put_max: +fail_tx_dpl_get_max: fail3: fail_txq_node: free(txq->pend_desc, M_SFXGE); diff -r 0c812cd721d6 sys/dev/sfxge/sfxge_tx.h --- a/sys/dev/sfxge/sfxge_tx.h Thu Sep 25 16:06:49 2014 +0400 +++ b/sys/dev/sfxge/sfxge_tx.h Thu Sep 25 16:06:56 2014 +0400 @@ -75,13 +75,17 @@ enum sfxge_tx_buf_flags flags; }; -#define SFXGE_TX_DPL_GET_PKT_LIMIT_DEFAULT 64 +#define SFXGE_TX_DPL_GET_PKT_LIMIT_DEFAULT 1024 #define SFXGE_TX_DPL_PUT_PKT_LIMIT_DEFAULT 64 /* * Deferred packet list. */ struct sfxge_tx_dpl { + unsigned int std_get_max; /* Maximum number of packets + * in get list */ + unsigned int std_put_max; /* Maximum number of packets + * in put list */ uintptr_t std_put; /* Head of put list. */ struct mbuf *std_get; /* Head of get list. */ struct mbuf **std_getp; /* Tail of get list. */ --------------080104050708050209000103-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 25 13:58:46 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 773AAC36; Thu, 25 Sep 2014 13:58:46 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 110C32D8B; Thu, 25 Sep 2014 13:58:44 +0000 (UTC) Message-ID: <54241F1D.4080206@FreeBSD.org> Date: Thu, 25 Sep 2014 17:56:45 +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: sbruno@freebsd.org, Gleb Smirnoff Subject: Re: svn commit: r272089 - head/sys/netpfil/ipfw References: <201409250226.s8P2Q6AS055635@svn.freebsd.org> <20140925051808.GS884@FreeBSD.org> <1411643223.2161.2.camel@bruno> In-Reply-To: <1411643223.2161.2.camel@bruno> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Adrian Chadd , David Carlier 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, 25 Sep 2014 13:58:46 -0000 On 25.09.2014 15:07, Sean Bruno wrote: > On Thu, 2014-09-25 at 09:18 +0400, Gleb Smirnoff wrote: >> On Wed, Sep 24, 2014 at 07:40:23PM -0700, Adrian Chadd wrote: >> A> Hm, I saw this from Kate on IRC. Did anyone figure out _where_ these >> A> frames are coming from? >> A> >> A> Just dropping them is cool, but I'd really like to see the contents of >> A> the frames and what their origin is. >> A> >> A> I'm worried that they're valid stack-generated frames.. >> >> I agree on this. Fixing NULL pointer derefs with NULL check is not >> always a right thing to do. >> A> > >> A> > Log: >> A> > Fix NULL pointer deref in ipfw when using dummynet at layer 2. >> A> > Drop packet if pkg->ifp is NULL, which is the case here. >> A> > >> A> > ref. https://github.com/HardenedBSD/hardenedBSD >> A> > commit 4eef3881c64f6e3aa38eebbeaf27a947a5d47dd7 >> A> > >> A> > PR 193861 -- DUMMYNET LAYER2: kernel panic >> A> > >> A> > in this case a kernel panic occurs. Hence, when we do not get an interface, >> A> > we just drop the packet in question. > Ok, moving off to freebsd-net. How should we proceded with debugging > further? Probably this can occurs when outgoing interface disappeared (netgrapg/tun/tap/lagg/vlan/usb ethernet), but packets were not send yet (delayed in the dummynet pipe). I think this is well known problem. -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Thu Sep 25 14:25:55 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CBEF4A35 for ; Thu, 25 Sep 2014 14:25:55 +0000 (UTC) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010: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 53350647 for ; Thu, 25 Sep 2014 14:25:55 +0000 (UTC) Received: by mail-la0-f53.google.com with SMTP id ty20so172150lab.40 for ; Thu, 25 Sep 2014 07:25:53 -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=1wdxk+NlgQlX9V+MPB0btiHXJsyusnlIoBM9sh8QLKQ=; b=RkTlrCWcN4IqescRuyzU3RQNjjl+v2zZG09TlL+EgvKsZnIg3eycrRAmgn0gcqe8tU sJdb4hwyhRbC07/cJnaRfrCctBtMvjsltBdVR/oVedlWOVptcjG/MkVImluZCZtKdzkS Xhw4hch+zkxPqbYYP9C1InMlFGYplhcQqnlCXdzCGdaR1bPGE0FFepIJkAzcmT09c9oH xTl3s93o1+Ihv/SO+4+jikJKHJaI298W8iPLbE8Zk3Kv7BWbYvMtnMulcuPOevQp0+zm gaccOwJ8Eo10Uey3uJ146AJMGKGm4O9IpcQUOWiIBpPrUzfxLnHQQG7oyILdFxRvoAsz OLcQ== MIME-Version: 1.0 X-Received: by 10.152.42.136 with SMTP id o8mr13629158lal.71.1411655153180; Thu, 25 Sep 2014 07:25:53 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.26.37 with HTTP; Thu, 25 Sep 2014 07:25:53 -0700 (PDT) In-Reply-To: References: Date: Thu, 25 Sep 2014 16:25:53 +0200 X-Google-Sender-Auth: TVtvv3VxHlBJxGfvrJchZa4k-ss Message-ID: Subject: Re: [patch] netmap not building From: Luigi Rizzo To: Daniel Peyrolon 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: Thu, 25 Sep 2014 14:25:56 -0000 thanks, committed in r272108 On Thu, Sep 25, 2014 at 3:19 PM, Daniel Peyrolon wrote: > Hello everyone, I've tried to build netmap on CURRENT, and to my surprise, > I couldn't load the module. > > Thanks to Sean, I managed to find the cause. One file from the netmap code > was not included as SRC. > Patch attached. > > -- > Daniel > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- -----------------------------------------+------------------------------- 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 Thu Sep 25 16:09:08 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F34FC77; Thu, 25 Sep 2014 16:09:08 +0000 (UTC) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450: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 9FA5775E; Thu, 25 Sep 2014 16:09:07 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id w61so6358827wes.40 for ; Thu, 25 Sep 2014 09:09: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=FC8aowtlak0Zxn+HWv8Lzpm4Bvki/6Bm4O8FHCFDkTk=; b=O5+VqhWmHHIHAOu9WVDwNFJRgoiM6ASVe1AGVMDDtuqTUkUulDvF96Yiakz38hsP39 ipXWOhk38fDZybsS50viVUffgK6GX5PIA1bZWrrg0JpmTtmuaaHx87b6v/oenbcpVtNq JzViJ8CUQlODRKAwvNejLeCBrDNUqfnHIPpiGfSzu0oc6+xt5vPPDx0+qovkyUGSSu6a 29nrRpavu7i6vRePAFBCa9QYWDNdViPW1DK8peKbcxG4AJFzGKws5tEkaN097cOV8xwf BeiFMPouFPcROQnU23RO2ORRNcgYt7izetjyNHtZXjqb1lShtOpF5eyE9ui4I3RzkEtm IyjQ== MIME-Version: 1.0 X-Received: by 10.180.101.129 with SMTP id fg1mr39434672wib.20.1411661345737; Thu, 25 Sep 2014 09:09:05 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Thu, 25 Sep 2014 09:09:05 -0700 (PDT) In-Reply-To: <54241F1D.4080206@FreeBSD.org> References: <201409250226.s8P2Q6AS055635@svn.freebsd.org> <20140925051808.GS884@FreeBSD.org> <1411643223.2161.2.camel@bruno> <54241F1D.4080206@FreeBSD.org> Date: Thu, 25 Sep 2014 09:09:05 -0700 X-Google-Sender-Auth: mybqyIsQgCd0GGgNlb1cH3PFMu0 Message-ID: Subject: Re: svn commit: r272089 - head/sys/netpfil/ipfw From: Adrian Chadd To: "Andrey V. Elsukov" Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net , David Carlier 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, 25 Sep 2014 16:09:08 -0000 Right, but I want to know if this is the case or not. I don't recall kate actually saying she had dynamically added/deleted interfaces. So - please at least put an m_print() or whatever that is in there, trigger the bug and inspect the frame. My hunch is something like "arp"... -a From owner-freebsd-net@FreeBSD.ORG Thu Sep 25 18:56: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31A2CBAA for ; Thu, 25 Sep 2014 18:56:25 +0000 (UTC) Received: from nm37-vm6.bullet.mail.ir2.yahoo.com (nm37-vm6.bullet.mail.ir2.yahoo.com [212.82.97.147]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9905EE9F for ; Thu, 25 Sep 2014 18:56:23 +0000 (UTC) Received: from [212.82.98.56] by nm37.bullet.mail.ir2.yahoo.com with NNFMP; 25 Sep 2014 18:53:52 -0000 Received: from [212.82.98.94] by tm9.bullet.mail.ir2.yahoo.com with NNFMP; 25 Sep 2014 18:53:52 -0000 Received: from [127.0.0.1] by omp1031.mail.ir2.yahoo.com with NNFMP; 25 Sep 2014 18:53:52 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 531638.99810.bm@omp1031.mail.ir2.yahoo.com Received: (qmail 37285 invoked by uid 60001); 25 Sep 2014 18:53:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1411671232; bh=8MTuDgMaJvMD3AOa17v0PvWtijhWIoZBfMlzfAk10eo=; h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=YjYyp1EHDkXfkeUQtw6o7uCWcnA1xhLyBTHXn2HvDso4VFZ2m4B1UjdM5cn1/Emmv4XLvqHskNVjmwRXwkadzb4bEzNjIpcOBNYKRIiknyHc3peizNw2Ek+iw6OgaebZZhpvctsd+q5lOuvf0nj8dpgJxrRDT0Dt5Vc9SUfLFRc= X-YMail-OSG: Xg3TPmwVM1k9d9HGiwZaij3Uf.UM4488bP23uhflKG9voaj vWf8sG3A22EOAw7guQY9yuIXRzVRVT7jbZnJJvZaKvoTcp7GOTfT2SItSQEa qEl46A9mgPAEfFg653S9USA79ftzo0w7NQKr8B3j8BgoC8jhSnX_iEtMpxXM Gk.RD9brDrSF40byjN2n0wNTfdtOcF8_PvRtwingfgJQ3noRs4I2olugrIqN uOGZHuf7u0hZnROly8seXRlWVDQZUtsWGVfYfmFRSKz0LzrX3YBXxzkh33ID KY5CD4mZowQs7.6MO32fUUfqT3etHIwfDwCVu3I.hcxEBp8avc6NQWXhgwpU D1ezbqkFiDhhrym.sTfPL9Zv1LF4khRopZgzzzwbP5G2oZO3Ab.jTI8uILRH YOna5mUwAi899sfWOy7jemRFS8X3XZD6dD4CV5gAp.eSH556hGUxHi2fXSTk FOXrCBuRqHNFl1lLmQZKuu9zAfkoR6qAsDyosyA3.RJohIQAk279PBeRbI0q 86qZTD91z1MTuuzoX_AIPYvQ0kwufhMJwPgB2xnMxeo557hN9WfMX4A-- Received: from [92.254.163.111] by web172805.mail.ir2.yahoo.com via HTTP; Thu, 25 Sep 2014 19:53:52 BST X-Rocket-MIMEInfo: 002.001, SGVsbG8sCgoKSSBoYXZlIGEgbmFzdHkgIHZsYW4gcHJvYmxlbSB0aGF0IHlvdSBtaWdodCBiZSBhYmxlIHRvIGhlbHA6CgpJIGhhdmUgdHdvIHNlcnZlcnMgY29ubmVjdCB0aG91Z2ggIGEgbWFydmVsIHN3aXRjaCAsIGluIG9uZSBvZiB0aGUgc2VydmVycyAKSSBhbSBydW5uaW5nIEZyZWVCU0QgOC4yLgoKRXZlcnl0aGluZyBpcyBmaW5lIHVudGlsIEkgZGVmaW5lIGEgdmxhbiBpbiBlYWNoIHNlcnZlcixJIGNhbiBkZWZpbmUgdGhlIHZsYW4gaW4gRmJzZCBzaWRlCmFuZCBhbGwgc3RpbGwgb2ssaG93IGV2ZXIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.696 Message-ID: <1411671232.29910.YahooMailNeo@web172805.mail.ir2.yahoo.com> Date: Thu, 25 Sep 2014 19:53:52 +0100 From: Tony Moseby Reply-To: Tony Moseby Subject: vlan problem To: "freebsd-net@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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: Thu, 25 Sep 2014 18:56:25 -0000 Hello,=0A=0A=0AI have a nasty vlan problem that you might be able to help:= =0A=0AI have two servers connect though a marvel switch , in one of the se= rvers =0AI am running FreeBSD 8.2.=0A=0AEverything is fine until I define a= vlan in each server,I can define the vlan in Fbsd side=0Aand all still ok,= how ever when I define the vlan in the non Fbsd server the communication = =0A=0Abetween the servers on the trunk/lan stops working.=0AHowever the lan= communication works fine.The trunk has 10.0.1.10(A server)and 10.0.1.11(B= server)=0A=0Aand the vlan 10.0.80.110 and 10.80.111 .=0AIf I ping from 1.0= .1.10(non Fbsd) to 10.0.1.11(Bsd) , I can see the icmp request going to Bsd= server=0Abut no answer coming back.=0AIf I ping from the Bsd server (1.0.1= .11) to 1.0.1.10 I can see the icmp reques coming to 1.0.1.10=0Aand I also= can see the answer arriving in 1.0.1.11, but nothing more happens.=0ALooks= like Fbsd can not handle this after the vlan been define in the non Fbsd s= erver.=0ASomeone understand this behavor?=0AThanks From owner-freebsd-net@FreeBSD.ORG Thu Sep 25 19:35:10 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10CCB9A8 for ; Thu, 25 Sep 2014 19:35:10 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::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 8EA83343 for ; Thu, 25 Sep 2014 19:35:09 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id 10so12500258lbg.38 for ; Thu, 25 Sep 2014 12:35: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=AxTCDLxhTaF+lVWzE8vYzLAfEN8skkW9FwGx7A5yMeU=; b=f/1/rjBx4IK259/+aBcF7RzdHAv9qq27Y84Jqs6C070iYd+m5XJuB6sGFN3JdWrBFw dL9XtMRPXx3NguynLFdxyokZu5nTTMh8uWh4rwpv/gl7cc8KeezwRPCzoYkwYsF+yTvV YnzKv33jxD6HispNhkIL7O14wkH7Bv5+enMK2OMvu7KWbpJOxcqgQMGM7XsZfuLbZ8b2 oSmfPFFkRKUldZKqlEQ8bfHXtE5UcjFpGB+iI4O1yV5ufGeAS1GB8OevrJ1VFWPydWQ3 oTTI/wbTVryNcwZx8HkHdGo5mP3039wX2gagL9WpTyF1kCXMs69pNzrmG95YO1sxtoeh wMTw== MIME-Version: 1.0 X-Received: by 10.152.163.66 with SMTP id yg2mr15563324lab.38.1411673707541; Thu, 25 Sep 2014 12:35:07 -0700 (PDT) Received: by 10.25.21.166 with HTTP; Thu, 25 Sep 2014 12:35:07 -0700 (PDT) In-Reply-To: <1411671232.29910.YahooMailNeo@web172805.mail.ir2.yahoo.com> References: <1411671232.29910.YahooMailNeo@web172805.mail.ir2.yahoo.com> Date: Thu, 25 Sep 2014 15:35:07 -0400 Message-ID: Subject: Re: vlan problem From: Ryan Stone To: Tony Moseby Content-Type: text/plain; charset=UTF-8 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, 25 Sep 2014 19:35:10 -0000 What netmasks are you using on the FreeBSD machine? I have seen very strange behaviour (like packets not being able to be routed) in the FreeBSD network stack if I assign two addresses on the same subnet to different interfaces. On Thu, Sep 25, 2014 at 2:53 PM, Tony Moseby wrote: > Hello, > > > I have a nasty vlan problem that you might be able to help: > > I have two servers connect though a marvel switch , in one of the servers > I am running FreeBSD 8.2. > > Everything is fine until I define a vlan in each server,I can define the vlan in Fbsd side > and all still ok,how ever when I define the vlan in the non Fbsd server the communication > > between the servers on the trunk/lan stops working. > However the lan communication works fine.The trunk has 10.0.1.10(A server)and 10.0.1.11(B server) > > and the vlan 10.0.80.110 and 10.80.111 . > If I ping from 1.0.1.10(non Fbsd) to 10.0.1.11(Bsd) , I can see the icmp request going to Bsd server > but no answer coming back. > If I ping from the Bsd server (1.0.1.11) to 1.0.1.10 I can see the icmp reques coming to 1.0.1.10 > and I also can see the answer arriving in 1.0.1.11, but nothing more happens. > Looks like Fbsd can not handle this after the vlan been define in the non Fbsd server. > Someone understand this behavor? > Thanks > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Sep 25 19:44:20 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DB07E58; Thu, 25 Sep 2014 19:44:20 +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 0D51768E; Thu, 25 Sep 2014 19:44:19 +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 s8PJiFpq042734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 25 Sep 2014 23:44:15 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id s8PJiFZD042733; Thu, 25 Sep 2014 23:44:15 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 25 Sep 2014 23:44:15 +0400 From: Gleb Smirnoff To: "Andrey V. Elsukov" Subject: Re: svn commit: r272089 - head/sys/netpfil/ipfw Message-ID: <20140925194415.GD884@glebius.int.ru> References: <201409250226.s8P2Q6AS055635@svn.freebsd.org> <20140925051808.GS884@FreeBSD.org> <1411643223.2161.2.camel@bruno> <54241F1D.4080206@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54241F1D.4080206@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD Net , David Carlier , 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: Thu, 25 Sep 2014 19:44:20 -0000 On Thu, Sep 25, 2014 at 05:56:45PM +0400, Andrey V. Elsukov wrote: A> > Ok, moving off to freebsd-net. How should we proceded with debugging A> > further? A> A> Probably this can occurs when outgoing interface disappeared A> (netgrapg/tun/tap/lagg/vlan/usb ethernet), but packets were not send yet A> (delayed in the dummynet pipe). I think this is well known problem. AFAIK, when an mbuf leaves an interface, it completely detaches from it. There is no mechanism to clear all rcvif pointers on all mbufs travelling through stack when interface departs. Yes, here I describe another problem: interface departs, and rcvif pointers are stale. This is known and old problem. But the pointers are not NULL. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Sep 26 01:19:46 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33D30629; Fri, 26 Sep 2014 01:19:46 +0000 (UTC) Received: from ns.kevlo.org (220-135-115-6.HINET-IP.hinet.net [220.135.115.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns.kevlo.org", Issuer "ns.kevlo.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 86574DE3; Fri, 26 Sep 2014 01:19:44 +0000 (UTC) Received: from ns.kevlo.org (localhost [127.0.0.1]) by ns.kevlo.org (8.14.8/8.14.8) with ESMTP id s8Q1Hwkb061239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 Sep 2014 09:17:59 +0800 (CST) (envelope-from kevlo@ns.kevlo.org) Received: (from kevlo@localhost) by ns.kevlo.org (8.14.8/8.14.8/Submit) id s8Q1Hwja061238; Fri, 26 Sep 2014 09:17:58 +0800 (CST) (envelope-from kevlo) Date: Fri, 26 Sep 2014 09:17:57 +0800 From: Kevin Lo To: Nils Beyer Subject: Re: Success with Qualcomm Atheros QCA8171 Message-ID: <20140926011757.GA61226@ns.kevlo.org> References: <3320661411119387@web21h.yandex.ru> <20140925094736.F2E71AE5@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140925094736.F2E71AE5@hub.freebsd.org> User-Agent: Mutt/1.5.22 (2013-10-16) 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: Fri, 26 Sep 2014 01:19:46 -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. > > But for small data transfers (SSH, RSYNC, RDP) it's okay. Mark has done a good > job so far: > =============================================================================== > #dmesg | grep alx > alx0: port 0x2000-0x207f mem 0xd0400000-0xd043ffff irq 16 at device 0.0 on pci2 > alx0: Ethernet address: 5c:f9:dd:55:c9:fb > > #ifconfig alx0 > alx0: flags=8843 metric 0 mtu 1500 > ether 5c:f9:dd:55:c9:fb > inet6 fe80::5ef9:ddff:fe55:c9fb%alx0 prefixlen 64 scopeid 0x2 > nd6 options=29 > media: Ethernet autoselect > status: no carrier > > #pciconf -evl | tail -13 > alx0@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 > PCI-e errors = Correctable Error Detected > Non-Fatal Error Detected > Unsupported Request Detected > Non-fatal = Unsupported Request > Corrected = Bad TLP > Bad DLLP > REPLAY_NUM Rollover > Replay Timer Timeout > =============================================================================== AFAIK yongari@ is working on it. > Regards, > Nils Kevin From owner-freebsd-net@FreeBSD.ORG Fri Sep 26 04:42: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A76399F4 for ; Fri, 26 Sep 2014 04:42:30 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 63C927DB for ; Fri, 26 Sep 2014 04:42:29 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s8Q4gMS6059031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2014 21:42:22 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s8Q4gMaF059030; Thu, 25 Sep 2014 21:42:22 -0700 (PDT) (envelope-from jmg) Date: Thu, 25 Sep 2014 21:42:22 -0700 From: John-Mark Gurney To: Tony Moseby Subject: Re: vlan problem Message-ID: <20140926044222.GC43300@funkthat.com> Mail-Followup-To: Tony Moseby , "freebsd-net@freebsd.org" References: <1411671232.29910.YahooMailNeo@web172805.mail.ir2.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1411671232.29910.YahooMailNeo@web172805.mail.ir2.yahoo.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 25 Sep 2014 21:42:23 -0700 (PDT) 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, 26 Sep 2014 04:42:30 -0000 Tony Moseby wrote this message on Thu, Sep 25, 2014 at 19:53 +0100: > Hello, > > > I have a nasty vlan problem that you might be able to help: > > I have two servers connect though a marvel switch , in one of the servers > I am running FreeBSD 8.2. > > Everything is fine until I define a vlan in each server,I can define the vlan in Fbsd side > and all still ok,how ever when I define the vlan in the non Fbsd server the communication > > between the servers on the trunk/lan stops working. > However the lan communication works fine.The trunk has 10.0.1.10(A server)and 10.0.1.11(B server) > > and the vlan 10.0.80.110 and 10.80.111 . > If I ping from 1.0.1.10(non Fbsd) to 10.0.1.11(Bsd) , I can see the icmp request going to Bsd server > but no answer coming back. > If I ping from the Bsd server (1.0.1.11) to 1.0.1.10 I can see the icmp reques coming to 1.0.1.10 > and I also can see the answer arriving in 1.0.1.11, but nothing more happens. > Looks like Fbsd can not handle this after the vlan been define in the non Fbsd server. > Someone understand this behavor? Also, is the routing table setup properly? Are you sure the routing table is setup so the response goes out the vlan interface? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Fri Sep 26 10:47:15 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 527C5D5E; Fri, 26 Sep 2014 10:47:15 +0000 (UTC) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::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 1A3D9641; Fri, 26 Sep 2014 10:47:15 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id r10so12504820pdi.11 for ; Fri, 26 Sep 2014 03:47:14 -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=BEdz3pfC5hwlkQtzfmJE+oeiTQzcNr9nmEIElG1JpwY=; b=o3EhXfyjznB+Zw2PeC0vLEa2m+OJRei5avO7X4AeY2Hh1Gw/hIRDIRAYrNhB2zXX8L ubt6CvVKSx130erMx/ZkmtE5yJRE4qgJQ3oStfri036lzSUS96DNTIJmiIjJ0Dr1JvzS ky8erSZXJWZFmgmpfNuhGWHXxLF1XR4XOjgrK9N56yYn+zpfoimPnYciFlT9hBMKq7Wg J9+7fm3CuPBbkghTxkIDzeBBATCxlfyKxG8wlYpYRxzHvEK5xRDKNzh096Wht5RIIN5v nGb8Af/oe4RhZpclhlJ+2SYQ/2tt8R5T670zR9vkvwfRcoqzwNpv+MrxYqRplsmpq/Lb Ds2g== X-Received: by 10.68.136.100 with SMTP id pz4mr29179029pbb.119.1411728434183; Fri, 26 Sep 2014 03:47:14 -0700 (PDT) Received: from pyunyh@gmail.com ([106.247.248.2]) by mx.google.com with ESMTPSA id nk11sm4602215pdb.40.2014.09.26.03.47.09 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 26 Sep 2014 03:47:12 -0700 (PDT) From: Yonghyeon PYUN X-Google-Original-From: "Yonghyeon PYUN" Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 26 Sep 2014 19:46:59 +0900 Date: Fri, 26 Sep 2014 19:46:59 +0900 To: Kevin Lo Subject: Re: Success with Qualcomm Atheros QCA8171 Message-ID: <20140926104659.GA980@michelle.fasterthan.com> Reply-To: pyunyh@gmail.com References: <3320661411119387@web21h.yandex.ru> <20140925094736.F2E71AE5@hub.freebsd.org> <20140926011757.GA61226@ns.kevlo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140926011757.GA61226@ns.kevlo.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, freebsd-drivers@freebsd.org, Nils Beyer 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, 26 Sep 2014 10:47:15 -0000 On Fri, Sep 26, 2014 at 09:17:57AM +0800, Kevin Lo wrote: > 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- Yeah, the controller requires lots of DSP fixup codes under various situations. > > nality ceases as soon as I perform an "iperf" benchmark until I reboot. > > > > But for small data transfers (SSH, RSYNC, RDP) it's okay. Mark has done a good > > job so far: > > =============================================================================== > > #dmesg | grep alx > > alx0: port 0x2000-0x207f mem 0xd0400000-0xd043ffff irq 16 at device 0.0 on pci2 > > alx0: Ethernet address: 5c:f9:dd:55:c9:fb > > > > #ifconfig alx0 > > alx0: flags=8843 metric 0 mtu 1500 > > ether 5c:f9:dd:55:c9:fb > > inet6 fe80::5ef9:ddff:fe55:c9fb%alx0 prefixlen 64 scopeid 0x2 > > nd6 options=29 > > media: Ethernet autoselect > > status: no carrier > > > > #pciconf -evl | tail -13 > > alx0@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 > > PCI-e errors = Correctable Error Detected > > Non-Fatal Error Detected > > Unsupported Request Detected > > Non-fatal = Unsupported Request > > Corrected = Bad TLP > > Bad DLLP > > REPLAY_NUM Rollover > > Replay Timer Timeout > > =============================================================================== > > AFAIK yongari@ is working on it. Yes, I'm working on it. Very basic things seems to work at this moment but it still has lots of things to be resolved. Due to lack of spare time the progress is very slow but I'll let you guys know when it's ready for public testing. From owner-freebsd-net@FreeBSD.ORG Fri Sep 26 13:21:12 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37A17971 for ; Fri, 26 Sep 2014 13:21:12 +0000 (UTC) Received: from hobex19.hob.de (hobex19.hob.de [212.185.199.31]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "hobex19", Issuer "hobex19" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C5DFEAF9 for ; Fri, 26 Sep 2014 13:21:11 +0000 (UTC) Received: from HOBEX22.hob.de (172.22.1.22) by hobex19.hob.de (172.25.1.31) with Microsoft SMTP Server (TLS) id 14.2.347.0; Fri, 26 Sep 2014 15:19:40 +0200 Received: from HOBEX21.hob.de ([fe80::886:fbb5:dd12:7a2f]) by HOBEX22.hob.de ([::1]) with mapi id 14.02.0387.000; Fri, 26 Sep 2014 15:19:52 +0200 From: "Leupoldt, Martin" To: "'freebsd-net@freebsd.org'" Subject: netmap on ubuntu 14.04? Thread-Topic: netmap on ubuntu 14.04? Thread-Index: Ac/Zi8NjHSQcge1oS3immNdS/agA8w== Date: Fri, 26 Sep 2014 13:19:51 +0000 Message-ID: <321E74F3FD7B9B478555010DC1AFD5D5C7357FD8@HOBEX21.hob.de> 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] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: Fri, 26 Sep 2014 13:21:12 -0000 Hello together, has anyone experience about netmap on a Ubuntu 14.04 machine? Actually we have compiled netmap including the module linux_lin.ko and have= successfully loaded it. But everytime we try to start the bridge, we=B4re getting the following err= or: ./bridge built Sep 10 2014 09:37:00 889.491390 main [233] cannot open eth1 Kernel: Linux 3.13.0-24-generic x86_x64 Does anyone have any ideas many thanks. Mit freundlichen Gr=FC=DFen, Martin Leupoldt Leiter Server Systeme Tel +49 (0)9103-715-3272 Fax +49 (0)9103-715-3299 E-mail: martin.leupoldt@hob.de Internet: http://www.hob.de ________________________________ Follow HOB: - HOB: http://www.hob.de/redirect/hob.html - Xing: http://www.hob.de/redirect/xing.html - LinkedIn: http://www.hob.de/redirect/linkedin.html - HOBLink Mobile: http://www.hob.de/redirect/hoblinkmobile.html - Facebook: http://www.hob.de/redirect/facebook.html - Twitter: http://www.hob.de/redirect/twitter.html - YouTube: http://www.hob.de/redirect/youtube.html - E-Mail: http://www.hob.de/redirect/mail.html HOB RD VPN - einfach, sicher und flexibel auf alle Unternehmensanwendungen = und -daten zugreifen Praesentation unter: http://www.hob.de/rdvpn2/ HOB GmbH & Co. KG Schwadermuehlstr. 3 D-90556 Cadolzburg Geschaeftsfuehrung: Klaus Brandstaetter, Zoran Adamovic AG Fuerth, HRA 5180 Steuer-Nr. 218/163/00107 USt-ID-Nr. DE 132747002 Komplementaerin HOB electronic Beteiligungs GmbH AG Fuerth, HRB 3416 From owner-freebsd-net@FreeBSD.ORG Fri Sep 26 18:21:55 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5AE8D92 for ; Fri, 26 Sep 2014 18:21:55 +0000 (UTC) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::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 850C9157 for ; Fri, 26 Sep 2014 18:21:55 +0000 (UTC) Received: by mail-qc0-f169.google.com with SMTP id r5so6101659qcx.14 for ; Fri, 26 Sep 2014 11:21:54 -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=uCSKhlFcPq00ruJBZFAkCcK0STBJiby+lI12mvkIhyw=; b=R/zyrlfjESxagmdxETKXb50Si+BT4T/Q8Em6qfRVnrN4p50W8fIeVG6sCn30j4YYXt XOTWFceMPluPqdGk7Lk0s7gZmte7Eku5hTdo0Fhm4G2LIXRzDdF1eTxbDsvGThjcMcj9 4bEkmdxuSdY34x6cFaBG9r87PUVItu4/l5GhdgACKUhbC9v8TZOhr2ZBNb25FZcOZSD4 9jcc6e1GXQ6QKop3+qrwB2SZNOC9M+fkQQPAWMqI0pfpfmQItux7LllYatozj7ohIjTw n57bOBy0p40onWRZe7wNiTGFEmZzJ7u4xi877nLuIacPn2KoDvmLI+R4Sq4P3lD+Lgdy ydLA== MIME-Version: 1.0 X-Received: by 10.224.46.133 with SMTP id j5mr31269976qaf.92.1411755714491; Fri, 26 Sep 2014 11:21:54 -0700 (PDT) Received: by 10.140.86.139 with HTTP; Fri, 26 Sep 2014 11:21:54 -0700 (PDT) In-Reply-To: <321E74F3FD7B9B478555010DC1AFD5D5C7357FD8@HOBEX21.hob.de> References: <321E74F3FD7B9B478555010DC1AFD5D5C7357FD8@HOBEX21.hob.de> Date: Fri, 26 Sep 2014 21:21:54 +0300 Message-ID: Subject: Re: netmap on ubuntu 14.04? From: Stefano Garzarella To: "Leupoldt, Martin" 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: Fri, 26 Sep 2014 18:21:55 -0000 Hi Martin, can you try in this way "sudo ./bridge -i netmap:eth1"? netmap:eth1 means that eth1 is put in netmap mode. Cheers, Stefano 2014-09-26 16:19 GMT+03:00 Leupoldt, Martin : > Hello together, > > has anyone experience about netmap on a Ubuntu 14.04 machine? > Actually we have compiled netmap including the module linux_lin.ko and > have successfully loaded it. > But everytime we try to start the bridge, we=C2=B4re getting the followin= g > error: > > ./bridge built Sep 10 2014 09:37:00 > 889.491390 main [233] cannot open eth1 > Kernel: Linux 3.13.0-24-generic x86_x64 > > Does anyone have any ideas > > many thanks. > > Mit freundlichen Gr=C3=BC=C3=9Fen, > > Martin Leupoldt > Leiter Server Systeme > > Tel +49 (0)9103-715-3272 > Fax +49 (0)9103-715-3299 > > E-mail: martin.leupoldt@hob.de > Internet: http://www.hob.de > > > ________________________________ > > Follow HOB: > > - HOB: http://www.hob.de/redirect/hob.html > - Xing: http://www.hob.de/redirect/xing.html > - LinkedIn: http://www.hob.de/redirect/linkedin.html > - HOBLink Mobile: http://www.hob.de/redirect/hoblinkmobile.html > - Facebook: http://www.hob.de/redirect/facebook.html > - Twitter: http://www.hob.de/redirect/twitter.html > - YouTube: http://www.hob.de/redirect/youtube.html > - E-Mail: http://www.hob.de/redirect/mail.html > > > HOB RD VPN - einfach, sicher und flexibel auf alle Unternehmensanwendunge= n > und -daten zugreifen > > Praesentation unter: http://www.hob.de/rdvpn2/ > > > HOB GmbH & Co. KG > Schwadermuehlstr. 3 > D-90556 Cadolzburg > > Geschaeftsfuehrung: Klaus Brandstaetter, Zoran Adamovic > > AG Fuerth, HRA 5180 > Steuer-Nr. 218/163/00107 > USt-ID-Nr. DE 132747002 > > Komplementaerin HOB electronic Beteiligungs GmbH > AG Fuerth, HRB 3416 > _______________________________________________ > 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 *Stefano Garzarella* stefano.garzarella@gmail.com From owner-freebsd-net@FreeBSD.ORG Fri Sep 26 22:26:40 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7338E68; Fri, 26 Sep 2014 22:26:40 +0000 (UTC) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::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 8639EE1; Fri, 26 Sep 2014 22:26:40 +0000 (UTC) Received: by mail-pd0-f178.google.com with SMTP id ft15so13463782pdb.23 for ; Fri, 26 Sep 2014 15:26:40 -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=EGjCwDTfjRftHt7MMZgb2yWeirUAeQrMfLmkNiYYEDk=; b=0qJRB0/gaegJH5fZ2sYBTSqH3STNmfNOe2nYZtHSAPzKX4agN1KrNyvdbbZgllLnt+ CVgkbVg2iNCAaUzL/RuFSbjuSQammSBVn/AR8oR5CCEVmsGpBcVzuZVEW1E/Ffay9gax Q7dBOkU+PoxHUdaknhGdbasrXPLXhFBegQs8tf0FJjVivkBwOtmRtw5y1G2JETif80ZM aQhD1bPnOzoDaajKrVv4T053tSut/uxUgFmuUeGEspFhty68vYUrrQVLDfpDXpmiZ6iu pspBCedJ13eNTMFxq+98z1MU1qDtS34vzT/PIXVcwwjTx/fylevv3jjG7ohqciF3RuYs s8Ig== X-Received: by 10.68.196.226 with SMTP id ip2mr35644148pbc.120.1411770400027; Fri, 26 Sep 2014 15:26:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.81.137 with HTTP; Fri, 26 Sep 2014 15:25:59 -0700 (PDT) In-Reply-To: <20140925120810.GA884@FreeBSD.org> References: <20140925120810.GA884@FreeBSD.org> From: Eric Joyner Date: Fri, 26 Sep 2014 15:25:59 -0700 Message-ID: Subject: Re: [PATCH] Convert ixl(4) and ixlv(4) to ifcounters, and fix some counter bugs To: Gleb Smirnoff Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net , Ryan Stone 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, 26 Sep 2014 22:26:40 -0000 I approve of this patch -- I tested it on ixl and ixlv on stable/10, and at least the sysctl stats still look good. --- - Eric Joyner On Thu, Sep 25, 2014 at 5:08 AM, Gleb Smirnoff wrote: > On Tue, Sep 23, 2014 at 07:18:51PM -0400, Ryan Stone wrote: > R> The patch below converts the ixl(4) and ixlv(4) drivers to use the new > R> ifcounter interface. I've hidden the interface behind some macros to > R> ensure that the driver continues to compile for FreeBSD 10 and > R> earlier. The result of the macros is that the ifcounter > R> implementation is somewhat clunkier than I would have liked, but I > R> preferred to try and share as much code between the legacy counter > R> implementation and the ifcounter implementation. > R> > R> I have tested the ixl driver with head. I have only compile-tested it > R> for stable/10. > R> > R> This patch also fixes some counter bugs: > R> > R> - Ensure that tx discards are reported > R> - There are actually two types of rx discard counters in the hardware. > R> Currently the driver is only reporting discards from one of the two > R> counters, so I fixed that > R> - The ipackets and opackets counters were being unnecessarily > R> incremented in the rx and tx paths. This was racy, unnecessary (the > R> counters also get explicitly set based on the values in HW counters) > R> and very bad for performance -- the cacheline contained the counters > R> was constantly bouncing between CPUs. I saw this even with only one > R> queue active, probably due to false sharing with some other field in > R> the ifnet struct. > R> > R> > https://people.freebsd.org/~rstone/patches/ixl/0005-Convert-ixl-and-ixlv-drivers-to-use-new-ifcounter-in.patch > > Thanks, Ryan! > > I'd suggest to use check against __FreeBSD_version >= 1100036. > > Can you please commit this? Navdeep promised to do cxgbe(4), Alexander > is working on ixgbe. After that we can go forward with making counters > in struct ifnet non-racy and cheap counter(9). > > -- > Totus tuus, Glebius. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sat Sep 27 11:21:58 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EFB9FA64 for ; Sat, 27 Sep 2014 11:21:57 +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 6B27BE6 for ; Sat, 27 Sep 2014 11:21:56 +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 s8RBLseU052442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 27 Sep 2014 15:21:55 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id s8RBLsYx052441; Sat, 27 Sep 2014 15:21:54 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sat, 27 Sep 2014 15:21:54 +0400 From: Gleb Smirnoff To: Eric Joyner Subject: Re: [PATCH] Convert ixl(4) and ixlv(4) to ifcounters, and fix some counter bugs Message-ID: <20140927112154.GO884@glebius.int.ru> References: <20140925120810.GA884@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-net , Ryan Stone 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, 27 Sep 2014 11:21:58 -0000 Thanks, Eric. Ryan, will you commit? The cxgbe(4) is already updated by Navdeep. Me and melifaro@ are finishing lagg(4). Once Intel drivers are done, we can go forward for counter(9) in struct ifnet. On Fri, Sep 26, 2014 at 03:25:59PM -0700, Eric Joyner wrote: E> I approve of this patch -- I tested it on ixl and ixlv on stable/10, and at E> least the sysctl stats still look good. E> E> --- E> - Eric Joyner E> E> On Thu, Sep 25, 2014 at 5:08 AM, Gleb Smirnoff wrote: E> E> > On Tue, Sep 23, 2014 at 07:18:51PM -0400, Ryan Stone wrote: E> > R> The patch below converts the ixl(4) and ixlv(4) drivers to use the new E> > R> ifcounter interface. I've hidden the interface behind some macros to E> > R> ensure that the driver continues to compile for FreeBSD 10 and E> > R> earlier. The result of the macros is that the ifcounter E> > R> implementation is somewhat clunkier than I would have liked, but I E> > R> preferred to try and share as much code between the legacy counter E> > R> implementation and the ifcounter implementation. E> > R> E> > R> I have tested the ixl driver with head. I have only compile-tested it E> > R> for stable/10. E> > R> E> > R> This patch also fixes some counter bugs: E> > R> E> > R> - Ensure that tx discards are reported E> > R> - There are actually two types of rx discard counters in the hardware. E> > R> Currently the driver is only reporting discards from one of the two E> > R> counters, so I fixed that E> > R> - The ipackets and opackets counters were being unnecessarily E> > R> incremented in the rx and tx paths. This was racy, unnecessary (the E> > R> counters also get explicitly set based on the values in HW counters) E> > R> and very bad for performance -- the cacheline contained the counters E> > R> was constantly bouncing between CPUs. I saw this even with only one E> > R> queue active, probably due to false sharing with some other field in E> > R> the ifnet struct. E> > R> E> > R> E> > https://people.freebsd.org/~rstone/patches/ixl/0005-Convert-ixl-and-ixlv-drivers-to-use-new-ifcounter-in.patch E> > E> > Thanks, Ryan! E> > E> > I'd suggest to use check against __FreeBSD_version >= 1100036. E> > E> > Can you please commit this? Navdeep promised to do cxgbe(4), Alexander E> > is working on ixgbe. After that we can go forward with making counters E> > in struct ifnet non-racy and cheap counter(9). E> > E> > -- E> > Totus tuus, Glebius. E> > _______________________________________________ E> > freebsd-net@freebsd.org mailing list E> > http://lists.freebsd.org/mailman/listinfo/freebsd-net E> > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" E> > -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Sat Sep 27 13:57:56 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A54A855 for ; Sat, 27 Sep 2014 13:57:56 +0000 (UTC) Received: from nm28.bullet.mail.ir2.yahoo.com (nm28.bullet.mail.ir2.yahoo.com [212.82.96.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ED78C8A for ; Sat, 27 Sep 2014 13:57:54 +0000 (UTC) Received: from [212.82.98.51] by nm28.bullet.mail.ir2.yahoo.com with NNFMP; 27 Sep 2014 13:55:58 -0000 Received: from [212.82.98.72] by tm4.bullet.mail.ir2.yahoo.com with NNFMP; 27 Sep 2014 13:55:58 -0000 Received: from [127.0.0.1] by omp1009.mail.ir2.yahoo.com with NNFMP; 27 Sep 2014 13:55:58 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 306063.9974.bm@omp1009.mail.ir2.yahoo.com Received: (qmail 380 invoked by uid 60001); 27 Sep 2014 13:55:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1411826158; bh=jY9zIIGCNQaldtKxMgHQT7/+OTFobWl1LIdROFOkx3I=; h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=QPrny82pYgCb0NnlWlSFku2K/vqEK71jk1maTi67aKZGS/N7Z5eHIekXip9wc46h80WqobEM96WPvmMnojHBZq90+baB4UmIDi5ec3hWtqgttIdV2MbmPd/pIfEEJPzPosRFV0CNYvf6ZDBwH0zUWpt3Nb7tXYWwffgwX1m9BKQ= X-YMail-OSG: odu35KUVM1mvVtNhd5QYr2LDXqya5MN4eh109.xw80aWL35 20OgR6UqjdX3lH.mHN9xFW0VuGxCoESlfMe5vlurBrg55zA2.fJcZXZ58VpG 6amF_wX.w9yamaOLKJr2N3ZCrcFsaRGUpsJrJdccqygjBiDz7_31m5v_m2PB k4M9zOjXvJYwnr4dSNkcE4F8hzNl.t9O02k8333Ee_Xayj6VksPKqD_w._Fy I0etc0mcMj0EUb3hgV2GslT9O4jADXWlzf_PttI898lqKsnBpN4PCz1WhaDN i7RVvZqaNYoJ3dr0Et0Q96JEviSF8supey6TvLBo5uuHalDi4rl9bzycGd3V MiROYehd3olZyxc9ng7h4LznpxcINJ.oOlZLQ2Oay8WojbjTEuMouR7JXwal YhPVXur7j18iz5pc_nyj3FPEAaU52oqEfj4ufIxJDDge2fLNM5Q1pO5SjIBP jMBR1Pb0ahifVcrlt1sSovPY0hgI2jGCZoXq.aHiMgQ1ry2aIUNqFeBN96.U hmK1YtU1YyVnGyppw2b0tXFfvfPPBEK3jY5cDg6S2EB7tUNHHbA-- Received: from [92.254.163.111] by web172803.mail.ir2.yahoo.com via HTTP; Sat, 27 Sep 2014 14:55:58 BST X-Rocket-MIMEInfo: 002.001, SGVsbG8sCgpGcmVlQlNEIHNlZW1zIHRvIGRyb3BwIGZyYW1lcyB3aXRoIHZsYW4gaWQgMChhbGwgb3RoZXIgaWQgb2spIGRvZXMgYW55b25lIGtub3cKaWYgdGhpcyBoYXMgYmVlbiBjb3JyZWN0ZWQ_cGF0Y2ggZXRjCgpJIGNhbiBzZWUgYSBwYXRjaCBmb3IgdGhpcyB2ZXJ5IHNhbWUgaXNzdWUgaW4gTGludXggYnV0IG5vdCBpbiBGcmVlQlNEIQpUaGFua3MKATABAQEB X-Mailer: YahooMailWebService/0.8.203.696 Message-ID: <1411826158.72985.YahooMailNeo@web172803.mail.ir2.yahoo.com> Date: Sat, 27 Sep 2014 14:55:58 +0100 From: Tony Moseby Reply-To: Tony Moseby Subject: vlan id 0 To: "freebsd-net@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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: Sat, 27 Sep 2014 13:57:56 -0000 Hello,=0A=0AFreeBSD seems to dropp frames with vlan id 0(all other id ok) d= oes anyone know=0Aif this has been corrected?patch etc=0A=0AI can see a pat= ch for this very same issue in Linux but not in FreeBSD!=0AThanks=0A From owner-freebsd-net@FreeBSD.ORG Sat Sep 27 23:44:59 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 4F9237E8 for ; Sat, 27 Sep 2014 23:44:59 +0000 (UTC) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::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 DFA0C18D for ; Sat, 27 Sep 2014 23:44:58 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id p10so1752678wes.4 for ; Sat, 27 Sep 2014 16:44: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=jaF+WFttNIG6LIJCLvOsPquXYPff6qUOLlh/UG2ShfY=; b=0TP5PWamHpU4hopfyZusFo7ufqVWu63k+UTtTGTVera5HuXUtNVykvSWwLPBUvDC7X PzbQXmp8spE0eJeaxVZ2LtSp05kxUwyAqjaLLQ99tj4ssbJ0JVRZ/0EyrMS+0Af07xuE CNIvjrtWmok+2B+YrnOjeU5J91nrdSQepV+ylOm7uFZYMGiIdfsyOJZndSOgy7GwiCQ7 nwmdQRTCXY5m9j8+GG5lezMzjuqrP8MlYrL1ND5Myjji29j1io5HxPsdaOQ8CJF2uy8r G9dar1VG69JYJDNeMYz7RE2h8ahmwBcypb48gQmlbIjz5C2Xmjmiu/x23XWbwzo2OGwr NzbQ== MIME-Version: 1.0 X-Received: by 10.180.101.129 with SMTP id fg1mr55122169wib.20.1411861497153; Sat, 27 Sep 2014 16:44:57 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Sat, 27 Sep 2014 16:44:57 -0700 (PDT) In-Reply-To: <1411826158.72985.YahooMailNeo@web172803.mail.ir2.yahoo.com> References: <1411826158.72985.YahooMailNeo@web172803.mail.ir2.yahoo.com> Date: Sat, 27 Sep 2014 16:44:57 -0700 X-Google-Sender-Auth: JaZefAD2-mVvjWwHeBBTUEexHRs Message-ID: Subject: Re: vlan id 0 From: Adrian Chadd To: Tony Moseby Content-Type: text/plain; charset=UTF-8 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: Sat, 27 Sep 2014 23:44:59 -0000 .. the spec allows vlan id=0? -a On 27 September 2014 06:55, Tony Moseby wrote: > Hello, > > FreeBSD seems to dropp frames with vlan id 0(all other id ok) does anyone know > if this has been corrected?patch etc > > I can see a patch for this very same issue in Linux but not in FreeBSD! > Thanks > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"