From owner-freebsd-net@FreeBSD.ORG Sun May 31 17:41:11 2015 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 55FA8D9 for ; Sun, 31 May 2015 17:41:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3F0B216BF for ; Sun, 31 May 2015 17:41:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4VHfBKU098866 for ; Sun, 31 May 2015 17:41:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 187149] [patch] [netmap] fix netmap's pkt-gen behavior with IP addresses or port range Date: Sun, 31 May 2015 17:41: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: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: olivier@cochard.me X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.isobsolete attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2015 17:41:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187149 olivier@cochard.me changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #140539|0 |1 is obsolete| | --- Comment #2 from olivier@cochard.me --- Created attachment 157306 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=157306&action=edit patch for pkt-gen (freebsd -current) Here is an improved patch that allow to optionally use the "software UDP checksum" because some NIC like Chelsio allow hardwarde checksuming in netmap mode. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sun May 31 17:41:38 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95ADC164 for ; Sun, 31 May 2015 17:41:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7D7ED1709 for ; Sun, 31 May 2015 17:41:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4VHfc2u000783 for ; Sun, 31 May 2015 17:41:38 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 187149] [patch] [netmap] fix netmap's pkt-gen behavior with IP addresses or port range Date: Sun, 31 May 2015 17:41:38 +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: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: olivier@cochard.me X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2015 17:41:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187149 --- Comment #3 from olivier@cochard.me --- Created attachment 157307 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=157307&action=edit patch for pkt-gen (freebsd 10.1) -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sun May 31 21:00:25 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 45EC8484 for ; Sun, 31 May 2015 21:00:25 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1C790132F for ; Sun, 31 May 2015 21:00:25 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4VL0OLJ035263 for ; Sun, 31 May 2015 21:00:24 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201505312100.t4VL0OLJ035263@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, 31 May 2015 21:00:24 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2015 21:00:25 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 197535 | [re] [panic] if_re (Realtek 8168) causes memory w Open | 194515 | Fatal Trap 12 Kernel with vimage Open | 199136 | [if_tap] Added down_on_close sysctl variable to t 3 problems total for which you should take action. From owner-freebsd-net@FreeBSD.ORG Mon Jun 1 08:25:12 2015 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 3886FFBF for ; Mon, 1 Jun 2015 08:25:12 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 E82FA1A8E for ; Mon, 1 Jun 2015 08:25:11 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YzL1x-000Mm8-US for freebsd-net@freebsd.org; Mon, 01 Jun 2015 11:25:09 +0300 Date: Mon, 1 Jun 2015 11:25:09 +0300 From: Slawa Olhovchenkov To: freebsd-net@freebsd.org Subject: Intel igb 82576 (netmap mode) and RSS queue issuse with fragmented UDP packets. Message-ID: <20150601082509.GE1647@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 08:25:12 -0000 I am use Intel 82576 (igb driver) in netmap mode. I see isssuse: flow routed in different queue depends of IP flags. For example: Total 4 queue. UDP flow. SRC: 91.214.70.167:12062 DST: 95.31.64.226:49939 Flags:DF routed to queue 0 SRC: 91.214.70.167:12062 DST: 95.31.64.226:49939 Flags:More_Frags (offset 0, length 1396) routed to queue 3 I understand that next fragment (IP (tos 0x0, ttl 62, id 36361, offset 1376, flags [none], proto UDP (17), length 102) 91.214.70.167 > 95.72.171.116: ip-proto-17) may be routed in different queue, but why fragment 0 routed to different queue? This is software (driver, netmap) issuse? Or this is hardware (silicon) isssuse? What about Intel 10G/40G cards? Chelsio? From owner-freebsd-net@FreeBSD.ORG Mon Jun 1 14:50:32 2015 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 D0D26F64 for ; Mon, 1 Jun 2015 14:50:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9AA4319AC for ; Mon, 1 Jun 2015 14:50:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by iebgx4 with SMTP id gx4so110475392ieb.0 for ; Mon, 01 Jun 2015 07:50:31 -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=ua31iHHw+d3HdFv0qgvW4PO1JNJBUkM0pJtBUbTgCaw=; b=D33lmvyd/fbitnT0LJk8CnUyvICgn+Pk7qvcKuoPDQ0leZOLv/hA5aerBj2NDJrkJM 2Bl6MqRTTT6vHvkqvSa/f+WsRuA/N0yLScNdOMlfHzqtBMa6Fp+7MVKrBoW7IfsHqEML qVKcdwuHlEKIyKgeeocwH1dCOwGTKvoRUsG0esm/Tql84CGISXIjJItSE1xsXfA/wX4t 3hvpBJHk3BzjeTwT6WDCi5HTU9KyNwYJfx+4X7MkKtx1/arD4t/X6TtvgcWdQx5eg1hv JuR3nWKKtjiZ44wcmPMsIHQvCJFCAO/SOWqHFcGu2mvWFSZp6Cs2uL0qm0Co8HcPy027 zEdw== MIME-Version: 1.0 X-Received: by 10.42.120.66 with SMTP id e2mr29299687icr.37.1433170231785; Mon, 01 Jun 2015 07:50:31 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Mon, 1 Jun 2015 07:50:31 -0700 (PDT) In-Reply-To: <20150601082509.GE1647@zxy.spb.ru> References: <20150601082509.GE1647@zxy.spb.ru> Date: Mon, 1 Jun 2015 07:50:31 -0700 X-Google-Sender-Auth: DSzgVYJQJ51fFHsKRyaNS86K4oA Message-ID: Subject: Re: Intel igb 82576 (netmap mode) and RSS queue issuse with fragmented UDP packets. From: Adrian Chadd To: Slawa Olhovchenkov Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 14:50:32 -0000 They all behave the same. You can fix the intel driver(s) by looking for the TCP/UDP queue config and only enabling IPv4/IPv6 (not TCP/UDP) hashing. -adrian On 1 June 2015 at 01:25, Slawa Olhovchenkov wrote: > I am use Intel 82576 (igb driver) in netmap mode. > I see isssuse: flow routed in different queue depends of IP flags. > > For example: > > Total 4 queue. > UDP flow. > SRC: 91.214.70.167:12062 DST: 95.31.64.226:49939 Flags:DF routed to queue 0 > SRC: 91.214.70.167:12062 DST: 95.31.64.226:49939 Flags:More_Frags (offset 0, length 1396) routed to queue 3 > > I understand that next fragment (IP (tos 0x0, ttl 62, id 36361, offset > 1376, flags [none], proto UDP (17), length 102) 91.214.70.167 > > 95.72.171.116: ip-proto-17) may be routed in different queue, but why > fragment 0 routed to different queue? This is software (driver, > netmap) issuse? Or this is hardware (silicon) isssuse? > > What about Intel 10G/40G cards? Chelsio? > > _______________________________________________ > 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 Jun 1 14:53:52 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2BB799F for ; Mon, 1 Jun 2015 14:53:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E94D61B5D for ; Mon, 1 Jun 2015 14:53:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by ieclw1 with SMTP id lw1so15582551iec.3 for ; Mon, 01 Jun 2015 07:53:51 -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=8CsagijCO+4vBHWHk/vToYjOs5rgxavLj7acN+XEUQM=; b=SS6ZmmpIMyHNhMhBaygyewHO+9cfyQoCIvQImLx57DQOj3KTZSYCT/gV1yX8fxWoZ4 o9YB+DSl9s2eszSfDvk/En1PFQZCXwq4KUomch/fVVFvZgIis0mTRUjNl/YHogZt8n09 UueqszUzcVfZtif/sJJCPePhdKKspYH9NaWU2f8OR14KXAiCJZEH/Ke6WY5iAQsxJDf3 xpTK5ezWZgZfO6J2cEdrsQm+KWJFwVsBlk4KUCW0+D5JvKjUrD2d9XFWVKo3Zg3JFqWm 9Ent/vQC4jey7ng3bP+ir51mk3m3vTNWUiokxWpPoFfs9tHW8e/UGsB/HatD+wCodYYH iMug== MIME-Version: 1.0 X-Received: by 10.107.11.26 with SMTP id v26mr3799359ioi.8.1433170431404; Mon, 01 Jun 2015 07:53:51 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Mon, 1 Jun 2015 07:53:51 -0700 (PDT) In-Reply-To: References: <20150601082509.GE1647@zxy.spb.ru> Date: Mon, 1 Jun 2015 07:53:51 -0700 X-Google-Sender-Auth: -TI7-DrfjNMuEOqAx54_k4sl1_I Message-ID: Subject: Re: Intel igb 82576 (netmap mode) and RSS queue issuse with fragmented UDP packets. From: Adrian Chadd To: Slawa Olhovchenkov Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 14:53:52 -0000 oh, hm, you asked the next question. Sorry, I haven't had coffee. I vaguely remember testing this and discovering the /should/ be putting all the frames in a packet int he same queue, as long as the frames have a consistent set of fragment bits set. Ie, if you're doing UDP and all frames in a packet have the fragment bit set, then all fragments (first and the rest) go into the same queue. Frames in a flow that are fragmented for some and not others (eg TCP flows with a firewall/router doing explicit fragmentation, or a mix of small/large UDP packets) will end up going into different queues. I can re-test this on ixgbe at some point, but IIRC that's how it behaved. I don't have the RSS stuff done for chelsio, so I haven't done any experiments just yet. Now, I also remember that with the badly setup flowdirector code in ixgbe it would mess that up, so the flowdir code was disabled in -HEAD and I believe now in -10. -adrian From owner-freebsd-net@FreeBSD.ORG Mon Jun 1 14:54:26 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DAD14133; Mon, 1 Jun 2015 14:54:26 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 937961B6C; Mon, 1 Jun 2015 14:54:26 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YzR6d-0004Qx-2A; Mon, 01 Jun 2015 17:54:23 +0300 Date: Mon, 1 Jun 2015 17:54:23 +0300 From: Slawa Olhovchenkov To: Adrian Chadd Cc: FreeBSD Net Subject: Re: Intel igb 82576 (netmap mode) and RSS queue issuse with fragmented UDP packets. Message-ID: <20150601145423.GH1647@zxy.spb.ru> References: <20150601082509.GE1647@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 14:54:27 -0000 On Mon, Jun 01, 2015 at 07:50:31AM -0700, Adrian Chadd wrote: > They all behave the same. You can fix the intel driver(s) by looking > for the TCP/UDP queue config and only enabling IPv4/IPv6 (not TCP/UDP) > hashing. Are you sure that enabling only IPv4/IPv6 hashing fix this? I see hashing in may case depends from flags fields. flags field is not part of TCP/UDP. > On 1 June 2015 at 01:25, Slawa Olhovchenkov wrote: > > I am use Intel 82576 (igb driver) in netmap mode. > > I see isssuse: flow routed in different queue depends of IP flags. > > > > For example: > > > > Total 4 queue. > > UDP flow. > > SRC: 91.214.70.167:12062 DST: 95.31.64.226:49939 Flags:DF routed to queue 0 > > SRC: 91.214.70.167:12062 DST: 95.31.64.226:49939 Flags:More_Frags (offset 0, length 1396) routed to queue 3 > > > > I understand that next fragment (IP (tos 0x0, ttl 62, id 36361, offset > > 1376, flags [none], proto UDP (17), length 102) 91.214.70.167 > > > 95.72.171.116: ip-proto-17) may be routed in different queue, but why > > fragment 0 routed to different queue? This is software (driver, > > netmap) issuse? Or this is hardware (silicon) isssuse? > > > > What about Intel 10G/40G cards? Chelsio? > > > > _______________________________________________ > > 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 Jun 1 15:01:25 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA1C2261; Mon, 1 Jun 2015 15:01:25 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 849B51D36; Mon, 1 Jun 2015 15:01:25 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YzRDP-0004Xy-Jt; Mon, 01 Jun 2015 18:01:23 +0300 Date: Mon, 1 Jun 2015 18:01:23 +0300 From: Slawa Olhovchenkov To: Adrian Chadd Cc: FreeBSD Net Subject: Re: Intel igb 82576 (netmap mode) and RSS queue issuse with fragmented UDP packets. Message-ID: <20150601150123.GI1647@zxy.spb.ru> References: <20150601082509.GE1647@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 15:01:25 -0000 On Mon, Jun 01, 2015 at 07:53:51AM -0700, Adrian Chadd wrote: > oh, hm, you asked the next question. Sorry, I haven't had coffee. > > I vaguely remember testing this and discovering the /should/ be > putting all the frames in a packet int he same queue, as long as the > frames have a consistent set of fragment bits set. Ie, if you're doing > UDP and all frames in a packet have the fragment bit set, then all > fragments (first and the rest) go into the same queue. Frames in a > flow that are fragmented for some and not others (eg TCP flows with a > firewall/router doing explicit fragmentation, or a mix of small/large > UDP packets) will end up going into different queues. > > I can re-test this on ixgbe at some point, but IIRC that's how it behaved. > > I don't have the RSS stuff done for chelsio, so I haven't done any > experiments just yet. > > Now, I also remember that with the badly setup flowdirector code in > ixgbe it would mess that up, so the flowdir code was disabled in -HEAD > and I believe now in -10. I am expect that second and next fragments may distributed in different queue. This is acceptable for me. And I think workaround of this in driver/OS code may be very expensive (collect and save 5-tuple, expiration control of this hash and etc). But I am very surprised that _first_ fragment distributed in different queue. I.e. fragment with frag_offset==0. Only different with DF bit clear and MF bit set. I am don't check case with frag_offset==0, DF bit clear and MF bit clear. May be this is also distrebuted in different queue. From owner-freebsd-net@FreeBSD.ORG Mon Jun 1 15:56:58 2015 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6DBF4ED6; Mon, 1 Jun 2015 15:56:58 +0000 (UTC) (envelope-from juliank@tzi.de) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailhost.informatik.uni-bremen.de", Issuer "Universitaet Bremen CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 055EB1A6E; Mon, 1 Jun 2015 15:56:57 +0000 (UTC) (envelope-from juliank@tzi.de) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t51FupXS015042; Mon, 1 Jun 2015 17:56:51 +0200 (CEST) Received: from [192.168.9.46] (82-198-197-71.briteline.de [82.198.197.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3m0h2W2lPnz2crn; Mon, 1 Jun 2015 17:56:51 +0200 (CEST) Message-ID: <556C80C3.508@tzi.de> Date: Mon, 01 Jun 2015 17:56:51 +0200 From: Julian Kornberger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Andrey V. Elsukov" , "net@freebsd.org" Subject: Re: Crash with GRE und IPFW fwd References: <5566565A.7030200@tzi.de> <55671F25.5070308@FreeBSD.org> In-Reply-To: <55671F25.5070308@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 15:56:58 -0000 Am 28.05.2015 um 15:59 schrieb Andrey V. Elsukov: > Also can you try this module instead of one from your base system? > https://people.freebsd.org/~ae/gre-10.tgz > > This is ported to stable/10 version from 11.0-CURRENT. I installed your gre module and our system has been running for more than two hours now without a crash. Can I expect these changes to be merge merged into stable/10? Thanks a lot for your help! -- Julian From owner-freebsd-net@FreeBSD.ORG Mon Jun 1 18:01:14 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 162D4557; Mon, 1 Jun 2015 18:01:14 +0000 (UTC) (envelope-from che@bein.link) Received: from mail.bein.link (bein.link [37.252.124.82]) (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 D0668197B; Mon, 1 Jun 2015 18:01:12 +0000 (UTC) (envelope-from che@bein.link) Received: from thinkpad.localnet (home.bein.link [188.134.8.193]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bein.link (Postfix) with ESMTPSA id 729221AF1D1; Mon, 1 Jun 2015 18:01:02 +0000 (UTC) From: Maxim V Filimonov To: freebsd-current@freebsd.org Reply-To: che@bein.link Cc: Gleb Smirnoff , current@freebsd.org, net@freebsd.org Subject: Re: [Testers needed!] WiFi drivers changes Date: Mon, 01 Jun 2015 21:01:01 +0300 Message-ID: <3365697.2qFDXoZ9ho@thinkpad> User-Agent: KMail/4.14.3 (FreeBSD/10.1-RELEASE-p10; KDE/4.14.3; amd64; ; ) In-Reply-To: <20150529133535.GT73119@glebius.int.ru> References: <20150529133535.GT73119@glebius.int.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 18:01:14 -0000 On Friday 29 May 2015 16:35:35 Gleb Smirnoff wrote: > Hi! > > As part of the "opaque ifnet project" [1], we are doing some code shake > with all IEEE802.11 (read WiFi) drivers. The drivers, that provide a parent > interface for the wlan(4) interface. > > The core idea is that parent device loses its ifnet(9) structure. The > code is already complete for the stack, but only 2 drivers are converted > to new KPI: iwn(4) and bwi(4). We got 22 more drivers left. The changes > are quite mechanical, but nevertheless testing is required before > committing. > > So, if you run FreeBSD head and wlan(4), please sign up here as tester: > > https://wiki.freebsd.org/projects/ifnet/net80211 > Did I get it correctly that you don't need tests for iwn(4)? -- wbr, Maxim Filimonov From owner-freebsd-net@FreeBSD.ORG Mon Jun 1 20:51:06 2015 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 98DB6DC7 for ; Mon, 1 Jun 2015 20:51:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 66FAD1642 for ; Mon, 1 Jun 2015 20:51:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igbpi8 with SMTP id pi8so71485723igb.1 for ; Mon, 01 Jun 2015 13:51:05 -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=I/CJkRPAG+axMIzrQqUKB3f1wgTUlb++8eozb0dK4Kg=; b=t34Ary4BAA9TlG2F6ebbkKtfqBZu4h42qYMSu0oNEJS6zZ86hgta5QwR+6JVDY80vQ s58/RIPBgE26P8SQGIO0IN/ezQlDnlN5VXOOo2MU2uchIGJsfm3+rN2mbPZPY/4MhugG 1u3qsgLyf9Q1pfCV2jCZr9KpSQFD2dIyM6ROWRCXb1TV/M/46CS9pP2N8GkMZvhgGe9k VaC6XVtPKYXCx1UEH/iW5i2OX0OOtARGRESrMdbpIDTte8Ix2HbFGaOqBYnOqCFLDWa2 JqiT684BrqgrK29kIboauEyPsy5iNjzZMQ8wJx5Y60Azi83RXIL2TZBnRAdUPiph3rzw qS7A== MIME-Version: 1.0 X-Received: by 10.43.163.129 with SMTP id mo1mr30397598icc.61.1433191865751; Mon, 01 Jun 2015 13:51:05 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Mon, 1 Jun 2015 13:51:05 -0700 (PDT) In-Reply-To: <20150601145423.GH1647@zxy.spb.ru> References: <20150601082509.GE1647@zxy.spb.ru> <20150601145423.GH1647@zxy.spb.ru> Date: Mon, 1 Jun 2015 13:51:05 -0700 X-Google-Sender-Auth: clLgZz3PUxTiIw2x2mLHmEqXE8k Message-ID: Subject: Re: Intel igb 82576 (netmap mode) and RSS queue issuse with fragmented UDP packets. From: Adrian Chadd To: Slawa Olhovchenkov Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 20:51:06 -0000 On 1 June 2015 at 07:54, Slawa Olhovchenkov wrote: > On Mon, Jun 01, 2015 at 07:50:31AM -0700, Adrian Chadd wrote: > >> They all behave the same. You can fix the intel driver(s) by looking >> for the TCP/UDP queue config and only enabling IPv4/IPv6 (not TCP/UDP) >> hashing. > > Are you sure that enabling only IPv4/IPv6 hashing fix this? > I see hashing in may case depends from flags fields. > flags field is not part of TCP/UDP. Yes. Just try doing ipv4/ipv6 only hashing. See if that fixes it. -a > >> On 1 June 2015 at 01:25, Slawa Olhovchenkov wrote: >> > I am use Intel 82576 (igb driver) in netmap mode. >> > I see isssuse: flow routed in different queue depends of IP flags. >> > >> > For example: >> > >> > Total 4 queue. >> > UDP flow. >> > SRC: 91.214.70.167:12062 DST: 95.31.64.226:49939 Flags:DF routed to queue 0 >> > SRC: 91.214.70.167:12062 DST: 95.31.64.226:49939 Flags:More_Frags (offset 0, length 1396) routed to queue 3 >> > >> > I understand that next fragment (IP (tos 0x0, ttl 62, id 36361, offset >> > 1376, flags [none], proto UDP (17), length 102) 91.214.70.167 > >> > 95.72.171.116: ip-proto-17) may be routed in different queue, but why >> > fragment 0 routed to different queue? This is software (driver, >> > netmap) issuse? Or this is hardware (silicon) isssuse? >> > >> > What about Intel 10G/40G cards? Chelsio? >> > >> > _______________________________________________ >> > 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 Jun 1 21:18:47 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5D89D36; Mon, 1 Jun 2015 21:18:47 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 622E91C24; Mon, 1 Jun 2015 21:18:45 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id t51LIdRT030787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 2 Jun 2015 00:18:39 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t51LIdvW030786; Tue, 2 Jun 2015 00:18:39 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 2 Jun 2015 00:18:39 +0300 From: Gleb Smirnoff To: Maxim V Filimonov Cc: freebsd-current@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: [Testers needed!] WiFi drivers changes Message-ID: <20150601211839.GZ73119@glebius.int.ru> References: <20150529133535.GT73119@glebius.int.ru> <3365697.2qFDXoZ9ho@thinkpad> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3365697.2qFDXoZ9ho@thinkpad> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 21:18:47 -0000 On Mon, Jun 01, 2015 at 09:01:01PM +0300, Maxim V Filimonov wrote: M> > As part of the "opaque ifnet project" [1], we are doing some code shake M> > with all IEEE802.11 (read WiFi) drivers. The drivers, that provide a parent M> > interface for the wlan(4) interface. M> > M> > The core idea is that parent device loses its ifnet(9) structure. The M> > code is already complete for the stack, but only 2 drivers are converted M> > to new KPI: iwn(4) and bwi(4). We got 22 more drivers left. The changes M> > are quite mechanical, but nevertheless testing is required before M> > committing. M> > M> > So, if you run FreeBSD head and wlan(4), please sign up here as tester: M> > M> > https://wiki.freebsd.org/projects/ifnet/net80211 M> > M> M> Did I get it correctly that you don't need tests for iwn(4)? I've got one in my laptop and run it with the patch. However, extra testing never hurts :) -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Tue Jun 2 00:08:24 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 49C69250 for ; Tue, 2 Jun 2015 00:08:24 +0000 (UTC) (envelope-from caldweba@colorado.edu) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 115E615EF for ; Tue, 2 Jun 2015 00:08:23 +0000 (UTC) (envelope-from caldweba@colorado.edu) Received: by igbpi8 with SMTP id pi8so74637983igb.1 for ; Mon, 01 Jun 2015 17:08:23 -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:message-id:references:to; bh=ZNqFblsaGuhyVm3FhH1MlxyRFBFVWAgSTinnrgTaD8U=; b=TG2RiNUdxVMhtcqJWc0zBH+5/YDczDuP0mLx1UNYR7KRsA7RK6J8LOXU7g8YWfttVy TRg3oGREsCd3fOlWYs1J083ShYv1tGrqXNGYd5h2SczPz9//HyFuf9QfYiA4Wwt3EEvC SsEQNUGYEeEj+H+zIW49akPKnAddkry5clf+eAd4BTGQBS7YcV2npQ8PxS+JVst+xMFe QdPiFPWjvi6/JTXEtbKvHR50o7Oj/CKeENz1NjikDv0vZBHZs7ip5J+nFrl2fS9al5/K ELlu5IwYvQglEJ/Wy3eFoaEHxCu0BkR76aIIYRGJwgBeKDiCqke8e97LlDuhjDe7ciHf M47Q== X-Gm-Message-State: ALoCoQnKQ+EUf/O/OGoM2nwAN9SUDcbdM2kZJOC4b83nTrGaS+qt4uNQlNioUUKabJINxxcpIHrk X-Received: by 10.50.178.133 with SMTP id cy5mr16841631igc.5.1433203702849; Mon, 01 Jun 2015 17:08:22 -0700 (PDT) Received: from vpn-cuboulder30-125-dhcp.colorado.edu (vpn-cuboulder30-125-dhcp.colorado.edu. [198.11.30.125]) by mx.google.com with ESMTPSA id i185sm11491234ioi.24.2015.06.01.17.08.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Jun 2015 17:08:21 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: netmap and mlx4 driver status (linux) From: Blake Caldwell In-Reply-To: Date: Mon, 1 Jun 2015 18:08:20 -0600 Cc: "freebsd-net@freebsd.org" Message-Id: References: <3010CFE2-66B7-416B-92DE-C1B669CC33BE@colorado.edu> <555C9F30.8070405@selasky.org> To: Luigi Rizzo , Hans Petter Selasky , Oded Shanoon X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 00:08:24 -0000 Wondering if those experienced with other netmap drivers might be able = to comment what is limiting performance of mlx4. It seems that the = reason pkt-gen is only getting 2.4Mpps with mlx4 40G is that pkt-gen is = saturating a core. This clearly shouldn=92t be the case as evidenced by = netmap papers (14.8Mpps at 900Mz core). As would be expected, the = output from =91perf top=92 shows that sender_body and poll() are the = largest userspace CPU hogs (measured in % of samples=97over 24 cpus) 29.65% [netmap] [k] netmap_poll 12.47% [mlx4_en] [k] mlx4_netmap_txsync 8.69% libc-2.19.so [.] poll 6.15% pkt-gen [.] sender_body 2.26% [kernel] [k] local_clock 2.12% [kernel] [k] context_tracking_user_exit 1.87% [kernel] [k] select_estimate_accuracy 1.81% [kernel] [k] system_call =85. 1.24% [netmap] [k] nm_txsync_prologue =85. 0.63% [mlx4_en] [k] mlx4_en_arm_cq 0.61% [kernel] [k] account_user_time =20 Furthermore it appears from annotating the code in pkt-gen.c with = utilization, about 50% of sender_body is spent on this line while = iterating through the rings: https://github.com/caldweba/netmap/blob/master/examples/pkt-gen.c#L1091 = if (nm_ring_empty(txring)) Does this mean it is waiting for free slots most of the time and = increasing from 8 rings might help? Here are the current module parameters in case they shed light on the = issue. Also, netmap config kernel messages are shown below. Thanks in advance. /sys/module/netmap/parameters/adaptive_io: 0 /sys/module/netmap/parameters/admode: 0 /sys/module/netmap/parameters/bridge_batch: 1024 /sys/module/netmap/parameters/buf_curr_num: 163840 /sys/module/netmap/parameters/buf_curr_size: 2048 /sys/module/netmap/parameters/buf_num: 163840 /sys/module/netmap/parameters/buf_size: 2048 /sys/module/netmap/parameters/default_pipes: 0 /sys/module/netmap/parameters/flags: 0 /sys/module/netmap/parameters/fwd: 0 /sys/module/netmap/parameters/generic_mit: 100000 /sys/module/netmap/parameters/generic_rings: 1 /sys/module/netmap/parameters/generic_ringsize: 1024 /sys/module/netmap/parameters/if_curr_num: 100 /sys/module/netmap/parameters/if_curr_size: 1024 /sys/module/netmap/parameters/if_num: 100 /sys/module/netmap/parameters/if_size: 1024 /sys/module/netmap/parameters/mitigate: 1 /sys/module/netmap/parameters/mmap_unreg: 0 /sys/module/netmap/parameters/no_pendintr: 1 /sys/module/netmap/parameters/no_timestamp: 0 /sys/module/netmap/parameters/priv_buf_num: 4098 /sys/module/netmap/parameters/priv_buf_size: 2048 /sys/module/netmap/parameters/priv_if_num: 1 /sys/module/netmap/parameters/priv_if_size: 1024 /sys/module/netmap/parameters/priv_ring_num: 4 /sys/module/netmap/parameters/priv_ring_size: 20480 /sys/module/netmap/parameters/ring_curr_num: 200 /sys/module/netmap/parameters/ring_curr_size: 36864 /sys/module/netmap/parameters/ring_num: 200 /sys/module/netmap/parameters/ring_size: 36864 /sys/module/netmap/parameters/txsync_retry: 2 /sys/module/netmap/parameters/verbose: 0 > On May 28, 2015, at 12:47 AM, Blake Caldwell = wrote: >=20 > Hello, >=20 > I have made necessary tweaks to the mlx4 patches for a successful = build on Linux 3.13.11 (Ubuntu 14.04) and enabled the driver in the = Linux build system. See: > https://github.com/caldweba/netmap.git = for my additional commits. >=20 > Without any core modifications to the mlx4 netmap driver, I am = actually getting reduced performance, 2.5 Mpps on a 40G port. I=92m = interested in improving the performance of this driver, but as I=92m new = to netmap and even these drivers, some assistance would be welcome. As = Luigi mentioned, the Mellanox developer documentation seems to be a = stumbling point. Would anyone from Mellanox be able to lend some = expertise? >=20 > It would appear mlx4_netmap_txsync() is the place to focus = optimization, and the comments Luigi put in will be helpful. Although = I=92m a little confused the on the remaining work for = mlx4_netmap_tx_config (marked TODO). See = https://github.com/caldweba/netmap/blob/master/LINUX/mlx4_netmap_linux.h = = for Luigi=92s current mlx4_netmap_txsync() code. >=20 > Below is my output from pkt-gen and from ethtool on the device. >=20 > Best regards, > Blake >=20 > =97=97=97=97=97 > $ sudo build-apps/pkt-gen -i p2p1 -f tx -n 500111222 -l 60 -w 5 > 060.428278 main [1649] interface is p2p1 > 060.428770 extract_ip_range [287] range is 10.0.0.1:0 to 10.0.0.1:0 > 060.428782 extract_ip_range [287] range is 10.1.0.1:0 to 10.1.0.1:0 > 060.875064 main [1840] mapped 334980KB at 0x7fd1f04d5000 > Sending on netmap:p2p1: 8 queues, 1 threads and 1 cpus. > 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> ff:ff:ff:ff:ff:ff) > 060.875151 main [1924] Sending 512 packets every 0.000000000 s > 060.875158 main [1926] Wait 5 secs for phy reset > 065.875244 main [1928] Ready... > 065.875276 nm_open [456] overriding ifname p2p1 ringid 0x0 flags 0x1 > 065.914805 sender_body [1014] start, fd 4 main_fd 3 > 065.958284 sender_body [1083] drop copy > 066.915788 main_thread [1446] 2468560 pps (2471088 pkts in 1001024 = usec) > 067.916827 main_thread [1446] 2476292 pps (2478865 pkts in 1001039 = usec) > 068.917815 main_thread [1446] 2476261 pps (2478708 pkts in 1000988 = usec) > 069.918864 main_thread [1446] 2476232 pps (2478827 pkts in 1001048 = usec) > 070.919902 main_thread [1446] 2476031 pps (2478604 pkts in 1001039 = usec) > 071.920920 main_thread [1446] 2476304 pps (2478825 pkts in 1001018 = usec) > 072.921896 main_thread [1446] 2476349 pps (2478766 pkts in 1000976 = usec) > 073.922948 main_thread [1446] 2476327 pps (2478932 pkts in 1001052 = usec) > 074.923924 main_thread [1446] 2476301 pps (2478715 pkts in 1000975 = usec) > 075.924903 main_thread [1446] 2476257 pps (2478681 pkts in 1000979 = usec) > 076.925918 main_thread [1446] 2476195 pps (2478708 pkts in 1001015 = usec) > 077.926970 main_thread [1446] 2476242 pps (2478849 pkts in 1001053 = usec) >=20 > dmesg: > [52591.017469] mlx4_en: Mellanox ConnectX HCA Ethernet driver v2.2-1 = (Feb 2014) > [52591.017621] mlx4_en 0000:04:00.0: registered PHC clock > [52591.017780] mlx4_en 0000:04:00.0: Activating port:1 > [52591.023552] mlx4_en: eth0: Using 192 TX rings > [52591.023554] mlx4_en: eth0: Using 8 RX rings > [52591.023556] mlx4_en: eth0: frag:0 - size:1526 prefix:0 align:0 = stride:1536 > [52591.040585] mlx4_en: eth0: Initializing port > [52591.040732] 779.121252 [2720] netmap_attach success for = eth0 tx 8/512 rx 8/1024 queues/slots > [52591.060580] mlx4_en 0000:04:00.0: Activating port:2 > [52591.068337] mlx4_en: eth1: Using 192 TX rings > [52591.068340] mlx4_en: eth1: Using 8 RX rings > [52591.068342] mlx4_en: eth1: frag:0 - size:1526 prefix:0 align:0 = stride:1536 > [52591.085696] mlx4_en: eth1: Initializing port > [52591.085867] 779.166352 [2720] netmap_attach success for = eth1 tx 8/512 rx 8/1024 queues/slots > [52591.960730] mlx4_en: eth0: Link Up > [52593.029536] systemd-udevd[50993]: renamed network interface eth0 to = p2p1 > [52593.061736] systemd-udevd[50996]: renamed network interface eth1 to = rename28 > [52624.680481] mlx4_en: p2p1: frag:0 - size:1526 prefix:0 align:0 = stride:1536 > [52624.834109] 812.888289 [ 473] mlx4_en_tx_irq XXXXXXXXX = tx_irq 0 unexpected, ignoring >=20 > [55436.322304] 622.179577 [ 665] mlx4_netmap_config using only = 8 out of 192 tx queues > [55436.339688] 622.196947 [ 672] mlx4_netmap_config txr 8 txd = 512 bufsize 32768 -- rxr 8 rxd 1024 act 1024 bufsize 16384 > [55436.361877] 622.219119 [ 124] mlx4_netmap_reg setting = netmap mode for eth0 to ON > [55436.379345] 622.236575 [ 127] mlx4_netmap_reg unloading = eth0 > [55436.485781] 622.342926 [ 163] mlx4_netmap_reg loading = eth0 > [55436.501124] mlx4_en: p2p1: frag:0 - size:1526 prefix:0 align:0 = stride:1536 > [55436.517514] 622.374635 [ 628] mlx4_netmap_rx_config stride 16 = possible frags 1 descsize 0 DS_SIZE 16 > [55436.536462] 622.393570 [ 648] mlx4_netmap_rx_config ring 0 done > [55436.551746] 622.408842 [ 648] mlx4_netmap_rx_config ring 1 done > [55436.567111] 622.424194 [ 628] mlx4_netmap_rx_config stride 16 = possible frags 1 descsize 0 DS_SIZE 16 > [55436.586261] 622.443330 [ 648] mlx4_netmap_rx_config ring 2 done > [55436.601844] 622.458900 [ 648] mlx4_netmap_rx_config ring 3 done > [55436.617525] 622.474569 [ 648] mlx4_netmap_rx_config ring 4 done > [55436.633057] 622.490089 [ 648] mlx4_netmap_rx_config ring 5 done > [55436.648376] 622.505396 [ 648] mlx4_netmap_rx_config ring 6 done > [55436.780501] 622.637414 [ 165] mlx4_netmap_reg start_port = returns 0 > [55436.796403] mlx4_en: p2p1: Link Down > [55437.755281] mlx4_en: p2p1: Link Up >=20 >=20 > $ ethtool p2p1 > Settings for p2p1: > Supported ports: [ TP ] > Supported link modes: 10000baseT/Full=20 > Supported pause frame use: No > Supports auto-negotiation: No > Advertised link modes: 10000baseT/Full=20 > Advertised pause frame use: No > Advertised auto-negotiation: No > Speed: 40000Mb/s > Duplex: Full > Port: Twisted Pair > PHYAD: 0 > Transceiver: internal > Auto-negotiation: off > MDI-X: Unknown > Cannot get wake-on-lan settings: Operation not permitted > Current message level: 0x00000014 (20) > link ifdown > Link detected: yes >=20 > $ ethtool -i p2p1 > driver: mlx4_en > version: 2.2-1 (Feb 2014) > firmware-version: 2.30.3200 > bus-info: 0000:04:00.0 > supports-statistics: yes > supports-test: yes > supports-eeprom-access: no > supports-register-dump: no > supports-priv-flags: yes >=20 > ethtool -g p2p1 > Ring parameters for p2p1: > Pre-set maximums: > RX: 8192 > RX Mini: 0 > RX Jumbo: 0 > TX: 8192 > Current hardware settings: > RX: 1024 > RX Mini: 0 > RX Jumbo: 0 > TX: 512 >=20 > Coalesce parameters for p2p1: > Adaptive RX: on TX: off > stats-block-usecs: 0 > sample-interval: 0 > pkt-rate-low: 400000 > pkt-rate-high: 450000 >=20 > rx-usecs: 16 > rx-frames: 44 > rx-usecs-irq: 0 > rx-frames-irq: 0 >=20 > tx-usecs: 16 > tx-frames: 16 > tx-usecs-irq: 0 > tx-frames-irq: 0 >=20 > rx-usecs-low: 0 > rx-frame-low: 0 > tx-usecs-low: 0 > tx-frame-low: 0 >=20 > rx-usecs-high: 128 > rx-frame-high: 0 > tx-usecs-high: 0 > tx-frame-high: 0 >=20 > $ sudo ethtool -k p2p1 > Features for p2p1: > rx-checksumming: on > tx-checksumming: on > tx-checksum-ipv4: on > tx-checksum-ip-generic: off [fixed] > tx-checksum-ipv6: on > tx-checksum-fcoe-crc: off [fixed] > tx-checksum-sctp: off [fixed] > scatter-gather: on > tx-scatter-gather: on > tx-scatter-gather-fraglist: off [fixed] > tcp-segmentation-offload: on > tx-tcp-segmentation: on > tx-tcp-ecn-segmentation: off [fixed] > tx-tcp6-segmentation: on > udp-fragmentation-offload: off [fixed] > generic-segmentation-offload: on > generic-receive-offload: on > large-receive-offload: off [fixed] > rx-vlan-offload: on > tx-vlan-offload: on > ntuple-filters: off [fixed] > receive-hashing: on > highdma: on [fixed] > rx-vlan-filter: on [fixed] > vlan-challenged: off [fixed] > tx-lockless: off [fixed] > netns-local: off [fixed] > tx-gso-robust: off [fixed] > tx-fcoe-segmentation: off [fixed] > tx-gre-segmentation: off [fixed] > tx-ipip-segmentation: off [fixed] > tx-sit-segmentation: off [fixed] > tx-udp_tnl-segmentation: off [fixed] > tx-mpls-segmentation: off [fixed] > fcoe-mtu: off [fixed] > tx-nocache-copy: on > loopback: off > rx-fcs: off [fixed] > rx-all: off [fixed] > tx-vlan-stag-hw-insert: off [fixed] > rx-vlan-stag-hw-parse: off [fixed] > rx-vlan-stag-filter: off [fixed] > l2-fwd-offload: off [fixed] >=20 >=20 >> On May 20, 2015, at 9:18 AM, Luigi Rizzo > wrote: >>=20 >> hi all, >>=20 >> the mlx4 netmap patch (for linux only) was something i did long >> ago when i had some mellanox hardware available, but no documentation >> so i had to resort to interpreting what the linux driver did. >>=20 >> At the time i had the following performance (on PCIe v2 bus): >>=20 >> 10G ports: tx/rx at about 7 Mpps with 64 byte packets >> could saturate the link with 192 or 256 byte packets >>=20 >> 40G ports: tx/rx at about 11 Mpps with 64 byte packets >> max 28 Gbit/s even with 1500 byte frames >>=20 >> I don't know if the limited performance was due to bus, >> firmware or lack of documentation, anyways this is not >> something i can or want to deal with. >>=20 >> My understanding is that Mellanox does not release programming >> documentation, so the only way to have native netmap support >> for that card would be to have Mellanox work on that and >> provide a suitable patch. >>=20 >> I do not expect more than a week's work (the typical extra >> code in each driver is about 500 lines, and very simple) >> for someone with access to documentation. Also, the patch >> for FreeBSD and Linux is typically very similar so once we >> have a driver for one, the other would be trivial. >>=20 >> It would be of course great to add Mellanox to the list of >> devices with native netmap support, together with Chelsio >> and Intel. >>=20 >> Perhaps Hans (who may have contacts) can talk to the right >> people and figure out. On my side, I am happy to give directions >> on what needs to be done and import any patch that should >> be made available. >>=20 >> cheers >> luigi >>=20 >> On Wed, May 20, 2015 at 4:50 PM, Hans Petter Selasky > wrote: >> On 05/20/15 16:13, Blake Caldwell wrote: >> Hello, >>=20 >> I noticed that the mlx4_en patch for netmap is LINUX/wip-patches, so = they are not enabled in the normal build process. I=92m curious about = the status of mlx4 support? >>=20 >> If additional work to the patches is needed, any details as to what = the issues were. >>=20 >> Any info would be great! Thanks in advance! >>=20 >>=20 >> Hi Blake, >>=20 >> The MLX4 driver is being actively maintained in -stable and -current. = Regarding netmap support for the FreeBSD MLX4 en driver, I'm not sure. = Maybe Oded knows, CC'ed? Do you have a link for the patch you are = referring? >>=20 >> This there any particular use-case you are interested in? >>=20 >> --HPS >>=20 >>=20 >> _______________________________________________ >> 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 >>=20 >>=20 >> --=20 >> = -----------------------------------------+------------------------------- >> Prof. Luigi RIZZO, rizzo@iet.unipi.it . = Dip. di Ing. dell'Informazione >> http://www.iet.unipi.it/~luigi/ = . Universita` di Pisa >> TEL +39-050-2217533 . via Diotisalvi 2 >> Mobile +39-338-6809875 . 56122 PISA (Italy) >> = -----------------------------------------+------------------------------- >=20 From owner-freebsd-net@FreeBSD.ORG Tue Jun 2 11:13:37 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9DD4DE8A for ; Tue, 2 Jun 2015 11:13:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6E00D1533 for ; Tue, 2 Jun 2015 11:13:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t52BDbnq024235 for ; Tue, 2 Jun 2015 11:13:37 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194264] race between unp_dispose (called from sofree) and unp_gc Date: Tue, 02 Jun 2015 11:13:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: johan@300.nl X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 11:13:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194264 johans changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |johan@300.nl --- Comment #3 from johans --- Is there anything known more on this bug? We're getting the same (or similar) panic on 10.1-RELENG (with few custom patches backported from 10-STABLE). #0 doadump (textdump=) at pcpu.h:219 #1 0xffffffff8091e882 in kern_reboot (howto=260) at /release/usr/src/sys/kern/kern_shutdown.c:452 #2 0xffffffff8091ed75 in vpanic (fmt=, ap=) at /release/usr/src/sys/kern/kern_shutdown.c:759 #3 0xffffffff8091edc3 in panic (fmt=0x0) at /release/usr/src/sys/kern/kern_shutdown.c:688 #4 0xffffffff80d1fc7f in trap_fatal (frame=, eva=) at /release/usr/src/sys/amd64/amd64/trap.c:865 #5 0xffffffff80d1f8d8 in trap (frame=) at /release/usr/src/sys/amd64/amd64/trap.c:203 #6 0xffffffff80d03972 in calltrap () at /release/usr/src/sys/amd64/amd64/exception.S:232 #7 0xffffffff809a4148 in unp_gc (arg=0x8, pending=24) at /release/usr/src/sys/kern/uipc_usrreq.c:2152 #8 0xffffffff80967030 in taskqueue_run_locked (queue=0xfffff80003f99e00) at /release/usr/src/sys/kern/subr_taskqueue.c:342 #9 0xffffffff8096799b in taskqueue_thread_loop (arg=) at /release/usr/src/sys/kern/subr_taskqueue.c:563 #10 0xffffffff808ee384 in fork_exit (callout=0xffffffff80967900 , arg=0xffffffff8166c160, frame=0xfffffe03ce7e5c00) at /release/usr/src/sys/kern/kern_fork.c:996 #11 0xffffffff80d03eae in fork_trampoline () at /release/usr/src/sys/amd64/amd64/exception.S:606 #12 0x0000000000000000 in ?? () We have kernel dumps available if needed. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Jun 2 15:40:05 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C4599D9 for ; Tue, 2 Jun 2015 15:40:05 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 314D81BB0 for ; Tue, 2 Jun 2015 15:40:05 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igblz2 with SMTP id lz2so13792904igb.1 for ; Tue, 02 Jun 2015 08:40:04 -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=pNGTmt1pb4Wm518rAAulS3X5sH4oesJMmxqhwiZ9Rsc=; b=byBWzTbqZDsSMTRF9psfAy3IZ+J3AqoVzrKAEY/c5Dc4uqPMlsKeUyK12hEafMm9eJ hz8XvHOu0JZfnwhSdEg9dCXNxP+DRd3bI9MscCH6gyWqN2e1cV30a/MsgqbDLwnnGJBm SgGk24ARo817jI71N37oRrbcEP1/KygMpgTUMruyVrBPqPYHu4nOegKJcTtYZtkHQjmU epb4883YPG7YuG7XD38j6mF3nsQY5Xrgp3ZnvAI+2WNBewTQ+8LTvXU82JLpAFyWS4cM TSPeXst4aRmUmj3yRZOTrY6ia3rVJ6XUHeBWb//UpsK092lddYm16DDc7yVMupVJbHqB OYvA== MIME-Version: 1.0 X-Received: by 10.107.11.26 with SMTP id v26mr10767094ioi.8.1433259604613; Tue, 02 Jun 2015 08:40:04 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Tue, 2 Jun 2015 08:40:04 -0700 (PDT) In-Reply-To: References: <3010CFE2-66B7-416B-92DE-C1B669CC33BE@colorado.edu> <555C9F30.8070405@selasky.org> Date: Tue, 2 Jun 2015 08:40:04 -0700 X-Google-Sender-Auth: 7VvY9HH1_xcoPL--kV2c_BlZUkI Message-ID: Subject: Re: netmap and mlx4 driver status (linux) From: Adrian Chadd To: Blake Caldwell Cc: Luigi Rizzo , Hans Petter Selasky , Oded Shanoon , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 15:40:05 -0000 Hi, You'll likely want to poke the linux mellanox driver maintainer for some he= lp. -adrian On 1 June 2015 at 17:08, Blake Caldwell wrote: > Wondering if those experienced with other netmap drivers might be able to= comment what is limiting performance of mlx4. It seems that the reason pk= t-gen is only getting 2.4Mpps with mlx4 40G is that pkt-gen is saturating a= core. This clearly shouldn=E2=80=99t be the case as evidenced by netmap pa= pers (14.8Mpps at 900Mz core). As would be expected, the output from =E2= =80=98perf top=E2=80=99 shows that sender_body and poll() are the largest u= serspace CPU hogs (measured in % of samples=E2=80=94over 24 cpus) > > 29.65% [netmap] [k] netmap_poll > 12.47% [mlx4_en] [k] mlx4_netmap_txsync > 8.69% libc-2.19.so [.] poll > 6.15% pkt-gen [.] sender_body > 2.26% [kernel] [k] local_clock > 2.12% [kernel] [k] context_tracking_user_exit > 1.87% [kernel] [k] select_estimate_accuracy > 1.81% [kernel] [k] system_call > =E2=80=A6. > 1.24% [netmap] [k] nm_txsync_prologue > =E2=80=A6. > 0.63% [mlx4_en] [k] mlx4_en_arm_cq > 0.61% [kernel] [k] account_user_time > > > Furthermore it appears from annotating the code in pkt-gen.c with utiliza= tion, about 50% of sender_body is spent on this line while iterating throug= h the rings: > https://github.com/caldweba/netmap/blob/master/examples/pkt-gen.c#L1091 <= https://github.com/caldweba/netmap/blob/master/examples/pkt-gen.c#L1091> > if (nm_ring_empty(txring)) > > Does this mean it is waiting for free slots most of the time and increasi= ng from 8 rings might help? > > Here are the current module parameters in case they shed light on the iss= ue. Also, netmap config kernel messages are shown below. > > Thanks in advance. > > /sys/module/netmap/parameters/adaptive_io: 0 > /sys/module/netmap/parameters/admode: 0 > /sys/module/netmap/parameters/bridge_batch: 1024 > /sys/module/netmap/parameters/buf_curr_num: 163840 > /sys/module/netmap/parameters/buf_curr_size: 2048 > /sys/module/netmap/parameters/buf_num: 163840 > /sys/module/netmap/parameters/buf_size: 2048 > /sys/module/netmap/parameters/default_pipes: 0 > /sys/module/netmap/parameters/flags: 0 > /sys/module/netmap/parameters/fwd: 0 > /sys/module/netmap/parameters/generic_mit: 100000 > /sys/module/netmap/parameters/generic_rings: 1 > /sys/module/netmap/parameters/generic_ringsize: 1024 > /sys/module/netmap/parameters/if_curr_num: 100 > /sys/module/netmap/parameters/if_curr_size: 1024 > /sys/module/netmap/parameters/if_num: 100 > /sys/module/netmap/parameters/if_size: 1024 > /sys/module/netmap/parameters/mitigate: 1 > /sys/module/netmap/parameters/mmap_unreg: 0 > /sys/module/netmap/parameters/no_pendintr: 1 > /sys/module/netmap/parameters/no_timestamp: 0 > /sys/module/netmap/parameters/priv_buf_num: 4098 > /sys/module/netmap/parameters/priv_buf_size: 2048 > /sys/module/netmap/parameters/priv_if_num: 1 > /sys/module/netmap/parameters/priv_if_size: 1024 > /sys/module/netmap/parameters/priv_ring_num: 4 > /sys/module/netmap/parameters/priv_ring_size: 20480 > /sys/module/netmap/parameters/ring_curr_num: 200 > /sys/module/netmap/parameters/ring_curr_size: 36864 > /sys/module/netmap/parameters/ring_num: 200 > /sys/module/netmap/parameters/ring_size: 36864 > /sys/module/netmap/parameters/txsync_retry: 2 > /sys/module/netmap/parameters/verbose: 0 > > >> On May 28, 2015, at 12:47 AM, Blake Caldwell wro= te: >> >> Hello, >> >> I have made necessary tweaks to the mlx4 patches for a successful build = on Linux 3.13.11 (Ubuntu 14.04) and enabled the driver in the Linux build s= ystem. See: >> https://github.com/caldweba/netmap.git for my additional commits. >> >> Without any core modifications to the mlx4 netmap driver, I am actually = getting reduced performance, 2.5 Mpps on a 40G port. I=E2=80=99m interested= in improving the performance of this driver, but as I=E2=80=99m new to net= map and even these drivers, some assistance would be welcome. As Luigi ment= ioned, the Mellanox developer documentation seems to be a stumbling point. = Would anyone from Mellanox be able to lend some expertise? >> >> It would appear mlx4_netmap_txsync() is the place to focus optimization,= and the comments Luigi put in will be helpful. Although I=E2=80=99m a litt= le confused the on the remaining work for mlx4_netmap_tx_config (marked TOD= O). See https://github.com/caldweba/netmap/blob/master/LINUX/mlx4_netmap_li= nux.h for Luigi=E2=80=99s current mlx4_netmap_txsync() code. >> >> Below is my output from pkt-gen and from ethtool on the device. >> >> Best regards, >> Blake >> >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >> $ sudo build-apps/pkt-gen -i p2p1 -f tx -n 500111222 -l 60 -w 5 >> 060.428278 main [1649] interface is p2p1 >> 060.428770 extract_ip_range [287] range is 10.0.0.1:0 to 10.0.0.1:0 >> 060.428782 extract_ip_range [287] range is 10.1.0.1:0 to 10.1.0.1:0 >> 060.875064 main [1840] mapped 334980KB at 0x7fd1f04d5000 >> Sending on netmap:p2p1: 8 queues, 1 threads and 1 cpus. >> 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> ff:ff:ff:ff:ff:ff) >> 060.875151 main [1924] Sending 512 packets every 0.000000000 s >> 060.875158 main [1926] Wait 5 secs for phy reset >> 065.875244 main [1928] Ready... >> 065.875276 nm_open [456] overriding ifname p2p1 ringid 0x0 flags 0x1 >> 065.914805 sender_body [1014] start, fd 4 main_fd 3 >> 065.958284 sender_body [1083] drop copy >> 066.915788 main_thread [1446] 2468560 pps (2471088 pkts in 1001024 usec) >> 067.916827 main_thread [1446] 2476292 pps (2478865 pkts in 1001039 usec) >> 068.917815 main_thread [1446] 2476261 pps (2478708 pkts in 1000988 usec) >> 069.918864 main_thread [1446] 2476232 pps (2478827 pkts in 1001048 usec) >> 070.919902 main_thread [1446] 2476031 pps (2478604 pkts in 1001039 usec) >> 071.920920 main_thread [1446] 2476304 pps (2478825 pkts in 1001018 usec) >> 072.921896 main_thread [1446] 2476349 pps (2478766 pkts in 1000976 usec) >> 073.922948 main_thread [1446] 2476327 pps (2478932 pkts in 1001052 usec) >> 074.923924 main_thread [1446] 2476301 pps (2478715 pkts in 1000975 usec) >> 075.924903 main_thread [1446] 2476257 pps (2478681 pkts in 1000979 usec) >> 076.925918 main_thread [1446] 2476195 pps (2478708 pkts in 1001015 usec) >> 077.926970 main_thread [1446] 2476242 pps (2478849 pkts in 1001053 usec) >> >> dmesg: >> [52591.017469] mlx4_en: Mellanox ConnectX HCA Ethernet driver v2.2-1 (Fe= b 2014) >> [52591.017621] mlx4_en 0000:04:00.0: registered PHC clock >> [52591.017780] mlx4_en 0000:04:00.0: Activating port:1 >> [52591.023552] mlx4_en: eth0: Using 192 TX rings >> [52591.023554] mlx4_en: eth0: Using 8 RX rings >> [52591.023556] mlx4_en: eth0: frag:0 - size:1526 prefix:0 align:0 stri= de:1536 >> [52591.040585] mlx4_en: eth0: Initializing port >> [52591.040732] 779.121252 [2720] netmap_attach success for e= th0 tx 8/512 rx 8/1024 queues/slots >> [52591.060580] mlx4_en 0000:04:00.0: Activating port:2 >> [52591.068337] mlx4_en: eth1: Using 192 TX rings >> [52591.068340] mlx4_en: eth1: Using 8 RX rings >> [52591.068342] mlx4_en: eth1: frag:0 - size:1526 prefix:0 align:0 stri= de:1536 >> [52591.085696] mlx4_en: eth1: Initializing port >> [52591.085867] 779.166352 [2720] netmap_attach success for e= th1 tx 8/512 rx 8/1024 queues/slots >> [52591.960730] mlx4_en: eth0: Link Up >> [52593.029536] systemd-udevd[50993]: renamed network interface eth0 to p= 2p1 >> [52593.061736] systemd-udevd[50996]: renamed network interface eth1 to r= ename28 >> [52624.680481] mlx4_en: p2p1: frag:0 - size:1526 prefix:0 align:0 stri= de:1536 >> [52624.834109] 812.888289 [ 473] mlx4_en_tx_irq XXXXXXXXX tx= _irq 0 unexpected, ignoring >> >> [55436.322304] 622.179577 [ 665] mlx4_netmap_config using only 8 = out of 192 tx queues >> [55436.339688] 622.196947 [ 672] mlx4_netmap_config txr 8 txd 512= bufsize 32768 -- rxr 8 rxd 1024 act 1024 bufsize 16384 >> [55436.361877] 622.219119 [ 124] mlx4_netmap_reg setting netma= p mode for eth0 to ON >> [55436.379345] 622.236575 [ 127] mlx4_netmap_reg unloading eth= 0 >> [55436.485781] 622.342926 [ 163] mlx4_netmap_reg loading eth0 >> [55436.501124] mlx4_en: p2p1: frag:0 - size:1526 prefix:0 align:0 stri= de:1536 >> [55436.517514] 622.374635 [ 628] mlx4_netmap_rx_config stride 16 pos= sible frags 1 descsize 0 DS_SIZE 16 >> [55436.536462] 622.393570 [ 648] mlx4_netmap_rx_config ring 0 done >> [55436.551746] 622.408842 [ 648] mlx4_netmap_rx_config ring 1 done >> [55436.567111] 622.424194 [ 628] mlx4_netmap_rx_config stride 16 pos= sible frags 1 descsize 0 DS_SIZE 16 >> [55436.586261] 622.443330 [ 648] mlx4_netmap_rx_config ring 2 done >> [55436.601844] 622.458900 [ 648] mlx4_netmap_rx_config ring 3 done >> [55436.617525] 622.474569 [ 648] mlx4_netmap_rx_config ring 4 done >> [55436.633057] 622.490089 [ 648] mlx4_netmap_rx_config ring 5 done >> [55436.648376] 622.505396 [ 648] mlx4_netmap_rx_config ring 6 done >> [55436.780501] 622.637414 [ 165] mlx4_netmap_reg start_port re= turns 0 >> [55436.796403] mlx4_en: p2p1: Link Down >> [55437.755281] mlx4_en: p2p1: Link Up >> >> >> $ ethtool p2p1 >> Settings for p2p1: >> Supported ports: [ TP ] >> Supported link modes: 10000baseT/Full >> Supported pause frame use: No >> Supports auto-negotiation: No >> Advertised link modes: 10000baseT/Full >> Advertised pause frame use: No >> Advertised auto-negotiation: No >> Speed: 40000Mb/s >> Duplex: Full >> Port: Twisted Pair >> PHYAD: 0 >> Transceiver: internal >> Auto-negotiation: off >> MDI-X: Unknown >> Cannot get wake-on-lan settings: Operation not permitted >> Current message level: 0x00000014 (20) >> link ifdown >> Link detected: yes >> >> $ ethtool -i p2p1 >> driver: mlx4_en >> version: 2.2-1 (Feb 2014) >> firmware-version: 2.30.3200 >> bus-info: 0000:04:00.0 >> supports-statistics: yes >> supports-test: yes >> supports-eeprom-access: no >> supports-register-dump: no >> supports-priv-flags: yes >> >> ethtool -g p2p1 >> Ring parameters for p2p1: >> Pre-set maximums: >> RX: 8192 >> RX Mini: 0 >> RX Jumbo: 0 >> TX: 8192 >> Current hardware settings: >> RX: 1024 >> RX Mini: 0 >> RX Jumbo: 0 >> TX: 512 >> >> Coalesce parameters for p2p1: >> Adaptive RX: on TX: off >> stats-block-usecs: 0 >> sample-interval: 0 >> pkt-rate-low: 400000 >> pkt-rate-high: 450000 >> >> rx-usecs: 16 >> rx-frames: 44 >> rx-usecs-irq: 0 >> rx-frames-irq: 0 >> >> tx-usecs: 16 >> tx-frames: 16 >> tx-usecs-irq: 0 >> tx-frames-irq: 0 >> >> rx-usecs-low: 0 >> rx-frame-low: 0 >> tx-usecs-low: 0 >> tx-frame-low: 0 >> >> rx-usecs-high: 128 >> rx-frame-high: 0 >> tx-usecs-high: 0 >> tx-frame-high: 0 >> >> $ sudo ethtool -k p2p1 >> Features for p2p1: >> rx-checksumming: on >> tx-checksumming: on >> tx-checksum-ipv4: on >> tx-checksum-ip-generic: off [fixed] >> tx-checksum-ipv6: on >> tx-checksum-fcoe-crc: off [fixed] >> tx-checksum-sctp: off [fixed] >> scatter-gather: on >> tx-scatter-gather: on >> tx-scatter-gather-fraglist: off [fixed] >> tcp-segmentation-offload: on >> tx-tcp-segmentation: on >> tx-tcp-ecn-segmentation: off [fixed] >> tx-tcp6-segmentation: on >> udp-fragmentation-offload: off [fixed] >> generic-segmentation-offload: on >> generic-receive-offload: on >> large-receive-offload: off [fixed] >> rx-vlan-offload: on >> tx-vlan-offload: on >> ntuple-filters: off [fixed] >> receive-hashing: on >> highdma: on [fixed] >> rx-vlan-filter: on [fixed] >> vlan-challenged: off [fixed] >> tx-lockless: off [fixed] >> netns-local: off [fixed] >> tx-gso-robust: off [fixed] >> tx-fcoe-segmentation: off [fixed] >> tx-gre-segmentation: off [fixed] >> tx-ipip-segmentation: off [fixed] >> tx-sit-segmentation: off [fixed] >> tx-udp_tnl-segmentation: off [fixed] >> tx-mpls-segmentation: off [fixed] >> fcoe-mtu: off [fixed] >> tx-nocache-copy: on >> loopback: off >> rx-fcs: off [fixed] >> rx-all: off [fixed] >> tx-vlan-stag-hw-insert: off [fixed] >> rx-vlan-stag-hw-parse: off [fixed] >> rx-vlan-stag-filter: off [fixed] >> l2-fwd-offload: off [fixed] >> >> >>> On May 20, 2015, at 9:18 AM, Luigi Rizzo > wrote: >>> >>> hi all, >>> >>> the mlx4 netmap patch (for linux only) was something i did long >>> ago when i had some mellanox hardware available, but no documentation >>> so i had to resort to interpreting what the linux driver did. >>> >>> At the time i had the following performance (on PCIe v2 bus): >>> >>> 10G ports: tx/rx at about 7 Mpps with 64 byte packets >>> could saturate the link with 192 or 256 byte packets >>> >>> 40G ports: tx/rx at about 11 Mpps with 64 byte packets >>> max 28 Gbit/s even with 1500 byte frames >>> >>> I don't know if the limited performance was due to bus, >>> firmware or lack of documentation, anyways this is not >>> something i can or want to deal with. >>> >>> My understanding is that Mellanox does not release programming >>> documentation, so the only way to have native netmap support >>> for that card would be to have Mellanox work on that and >>> provide a suitable patch. >>> >>> I do not expect more than a week's work (the typical extra >>> code in each driver is about 500 lines, and very simple) >>> for someone with access to documentation. Also, the patch >>> for FreeBSD and Linux is typically very similar so once we >>> have a driver for one, the other would be trivial. >>> >>> It would be of course great to add Mellanox to the list of >>> devices with native netmap support, together with Chelsio >>> and Intel. >>> >>> Perhaps Hans (who may have contacts) can talk to the right >>> people and figure out. On my side, I am happy to give directions >>> on what needs to be done and import any patch that should >>> be made available. >>> >>> cheers >>> luigi >>> >>> On Wed, May 20, 2015 at 4:50 PM, Hans Petter Selasky > wrote: >>> On 05/20/15 16:13, Blake Caldwell wrote: >>> Hello, >>> >>> I noticed that the mlx4_en patch for netmap is LINUX/wip-patches, so th= ey are not enabled in the normal build process. I=E2=80=99m curious about t= he status of mlx4 support? >>> >>> If additional work to the patches is needed, any details as to what the= issues were. >>> >>> Any info would be great! Thanks in advance! >>> >>> >>> Hi Blake, >>> >>> The MLX4 driver is being actively maintained in -stable and -current. R= egarding netmap support for the FreeBSD MLX4 en driver, I'm not sure. Maybe= Oded knows, CC'ed? Do you have a link for the patch you are referring? >>> >>> This there any particular use-case you are interested in? >>> >>> --HPS >>> >>> >>> _______________________________________________ >>> 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 <= mailto:freebsd-net-unsubscribe@freebsd.org>" >>> >>> >>> >>> -- >>> -----------------------------------------+-----------------------------= -- >>> Prof. Luigi RIZZO, rizzo@iet.unipi.it . D= ip. di Ing. dell'Informazione >>> http://www.iet.unipi.it/~luigi/ = . Universita` di Pisa >>> TEL +39-050-2217533 . via Diotisalvi 2 >>> Mobile +39-338-6809875 . 56122 PISA (Italy) >>> -----------------------------------------+-----------------------------= -- >> > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Jun 2 16:23:24 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6349D6DE; Tue, 2 Jun 2015 16:23:24 +0000 (UTC) (envelope-from helpdesk@sealnet.de) Received: from mxout.sealnet.de (mxout.sealnet.de [194.77.96.6]) by mx1.freebsd.org (Postfix) with ESMTP id CB4E318ED; Tue, 2 Jun 2015 16:23:23 +0000 (UTC) (envelope-from helpdesk@sealnet.de) Received: from sealnet.de ([10.13.2.41]) by mxout.sealnet.de (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id t52GLKMS010062; Tue, 2 Jun 2015 18:21:21 +0200 Received: from DOM_RZ-MTA by sealnet.de with Novell_GroupWise; Tue, 02 Jun 2015 18:20:37 +0200 Message-Id: <556DF3D9020000D100008E2A@sealnet.de> X-Mailer: Novell GroupWise Internet Agent 14.0.1 Date: Tue, 02 Jun 2015 18:20:40 +0200 From: "HelpDesk SEALNET" To: Cc: , , , , Subject: Re: netmap and mlx4 driver status (linux) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-Disposition: inline X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 16:23:24 -0000 -- von unterwegs gesendet. > Am 02.06.2015 um 17:40 schrieb Adrian Chadd : > > Hi, > > You'll likely want to poke the linux mellanox driver maintainer for some help. > > > > -adrian > > >> On 1 June 2015 at 17:08, Blake Caldwell wrote: >> Wondering if those experienced with other netmap drivers might be able to comment what is limiting performance of mlx4. It seems that the reason pkt-gen is only getting 2.4Mpps with mlx4 40G is that pkt-gen is saturating a core. This clearly shouldn’t be the case as evidenced by netmap papers (14.8Mpps at 900Mz core). As would be expected, the output from ‘perf top’ shows that sender_body and poll() are the largest userspace CPU hogs (measured in % of samples—over 24 cpus) >> >> 29.65% [netmap] [k] netmap_poll >> 12.47% [mlx4_en] [k] mlx4_netmap_txsync >> 8.69% libc-2.19.so [.] poll >> 6.15% pkt-gen [.] sender_body >> 2.26% [kernel] [k] local_clock >> 2.12% [kernel] [k] context_tracking_user_exit >> 1.87% [kernel] [k] select_estimate_accuracy >> 1.81% [kernel] [k] system_call >> …. >> 1.24% [netmap] [k] nm_txsync_prologue >> …. >> 0.63% [mlx4_en] [k] mlx4_en_arm_cq >> 0.61% [kernel] [k] account_user_time >> >> >> Furthermore it appears from annotating the code in pkt-gen.c with utilization, about 50% of sender_body is spent on this line while iterating through the rings: >> https://github.com/caldweba/netmap/blob/master/examples/pkt-gen.c#L1091 >> if (nm_ring_empty(txring)) >> >> Does this mean it is waiting for free slots most of the time and increasing from 8 rings might help? >> >> Here are the current module parameters in case they shed light on the issue. Also, netmap config kernel messages are shown below. >> >> Thanks in advance. >> >> /sys/module/netmap/parameters/adaptive_io: 0 >> /sys/module/netmap/parameters/admode: 0 >> /sys/module/netmap/parameters/bridge_batch: 1024 >> /sys/module/netmap/parameters/buf_curr_num: 163840 >> /sys/module/netmap/parameters/buf_curr_size: 2048 >> /sys/module/netmap/parameters/buf_num: 163840 >> /sys/module/netmap/parameters/buf_size: 2048 >> /sys/module/netmap/parameters/default_ From owner-freebsd-net@FreeBSD.ORG Wed Jun 3 12:40:43 2015 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 063B2A77 for ; Wed, 3 Jun 2015 12:40:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E527219DA for ; Wed, 3 Jun 2015 12:40:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t53CegGa039559 for ; Wed, 3 Jun 2015 12:40:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 200221] em0 watchdog timeout under load Date: Wed, 03 Jun 2015 12:40:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: anthony@ury.org.uk X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 12:40:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200221 --- Comment #7 from anthony@ury.org.uk --- I've now built a 10.1-RELEASE-p10 kernel with sys/dev/e1000 rolled back to before 269196. tso4 is enabled, I'll test this out over a few days and see what happens. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Jun 3 13:37:04 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9A46760 for ; Wed, 3 Jun 2015 13:37:04 +0000 (UTC) (envelope-from gpillai@vmware.com) Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [208.91.2.12]) (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 7C6311823 for ; Wed, 3 Jun 2015 13:37:04 +0000 (UTC) (envelope-from gpillai@vmware.com) Received: from sc9-mailhost2.vmware.com (sc9-mailhost2.vmware.com [10.113.161.72]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 8E65928BD3 for ; Wed, 3 Jun 2015 06:31:38 -0700 (PDT) Received: from EX13-CAS-004.vmware.com (EX13-CAS-004.vmware.com [10.113.191.54]) by sc9-mailhost2.vmware.com (Postfix) with ESMTP id 8BF1BB02F0 for ; Wed, 3 Jun 2015 06:31:38 -0700 (PDT) Received: from EX13-MBX-TERM.vmware.com (10.113.191.143) by EX13-MBX-014.vmware.com (10.113.191.34) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 3 Jun 2015 06:31:38 -0700 Received: from EX13-MBX-018.vmware.com (10.113.191.38) by EX13-MBX-TERM.vmware.com (10.113.191.143) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 3 Jun 2015 06:31:25 -0700 Received: from EX13-MBX-018.vmware.com ([fe80::7cdc:b1ba:f507:8b02]) by EX13-MBX-018.vmware.com ([fe80::7cdc:b1ba:f507:8b02%15]) with mapi id 15.00.0913.011; Wed, 3 Jun 2015 06:31:07 -0700 From: Gopakumar Pillai To: "freebsd-net@freebsd.org" Subject: FreeBSD 8.x - ifa -> ifp refcount Thread-Topic: FreeBSD 8.x - ifa -> ifp refcount Thread-Index: AQHQngGLdHP5Ry4nnkua+5BDM/r4iA== Date: Wed, 3 Jun 2015 13:31:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.113.160.246] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 13:37:04 -0000 Hi, I am using FreeBSD 8.x with some modifications. The question I have is that no reference count is taken when ifa is pointed= to ifp. There are cases when I encounter issues like ifa is alive and has = a pointer to ifp, but ifp itself is deleted. Looks like we expect all ifa entries to be gone when ifp is being deleted. = In FreeBSD 8.x we store the ifa address inside mbufs (for IPv6), which take= s an ifa refcount when one accesses it (but not when added, which is probab= ly wrong). Hence there are more chances that the mbuf may be around (and t= he ifa) when an interface is being deleted. Solution: Was thinking of incrementing the refcount of ifp when ifa points = to it, thus the ifp goes away only after the last ifa (or the last mbuf wit= h the ifa pointer) is gone. I do not see that FreeBSD 11.x is doing this either. There must be a reason= as to why it is so. Can one of the gurus explain why it is so or whether = I am wrong in my assumption. Thank You -Gopu From owner-freebsd-net@FreeBSD.ORG Wed Jun 3 14:59:49 2015 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 99C11317 for ; Wed, 3 Jun 2015 14:59:49 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 67DA31C4B for ; Wed, 3 Jun 2015 14:59:49 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by igbyr2 with SMTP id yr2so114946955igb.0 for ; Wed, 03 Jun 2015 07:59:48 -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=8pDgCJCz7tNyLzVe+MEw+hVxlvOZINzG9edKgnD6iHk=; b=NDdkH+R82y5ElKstk7LydTCMZedNGH5D0oRU3AuuKncDlHENmr4dqD8Q73uZebVXve gWFOiPNEo2LYS8AwYGRNpujONqXmhzWDUu0w4WYK/bdrigafh+cOucCz2EEiL3Byv3b8 zF00v5lO7rmM4dLfaY4dfrvfHn0awV1bDCpsRVj8zHWBWZbF7jqByuhMhYK10Ny45B3M xFJusLI3vHweXc5+IgRfPAPB8VYsIrfiPGsN36jtzCmnI4hcVv18WTawaK0CXTrpkbdd BdEX4LPOgNdydaNuZYixQyjf6LUwfTqt7zOWBEmoYxBfypk5iw4fq6zfIarcoR8P28nx c2mQ== MIME-Version: 1.0 X-Received: by 10.50.97.33 with SMTP id dx1mr4526317igb.1.1433343588697; Wed, 03 Jun 2015 07:59:48 -0700 (PDT) Received: by 10.64.236.10 with HTTP; Wed, 3 Jun 2015 07:59:48 -0700 (PDT) Date: Wed, 3 Jun 2015 22:59:48 +0800 Message-ID: Subject: Adding RTL8153 support to rue(4) USB to Ethernet driver From: Ben Woods To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 14:59:49 -0000 Hi everyone, I am wondering what it would take to add support for RTL8153 to the rue(4) USB to Fast Ethernet driver for Realtek. I bought one of these from NEC in Japan (their part number PC-VP-BK06), as shown here (use Google translate): http://121ware.com/product/option/cable/pc-vp-bk06/index.html Here is the diff when support was added to the Linux kernel: https://lkml.org/lkml/2013/7/7/127 Regards, Ben -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-net@FreeBSD.ORG Wed Jun 3 15:01:28 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F15903CC for ; Wed, 3 Jun 2015 15:01:28 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BD43D1DE9 for ; Wed, 3 Jun 2015 15:01:28 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by igbpi8 with SMTP id pi8so113392582igb.0 for ; Wed, 03 Jun 2015 08:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=FYI19X4CsQous2KARo/Yqmsam3h6Nr/rTDBABp2NjQ8=; b=E7hLbEMSRnGqmZoXFTuLHy+6aElI1As5pr5zAqg/I39/EAm2KcKzHPPiO2Rk5lTa1t 8mlBmFU5UG4C7kTHISJgici+6cj7tWi1wCN5aPCFl2I9DKfo2PE+xf0JQugQi1r7Waf0 gAmcy4FO5cyD5QKEbap6dQNYTOIbjki7iH+1iUmmHlPpjI1ozLo+8ThPuSkn4tmNG9QY uvIpYg1ZURbfHM4ifjDec1XWNq0XRTjDF7REAauN6xO7s8/YGdO6jW+nKfjcO1lNvBZj EDA4k9Ho/N1mXRlGtqSgZt91rYlkOtDZeZvFSsvFL/DMVKNgUFBcWbyJyXlB5V///uDw DZ1A== MIME-Version: 1.0 X-Received: by 10.107.138.208 with SMTP id c77mr14112447ioj.24.1433343688109; Wed, 03 Jun 2015 08:01:28 -0700 (PDT) Received: by 10.64.236.10 with HTTP; Wed, 3 Jun 2015 08:01:28 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Jun 2015 23:01:28 +0800 Message-ID: Subject: Re: Adding RTL8153 support to rue(4) USB to Ethernet driver From: Ben Woods To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 15:01:29 -0000 On 3 June 2015 at 22:59, Ben Woods wrote: > Hi everyone, > > I am wondering what it would take to add support for RTL8153 to the > rue(4) USB to Fast Ethernet driver for Realtek. > > I bought one of these from NEC in Japan (their part number > PC-VP-BK06), as shown here (use Google translate): > http://121ware.com/product/option/cable/pc-vp-bk06/index.html > > Here is the diff when support was added to the Linux kernel: > https://lkml.org/lkml/2013/7/7/127 > > Regards, > Ben > > -- > From: Benjamin Woods > woodsb02@gmail.com I nearly forgot the output from my usbconfig(8): # usbconfig -u 1 -a 2 dump_device_desc ugen1.5: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (100mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0210 bDeviceClass = 0x0000 bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0040 idVendor = 0x0bda idProduct = 0x8153 bcdDevice = 0x3000 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0003 <9CEBE81A1976> bNumConfigurations = 0x0002 Regards, Ben From owner-freebsd-net@FreeBSD.ORG Wed Jun 3 15:17:42 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C90E3CEA for ; Wed, 3 Jun 2015 15:17:42 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (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 8C9961128 for ; Wed, 3 Jun 2015 15:17:42 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 6F2401FE022; Wed, 3 Jun 2015 17:17:40 +0200 (CEST) Message-ID: <556F1AC7.3030505@selasky.org> Date: Wed, 03 Jun 2015 17:18:31 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ben Woods , freebsd-net@freebsd.org Subject: Re: Adding RTL8153 support to rue(4) USB to Ethernet driver References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 15:17:42 -0000 On 06/03/15 17:01, Ben Woods wrote: > On 3 June 2015 at 22:59, Ben Woods wrote: >> Hi everyone, >> >> I am wondering what it would take to add support for RTL8153 to the >> rue(4) USB to Fast Ethernet driver for Realtek. >> >> I bought one of these from NEC in Japan (their part number >> PC-VP-BK06), as shown here (use Google translate): >> http://121ware.com/product/option/cable/pc-vp-bk06/index.html >> >> Here is the diff when support was added to the Linux kernel: >> https://lkml.org/lkml/2013/7/7/127 >> >> Regards, >> Ben >> >> -- >> From: Benjamin Woods >> woodsb02@gmail.com > > I nearly forgot the output from my usbconfig(8): > > # usbconfig -u 1 -a 2 dump_device_desc > ugen1.5: at usbus1, cfg=0 md=HOST spd=HIGH > (480Mbps) pwr=ON (100mA) > > bLength = 0x0012 > bDescriptorType = 0x0001 > bcdUSB = 0x0210 > bDeviceClass = 0x0000 > bDeviceSubClass = 0x0000 > bDeviceProtocol = 0x0000 > bMaxPacketSize0 = 0x0040 > idVendor = 0x0bda > idProduct = 0x8153 > bcdDevice = 0x3000 > iManufacturer = 0x0001 > iProduct = 0x0002 > iSerialNumber = 0x0003 <9CEBE81A1976> > bNumConfigurations = 0x0002 > > Regards, > Ben Hi, Can you dump the configuration descriptors? Have you tried: usbconfig -d X.Y set_config 1 --HPS From owner-freebsd-net@FreeBSD.ORG Wed Jun 3 15:42:29 2015 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 CF51980E for ; Wed, 3 Jun 2015 15:42:29 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 70B861906 for ; Wed, 3 Jun 2015 15:42:29 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by wibdt2 with SMTP id dt2so18021372wib.1 for ; Wed, 03 Jun 2015 08:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=55bj6YbxCNA2Rsme4bAFs2RMMhrKGpw8hyXdJ1cGdXM=; b=WoggsD9wpVZq1z9gktOdyyakNAkrgFeRZhPVBz7CV4qRSWQFvfaLdxvyQN7z42mV1s zpLT1lceN5mWOFXiUVfU9JlOFLpBDXLNXqMel06cDFYrAr6bQ2KjBqicbliDs4ng+uJq c5ppJNaKuiMVi6b0kmevphYUB1hYXadkdItXx3HYUmtNUy+WRuXn4RzR4HGhn4aZFSNf Zj+qRUtOcA2sDxDI2aTZCq8fGv8ky8EF8HLFZ0zi1N7hiI45ztJL57fZTAPkUKAiFDtT r8dQf6gH5kkONldtc7NAQdOQJKpyHgRu+SBn138Il+F0oT299qbYSNcvA5MBi7cZ3d6Q 4JGw== MIME-Version: 1.0 X-Received: by 10.180.94.39 with SMTP id cz7mr41857590wib.66.1433346147970; Wed, 03 Jun 2015 08:42:27 -0700 (PDT) Received: by 10.28.61.215 with HTTP; Wed, 3 Jun 2015 08:42:27 -0700 (PDT) In-Reply-To: <556F1AC7.3030505@selasky.org> References: <556F1AC7.3030505@selasky.org> Date: Wed, 3 Jun 2015 23:42:27 +0800 Message-ID: Subject: Re: Adding RTL8153 support to rue(4) USB to Ethernet driver From: Ben Woods To: Hans Petter Selasky Cc: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 15:42:30 -0000 On 3 June 2015 at 23:18, Hans Petter Selasky wrote: > On 06/03/15 17:01, Ben Woods wrote: >> >> On 3 June 2015 at 22:59, Ben Woods wrote: >>> >>> Hi everyone, >>> >>> I am wondering what it would take to add support for RTL8153 to the >>> rue(4) USB to Fast Ethernet driver for Realtek. >>> >>> I bought one of these from NEC in Japan (their part number >>> PC-VP-BK06), as shown here (use Google translate): >>> http://121ware.com/product/option/cable/pc-vp-bk06/index.html >>> >>> Here is the diff when support was added to the Linux kernel: >>> https://lkml.org/lkml/2013/7/7/127 >>> >>> Regards, >>> Ben >>> >>> -- >>> From: Benjamin Woods >>> woodsb02@gmail.com >> >> >> I nearly forgot the output from my usbconfig(8): >> >> # usbconfig -u 1 -a 2 dump_device_desc >> ugen1.5: at usbus1, cfg=0 md=HOST spd=HIGH >> (480Mbps) pwr=ON (100mA) >> >> bLength = 0x0012 >> bDescriptorType = 0x0001 >> bcdUSB = 0x0210 >> bDeviceClass = 0x0000 >> bDeviceSubClass = 0x0000 >> bDeviceProtocol = 0x0000 >> bMaxPacketSize0 = 0x0040 >> idVendor = 0x0bda >> idProduct = 0x8153 >> bcdDevice = 0x3000 >> iManufacturer = 0x0001 >> iProduct = 0x0002 >> iSerialNumber = 0x0003 <9CEBE81A1976> >> bNumConfigurations = 0x0002 >> >> Regards, >> Ben > > > Hi, > > Can you dump the configuration descriptors? > > Have you tried: > > usbconfig -d X.Y set_config 1 > > --HPS > Wow - it works after running your recommended "usbconfig -d X.Y set_config 1"! It shows up as interface ue0, I can get an IP address with DHCLIENT and networking works fine. Note that I am running FreeBSD 11-current r283879. Thank you for your help HPS! How can we make this work out of the box in the future? Here is the dmesg output: kernel: ugen0.3: at usbus0 root: Unknown USB device: vendor 0x0bda product 0x8153 bus uhub0 kernel: cdce0: on usbus0 kernel: ue0: on cdce0 kernel: ue0: Ethernet address: 9c:eb:e8:1a:19:76 root: Unknown USB device: vendor 0x0bda product 0x8153 bus uhub0 root: Unknown USB device: vendor 0x064e product 0xc801 bus uhub0 root: Unknown USB device: vendor 0x064e product 0xc801 bus uhub0 Here is a copy of the configuration descriptors BEFORE running the above command: ugen0.3: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (36mA) Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0039 bNumInterfaces = 0x0001 bConfigurationValue = 0x0001 iConfiguration = 0x0000 bmAttributes = 0x00a0 bMaxPower = 0x0012 Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0000 bAlternateSetting = 0x0000 bNumEndpoints = 0x0003 bInterfaceClass = 0x00ff bInterfaceSubClass = 0x00ff bInterfaceProtocol = 0x0000 iInterface = 0x0000 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 bmAttributes = 0x0002 wMaxPacketSize = 0x0400 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Additional Descriptor bLength = 0x06 bDescriptorType = 0x30 bDescriptorSubType = 0x03 RAW dump: 0x00 | 0x06, 0x30, 0x03, 0x00, 0x00, 0x00 Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0002 bmAttributes = 0x0002 wMaxPacketSize = 0x0400 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Additional Descriptor bLength = 0x06 bDescriptorType = 0x30 bDescriptorSubType = 0x03 RAW dump: 0x00 | 0x06, 0x30, 0x03, 0x00, 0x00, 0x00 Endpoint 2 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0083 bmAttributes = 0x0003 wMaxPacketSize = 0x0002 bInterval = 0x0008 bRefresh = 0x0000 bSynchAddress = 0x0000 Additional Descriptor bLength = 0x06 bDescriptorType = 0x30 bDescriptorSubType = 0x00 RAW dump: 0x00 | 0x06, 0x30, 0x00, 0x00, 0x02, 0x00 Here is a copy of the configuration descriptors AFTER running the command: ugen0.3: at usbus0, cfg=1 md=HOST spd=SUPER (5.0Gbps) pwr=ON (36mA) Configuration index 1 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0062 bNumInterfaces = 0x0002 bConfigurationValue = 0x0002 iConfiguration = 0x0000 bmAttributes = 0x00a0 bMaxPower = 0x0012 Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0000 bAlternateSetting = 0x0000 bNumEndpoints = 0x0001 bInterfaceClass = 0x0002 bInterfaceSubClass = 0x0006 bInterfaceProtocol = 0x0000 iInterface = 0x0005 Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x00 RAW dump: 0x00 | 0x05, 0x24, 0x00, 0x10, 0x01 Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x06 RAW dump: 0x00 | 0x05, 0x24, 0x06, 0x00, 0x01 Additional Descriptor bLength = 0x0d bDescriptorType = 0x24 bDescriptorSubType = 0x0f RAW dump: 0x00 | 0x0d, 0x24, 0x0f, 0x03, 0x00, 0x00, 0x00, 0x00, 0x08 | 0xea, 0x05, 0x00, 0x00, 0x00 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0083 bmAttributes = 0x0003 wMaxPacketSize = 0x0010 bInterval = 0x0008 bRefresh = 0x0000 bSynchAddress = 0x0000 Additional Descriptor bLength = 0x06 bDescriptorType = 0x30 bDescriptorSubType = 0x00 RAW dump: 0x00 | 0x06, 0x30, 0x00, 0x00, 0x08, 0x00 Interface 1 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0001 bAlternateSetting = 0x0000 bNumEndpoints = 0x0000 bInterfaceClass = 0x000a bInterfaceSubClass = 0x0000 bInterfaceProtocol = 0x0000 iInterface = 0x0000 Interface 1 Alt 1 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0001 bAlternateSetting = 0x0001 bNumEndpoints = 0x0002 bInterfaceClass = 0x000a bInterfaceSubClass = 0x0000 bInterfaceProtocol = 0x0000 iInterface = 0x0004 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 bmAttributes = 0x0002 wMaxPacketSize = 0x0400 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Additional Descriptor bLength = 0x06 bDescriptorType = 0x30 bDescriptorSubType = 0x03 RAW dump: 0x00 | 0x06, 0x30, 0x03, 0x00, 0x00, 0x00 Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0002 bmAttributes = 0x0002 wMaxPacketSize = 0x0400 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Additional Descriptor bLength = 0x06 bDescriptorType = 0x30 bDescriptorSubType = 0x03 RAW dump: 0x00 | 0x06, 0x30, 0x03, 0x00, 0x00, 0x00 Regards, Ben From owner-freebsd-net@FreeBSD.ORG Wed Jun 3 15:45:44 2015 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 7A750A2A for ; Wed, 3 Jun 2015 15:45:44 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (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 3C9571934 for ; Wed, 3 Jun 2015 15:45:44 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 75D1E1FE022; Wed, 3 Jun 2015 17:45:42 +0200 (CEST) Message-ID: <556F2159.1010704@selasky.org> Date: Wed, 03 Jun 2015 17:46:33 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ben Woods CC: freebsd-net@freebsd.org Subject: Re: Adding RTL8153 support to rue(4) USB to Ethernet driver References: <556F1AC7.3030505@selasky.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 15:45:44 -0000 On 06/03/15 17:42, Ben Woods wrote: > Thank you for your help HPS! How can we make this work out of the box > in the future? Hi, In dev/usb/quirk/usb_quirk.c you can add a quirk that config index 1 should be selected by default for your device. --HPS From owner-freebsd-net@FreeBSD.ORG Wed Jun 3 18:06:44 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B76A41DE for ; Wed, 3 Jun 2015 18:06:44 +0000 (UTC) (envelope-from sbruno@ignoranthack.me) 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 9A1101D31 for ; Wed, 3 Jun 2015 18:06:44 +0000 (UTC) (envelope-from sbruno@ignoranthack.me) Received: from [192.168.200.214] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id B230A193656 for ; Wed, 3 Jun 2015 18:06:42 +0000 (UTC) Message-ID: <556F4231.6060404@ignoranthack.me> Date: Wed, 03 Jun 2015 11:06:41 -0700 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" Subject: [CFT] em(4) updates Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 18:06:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Intel and Limelight have collaborated a bit to update em(4) and shake loose some features. https://svnweb.freebsd.org/changeset/base/283959 I've left EM_MULTIQUEUE turned off by default but some of the changes in head are relevant to all em(4) chipsets. lem(4) is unaffected by this change. If you've had issues with em(4) in the past or have problems now, I'd really appreciate a shake down of these changes. sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJVb0IxXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kkZwIAIqyWNymaYZPCavzO7j1VDFQ cqiGREQckOWFpkv4IA9bVAGqM7k1VRhOj5ewXIIhbITfCXaCv31CUxh7hG9l7KDe CMmAObLX917mY9JvS+p/vCYFHwZLkH1OxeC/rdPViEXEJAs4PkJWUB4WS2pJQKU1 vpIAYcbEf5E6TpKCdLDw8yzFXiOE4apq+1Qnt83/JLu08PtJ+85ymXPinoq+/WBF SiLg7nWBis6E6uC+zvA2XU4LkOdWO6DZTdowU/lexy9xp1SoYJxOEW0DNns+pSCs ihOew1zzTisWlrVazaHZpMA9vl1q4Vdv3Amy7zituU+Ab6713ETiD5Neit01GVY= =vCcB -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Thu Jun 4 07:31:13 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D6654D3 for ; Thu, 4 Jun 2015 07:31:13 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CF8001C25 for ; Thu, 4 Jun 2015 07:31:12 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [93.104.14.203] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1Z0PcJ-0006Tz-P5 for freebsd-net@freebsd.org; Thu, 04 Jun 2015 09:31:08 +0200 Received: from localhost.my.domain (c720-r276659 [127.0.0.1]) by localhost.unixarea.de (8.14.9/8.14.9) with ESMTP id t547V5Sx002052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 4 Jun 2015 09:31:06 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.9/8.14.9/Submit) id t547V50N002051 for freebsd-net@freebsd.org; Thu, 4 Jun 2015 09:31:05 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Thu, 4 Jun 2015 09:31:00 +0200 From: Matthias Apitz To: freebsd-net@freebsd.org Subject: unknown UDP caused by dhclient Message-ID: <20150604073100.GA2012@c720-r276659> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Operating-System: FreeBSD 11.0-CURRENT r269739 (i386) User-Agent: Mutt/1.5.23 (2014-03-12) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 93.104.14.203 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 07:31:13 -0000 Hello, I'm seeing in my firewall log unknow UDP traffic which is caused by the running dhclient: Jun 3 21:57:02 c720-r276659 dhclient[2601]: send_packet: Network is unreachable Jun 3 21:57:02 c720-r276659 ipmon[2368]: 21:57:02.751350 ue0 @0:82 b 10.42.0.83,68 -> 10.42.0.1,67 PR udp len 20 328 OUT Jun 3 21:58:38 c720-r276659 dhclient[2601]: send_packet: Network is unreachable Jun 3 21:58:38 c720-r276659 ipmon[2368]: 21:58:38.753118 ue0 @0:82 b 10.42.0.83,68 -> 10.42.0.1,67 PR udp len 20 328 OUT What is my dhclient asking from the router 10.42.0.1? Should I open the ipfilter for this? The system is r276659. Thanks matthias -- Matthias Apitz, guru@unixarea.de, http://www.unixarea.de/ +49-170-4527211 +49-176-38902045 "Wenn der Mensch von den Umständen gebildet wird, so muß man die Umstände menschlich bilden." "Si el hombre es formado por las circunstancias entonces es necesario formar humanamente las circunstancias", Karl Marx in Die heilige Familie / La sagrada familia (MEW 2, 138) From owner-freebsd-net@FreeBSD.ORG Thu Jun 4 16:54:38 2015 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 7E4A86D1 for ; Thu, 4 Jun 2015 16:54:38 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0456017D4 for ; Thu, 4 Jun 2015 16:54:38 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: by lbcmx3 with SMTP id mx3so31079733lbc.1 for ; Thu, 04 Jun 2015 09:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=LqCg4tcSDly/4XYnEuEW+jXXVJX5ZwiVfeUEl0EntHw=; b=UgHUFLiMfT5vSFjEGvh25BHB/ZwyVE+HLt2McTWUF5JK63AfRn+lzhVD32EVZCfxFC WLzQY8LQQ/75NE2SUPKEGi0doNN33sBGpOW12kb/xKGnsmCkvlTVCrp0msV2lOfoUcQy MWLQV1Wgnz6YP4eQxDyO9vM0sc2wIrswEzQu5+oJx49M9UJKmnrJoPLpXAWQ9/coc/Qg MgKkbHksgLfRBvLuC312bU5NzUPzUGKt3/sUAdIsJp6Dn+a3Tj6icT4RJpt5NOOgqlvS kpgq3mGjkIqPTauS/9D40v6zVxDdC/kBtjeAP2Y14BMcftM9uFuBASHHIY/kbweG+OTV wX4Q== MIME-Version: 1.0 X-Received: by 10.152.203.162 with SMTP id kr2mr38744602lac.68.1433436875883; Thu, 04 Jun 2015 09:54:35 -0700 (PDT) Received: by 10.152.137.193 with HTTP; Thu, 4 Jun 2015 09:54:35 -0700 (PDT) In-Reply-To: <20150604073100.GA2012@c720-r276659> References: <20150604073100.GA2012@c720-r276659> Date: Thu, 4 Jun 2015 19:54:35 +0300 Message-ID: Subject: Re: unknown UDP caused by dhclient From: Kimmo Paasiala To: Matthias Apitz , FreeBSD Net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 16:54:38 -0000 On Thu, Jun 4, 2015 at 10:31 AM, Matthias Apitz wrote: > > Hello, > > I'm seeing in my firewall log unknow UDP traffic which is caused by the > running dhclient: > > Jun 3 21:57:02 c720-r276659 dhclient[2601]: send_packet: Network is unre= achable > Jun 3 21:57:02 c720-r276659 ipmon[2368]: 21:57:02.751350 ue0 @0:82 b 10.= 42.0.83,68 -> 10.42.0.1,67 PR udp len 20 328 OUT > Jun 3 21:58:38 c720-r276659 dhclient[2601]: send_packet: Network is unre= achable > Jun 3 21:58:38 c720-r276659 ipmon[2368]: 21:58:38.753118 ue0 @0:82 b 10.= 42.0.83,68 -> 10.42.0.1,67 PR udp len 20 328 OUT > > What is my dhclient asking from the router 10.42.0.1? Should I open the > ipfilter for this? > > The system is r276659. > > Thanks > > matthias > -- > Matthias Apitz, guru@unixarea.de, http://www.unixarea.de/ +49-170-4527211= +49-176-38902045 > "Wenn der Mensch von den Umst=C3=A4nden gebildet wird, so mu=C3=9F man di= e Umst=C3=A4nde menschlich bilden." > "Si el hombre es formado por las circunstancias entonces es necesario for= mar humanamente > las circunstancias", Karl Marx in Die heilige Familie / La sagrada famili= a (MEW 2, 138) That is how a DHCP client ask for lease renewal from the DHCP server, you should allow the traffic if the interface in question is configured to use DHCP. -Kimmo From owner-freebsd-net@FreeBSD.ORG Thu Jun 4 18:20:27 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 657E9E49 for ; Thu, 4 Jun 2015 18:20:27 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2194A1BED for ; Thu, 4 Jun 2015 18:20:27 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [89.204.130.9] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1Z0ZkY-00057S-1x; Thu, 04 Jun 2015 20:20:18 +0200 Received: from localhost.my.domain (c720-r276659 [127.0.0.1]) by localhost.unixarea.de (8.14.9/8.14.9) with ESMTP id t54IKEJK001946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 4 Jun 2015 20:20:14 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.9/8.14.9/Submit) id t54IKDcr001945; Thu, 4 Jun 2015 20:20:13 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Thu, 4 Jun 2015 20:20:13 +0200 From: Matthias Apitz To: Kimmo Paasiala Cc: FreeBSD Net Subject: Re: unknown UDP caused by dhclient Message-ID: <20150604182013.GA1841@c720-r276659> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , Kimmo Paasiala , FreeBSD Net References: <20150604073100.GA2012@c720-r276659> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT r269739 (i386) User-Agent: Mutt/1.5.23 (2014-03-12) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.130.9 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 18:20:27 -0000 El día Thursday, June 04, 2015 a las 07:54:35PM +0300, Kimmo Paasiala escribió: > That is how a DHCP client ask for lease renewal from the DHCP server, > you should allow the traffic if the interface in question is > configured to use DHCP. Thanks for your kind answer. I was wondering why I only see this on the ue0 interface (which is to my Ubuntu mobile phone when I'm in the fields) and not on the Wifi wlan0. But, perhaps this is due to the very short renewal interval of 1800 secs: DHCPREQUEST on ue0 to 255.255.255.255 port 67 DHCPACK from 10.42.0.1 bound to 10.42.0.83 -- renewal in 1800 seconds. I will let pass this traffic from now. matthias -- Matthias Apitz, guru@unixarea.de, http://www.unixarea.de/ +49-170-4527211 +49-176-38902045 "Wenn der Mensch von den Umständen gebildet wird, so muß man die Umstände menschlich bilden." "Si el hombre es formado por las circunstancias entonces es necesario formar humanamente las circunstancias", Karl Marx in Die heilige Familie / La sagrada familia (MEW 2, 138) From owner-freebsd-net@FreeBSD.ORG Thu Jun 4 19:01:02 2015 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 E7FFB899 for ; Thu, 4 Jun 2015 19:01:02 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E0931675 for ; Thu, 4 Jun 2015 19:01:02 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: by labko7 with SMTP id ko7so38739745lab.2 for ; Thu, 04 Jun 2015 12:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=aTD5mDWfDOyS7f1i6AOtlUpu269o+f1P+v3aqzWhb28=; b=a9zU3AdLzKJa/H/O+iflcdlAfQHGmPCOVG51zTfL/jVDeaJw1VgxJ4CfIQpT6Hyxe/ PjOOxjd+IPJ+KK9HuJGBU5OJ0kJAVh8CdPqtGnRQRWbpsqBbcapdQy/v1e0ohyo2H/RD sUtWLHO08obJlRCxcqtRYgooNih9B2QKSdsQ5uI1bK/7VrwmUd3JG1Ib5UpCMoGpZGGX Ij1IwovaiHaQFq8wmhucTXBC0t7IlYQ/Om54ChATbhxrg8aA/JUi8OV3ZavvO+2lrJlr 3cW8jRWPICVMvTV1Yv6mBl/x3Vz80kYNl8N5i0WRtnziKHrjie5PMhuLWq4p+ZK++G7X Ynxg== MIME-Version: 1.0 X-Received: by 10.112.166.5 with SMTP id zc5mr24535736lbb.91.1433444460244; Thu, 04 Jun 2015 12:01:00 -0700 (PDT) Received: by 10.152.137.193 with HTTP; Thu, 4 Jun 2015 12:01:00 -0700 (PDT) In-Reply-To: <20150604182013.GA1841@c720-r276659> References: <20150604073100.GA2012@c720-r276659> <20150604182013.GA1841@c720-r276659> Date: Thu, 4 Jun 2015 22:01:00 +0300 Message-ID: Subject: Re: unknown UDP caused by dhclient From: Kimmo Paasiala To: Matthias Apitz , Kimmo Paasiala , FreeBSD Net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 19:01:03 -0000 On Thu, Jun 4, 2015 at 9:20 PM, Matthias Apitz wrote: > El d=C3=ADa Thursday, June 04, 2015 a las 07:54:35PM +0300, Kimmo Paasial= a escribi=C3=B3: > >> That is how a DHCP client ask for lease renewal from the DHCP server, >> you should allow the traffic if the interface in question is >> configured to use DHCP. > > Thanks for your kind answer. I was wondering why I only see this on the > ue0 interface (which is to my Ubuntu mobile phone when I'm in the > fields) and not on the Wifi wlan0. But, perhaps this is due to the very > short renewal interval of 1800 secs: > > DHCPREQUEST on ue0 to 255.255.255.255 port 67 > DHCPACK from 10.42.0.1 > bound to 10.42.0.83 -- renewal in 1800 seconds. > > I will let pass this traffic from now. > > matthias > -- > Matthias Apitz, guru@unixarea.de, http://www.unixarea.de/ +49-170-4527211= +49-176-38902045 > "Wenn der Mensch von den Umst=C3=A4nden gebildet wird, so mu=C3=9F man di= e Umst=C3=A4nde menschlich bilden." > "Si el hombre es formado por las circunstancias entonces es necesario for= mar humanamente > las circunstancias", Karl Marx in Die heilige Familie / La sagrada famili= a (MEW 2, 138) What you saw there was the most specific way to ask for lease renewal using the last known address of the DHCP server. If that fails the client falls back to broadcasting to 10.41.0.255:67 because the DHCP server might have relocated to a new address in the subnet. If even that fails the client will start over from zero broadcasting to 255.255.255.255:67. DHCP is a bit complicated case for stateful filtering, that's why you should allow all outgoing UDP traffic to port 67 regardless of addresses. -Kimmo From owner-freebsd-net@FreeBSD.ORG Sat Jun 6 13:42:57 2015 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C974E1C for ; Sat, 6 Jun 2015 13:42:57 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 48AFA3CEC; Sat, 6 Jun 2015 13:42:56 +0000 (UTC) (envelope-from ae@FreeBSD.org) Message-ID: <5572F84A.5060101@FreeBSD.org> Date: Sat, 06 Jun 2015 16:40:26 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Julian Kornberger , "net@freebsd.org" Subject: Re: Crash with GRE und IPFW fwd References: <5566565A.7030200@tzi.de> <55671F25.5070308@FreeBSD.org> <556C80C3.508@tzi.de> In-Reply-To: <556C80C3.508@tzi.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="t030oK47On1CXhj83TgpSH4b5sMTneaSN" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 13:42:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --t030oK47On1CXhj83TgpSH4b5sMTneaSN Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01.06.2015 18:56, Julian Kornberger wrote: > Am 28.05.2015 um 15:59 schrieb Andrey V. Elsukov: >> Also can you try this module instead of one from your base system? >> https://people.freebsd.org/~ae/gre-10.tgz >> >> This is ported to stable/10 version from 11.0-CURRENT. >=20 > I installed your gre module and our system has been running for more > than two hours now without a crash. Can I expect these changes to be > merge merged into stable/10? JFYI, I merged gre(4) from head/ into stable/10. --=20 WBR, Andrey V. Elsukov --t030oK47On1CXhj83TgpSH4b5sMTneaSN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVcvhLAAoJEAHF6gQQyKF6nJMH/3SpQ1Jgrq1/hDgRGoDUvupW lxSEjaSDvU9qezHYkzo47Rk8mh05X8ckER3HIBYgchFYzs2Fwoi+QGKbOUFg0NvQ NKioGvUhU9Va/z622/nIkkYsZVNZ3G6ZEoAXftpyHoEWcpR58FhZ2a8SmUAGDTbO nD4fV6HJzwjsocXLvbIcqwfgEdvb4wfnW4ryO5gCyQZT2l59OW4Ni0H3Kepd5LYW x6bzPPwP56OYDs6u4HLEsw+CshM1ZysBuz+oZ/6GT9R83VKOL+3cuNME1wDGBsGK CTrj8zNDKqtFWYjGVNJfcOKvgqVywc9Z6sGOza7ngAq0akWq8WNLS6WjqKuUg9M= =uovT -----END PGP SIGNATURE----- --t030oK47On1CXhj83TgpSH4b5sMTneaSN-- From owner-freebsd-net@FreeBSD.ORG Sat Jun 6 19:46:49 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9E45869; Sat, 6 Jun 2015 19:46:49 +0000 (UTC) (envelope-from service@plitc.eu) Received: from root1-rz1-hetzner.plitc.eu (root1-rz1-hetzner.plitc.eu [IPv6:2a01:4f8:a0:4283::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "root1-rz1-hetzner.plitc.eu", Issuer "StartCom Class 2 Primary Intermediate Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA52313BC; Sat, 6 Jun 2015 19:46:49 +0000 (UTC) (envelope-from service@plitc.eu) Received: from localhost (localhost [127.0.0.1]) by root1-rz1-hetzner.plitc.eu (Postfix) with ESMTP id 3D9BCAE0076; Sat, 6 Jun 2015 21:46:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at root1-rz1-hetzner.plitc.eu Received: from root1-rz1-hetzner.plitc.eu ([127.0.0.1]) by localhost (root1-rz1-hetzner.plitc.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjKYVqnnD2SL; Sat, 6 Jun 2015 21:46:40 +0200 (CEST) Received: from MacBook1-PLITC.local (unknown [46.246.49.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: service@plitc.eu) by root1-rz1-hetzner.plitc.eu (Postfix) with ESMTPSA id B6124AE0074; Sat, 6 Jun 2015 21:46:39 +0200 (CEST) Message-ID: <55734E1E.9050500@plitc.eu> Date: Sat, 06 Jun 2015 21:46:38 +0200 From: PLITC Service MIME-Version: 1.0 To: freebsd-net@FreeBSD.org, freebsd-security@FreeBSD.org Subject: IPsec-Tools 0-Day Denial of Service Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 19:46:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 https://www.altsci.com/ipsec/ipsec-tools-sa.html security/ipsec-tools build with gssapi: CRASHED (FreeBSD 10.1 + ipsec-tools 0.8.2_1) best regards Daniel -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVc04dAAoJEFjRCSf16qPCAnsP/R237p8lFV4VB8GG1r3Td3SN 0BIsQvaEHXmoBuU5RydZo02sxXkjeMzq1lu52twtEAx/DLMSy4Bv9m+bjAJ3vIGB rJ/lDq+bp4KcUcz4rO7/coivbdHJ6TVP5+/hWAOOWZqYhm3am7n2TOXI+E5gvuLy UleDufie1soJyBpSjoq2r0psPhTTt+s7NlW0JvJyDsr5QID40UpxIjrIlPX8GfzS fIBA4v8kixQCv6b+fFO1hl78O02SF1w/Zl0KIXG1Cc948vi2lZ8y0NT6YIcNLx0H pfg7OdN4J8YF8JMhG5ZMlUeVIbTDCsQLoSteB/u9WF/Gm0U2Xz/uV6WjD2br+KQh tpnfm3JYMO2xs8YSXJW7KMmp/3gEQZf/15rpTKmkQxWw6edFl43xf97wuKY4pI5P uy0LgFjkrmxEK3ifDnJlMBY/wsgGU8AngwbvOaGLy+esWQN12NDNJEpSC9Zc8Ym6 iz7QA8zXiyAlq087xcYYu0Rk/uhXwMev4N3V0CQfamhKtndORZmtZUP+i4IVihJL UAhX5x74GiQqV0vnTZpdC1IiukhSy2C/8GSXeevRrpH7XWvtTKKH5iLtbC8bBYdU btqQQM7s+dLaZQhkVamhN4rCocgQVRgS6TemjF/uzIDQaHgxgzVkZdSQHELOxMF5 bnt18bGUAsHp35Fe+SrT =PDd9 -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Sat Jun 6 19:48:20 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2CACA3C; Sat, 6 Jun 2015 19:48:20 +0000 (UTC) (envelope-from Daniel@Plominski.eu) Received: from root1-rz1-hetzner.plitc.eu (root1-rz1-hetzner.plitc.eu [IPv6:2a01:4f8:a0:4283::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "root1-rz1-hetzner.plitc.eu", Issuer "StartCom Class 2 Primary Intermediate Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7441313D7; Sat, 6 Jun 2015 19:48:19 +0000 (UTC) (envelope-from Daniel@Plominski.eu) Received: from localhost (localhost [127.0.0.1]) by root1-rz1-hetzner.plitc.eu (Postfix) with ESMTP id D477BAE0076; Sat, 6 Jun 2015 21:48:17 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at root1-rz1-hetzner.plitc.eu Received: from root1-rz1-hetzner.plitc.eu ([127.0.0.1]) by localhost (root1-rz1-hetzner.plitc.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdVMWP7R8E7V; Sat, 6 Jun 2015 21:48:17 +0200 (CEST) Received: from MacBook1-PLITC.local (unknown [46.246.49.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: daniel@plominski.eu) by root1-rz1-hetzner.plitc.eu (Postfix) with ESMTPSA id B9147AE0074; Sat, 6 Jun 2015 21:48:16 +0200 (CEST) Message-ID: <55734E7F.2070308@Plominski.eu> Date: Sat, 06 Jun 2015 21:48:15 +0200 From: "Daniel DP. Plominski" MIME-Version: 1.0 To: freebsd-net@FreeBSD.org, freebsd-security@FreeBSD.org Subject: IPsec-Tools 0-Day Denial of Service Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 19:48:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 https://www.altsci.com/ipsec/ipsec-tools-sa.html security/ipsec-tools build with gssapi: CRASHED (FreeBSD 10.1 + ipsec-tools 0.8.2_1) best regards Daniel -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVc05/AAoJEHqkZNWiQao7tIIP/1A+EdQNylO3kLeO+LZA3j+7 U5BSq9lmCHVmNhiGcb0Q7u2px/t60p5axbuJbJLGAOGFsbeFy+nXCjXvgc4BI7Xq xC4QR+dFy16F4w+ZVBpmOlu7+jcgHz2m2/Nq5iupUsWTmNWIEOrw1cH6Qv872eC1 mrJgaAMPHpmlY/pvrdhCkAtoGoVJztywbW7l0BYeV4lLhbOm3JtmySJ+H0zUuBFI kpG9dx3wXD8fShac/9i1mjtl3Qo8741744REHyMO7XuykroFEllsDkeYC0xwbLD0 /yj6Q+F1wQ1vZvu4XnuoxsxR18Ov1EtVJp7expfI3DC61A4yO/kr+ROGv7yhtPMl pJIsvMwqMs84+m11lalhNPd08L1dSYBBT2xF2tFUGHlhuiX7m0+jiF7a9l/M4AeY TvBqkEKVbbBWiVYr0Dd1q2R2ca5/LUq2v1MEQUmAj/c9KKWYML9VRRO0Vm94ADV8 FeywmhpPBqst9VJQ29QuOdC1z8/82sQIA1JE9e1x1Ct877fugLOEc3CJpR73lv+l l3sdJBGPE5thEELboB+F5zS29Yl/TK2YKT/WdrV8rcYOXhsHKV2Zq4/FQ9mJe+jB PukIaNiRbsfZ0R2W1mhKYg5J9ZeR5GVbsR9GulYQTxIu9grqpT+EQkVnJWusql3p 1jxrMWuBtkcEUEZ5X7/i =5y6s -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Sat Jun 6 22:52:26 2015 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 5D29A40B for ; Sat, 6 Jun 2015 22:52:26 +0000 (UTC) (envelope-from daemon-user@FreeBSD.org) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (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 3293D120B for ; Sat, 6 Jun 2015 22:52:26 +0000 (UTC) (envelope-from daemon-user@FreeBSD.org) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t56MqP5w045732 for ; Sat, 6 Jun 2015 22:52:25 GMT (envelope-from daemon-user@phabric-backend.isc.freebsd.org) Received: (from daemon-user@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t56MqPdX045728; Sat, 6 Jun 2015 22:52:25 GMT (envelope-from daemon-user) Date: Sat, 6 Jun 2015 22:52:25 +0000 To: freebsd-net@freebsd.org From: "sbruno (Sean Bruno)" Reply-to: D1777+325+ec2e1ba39a1e09fe@FreeBSD.org Subject: [Differential] [Commented On] D1777: Associated fix for arp/nd6 timer usage. Message-ID: <43d92e3e4a4534b89f4e56adb82601e8@localhost.localdomain> X-Priority: 3 Thread-Topic: D1777: Associated fix for arp/nd6 timer usage. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: N2Y2Y2VmY2ZjNTc1MTM4NTA3YmIzZDk3NmE4IFVzeak= Precedence: bulk X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 22:52:26 -0000 sbruno added a comment. Should this be closed? REVISION DETAIL https://reviews.freebsd.org/D1777 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: rrs, imp, gnn, rwatson, lstewart, kib, adrian, jhb, bz, sbruno Cc: ae, bz, freebsd-net-list, emaste, hiren, julian, hselasky