From owner-svn-src-head@freebsd.org Fri Aug 26 15:13:27 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46452B706F6; Fri, 26 Aug 2016 15:13:27 +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 049E1892; Fri, 26 Aug 2016 15:13:27 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1bdIou-0007Ni-Jw; Fri, 26 Aug 2016 18:13:24 +0300 Date: Fri, 26 Aug 2016 18:13:24 +0300 From: Slawa Olhovchenkov To: Bruce Simpson Cc: Ryan Stone , "svn-src-head@freebsd.org" , Ryan Stone , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , Adrian Chadd Subject: Re: svn commit: r304436 - in head: . sys/netinet Message-ID: <20160826151324.GF88122@zxy.spb.ru> References: <0f42c5fb-f930-c6e3-75d6-df97f67c201d@fastmail.net> <20160820204106.GW8192@zxy.spb.ru> <0acba141-4701-d9c2-0ddb-46d1f60ff55b@fastmail.net> <20160820220510.GX8192@zxy.spb.ru> <8ac23bd1-dcb3-7c64-f195-5039f9af0eaf@fastmail.net> <20160821000400.GY8192@zxy.spb.ru> <20160826144926.GE88122@zxy.spb.ru> <3dba1b70-54cc-0bb1-5cc8-8c56cd750bec@fastmail.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3dba1b70-54cc-0bb1-5cc8-8c56cd750bec@fastmail.net> User-Agent: Mutt/1.5.24 (2015-08-30) 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: svn-src-head@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 15:13:27 -0000 On Fri, Aug 26, 2016 at 04:01:14PM +0100, Bruce Simpson wrote: > Slawa, > > I'm afraid this may be a bit of a non-sequitur. Sorry.. I seem to be > missing something. As I understand it this thread is about Ryan's change > to netinet for broadcast. > > On 26/08/16 15:49, Slawa Olhovchenkov wrote: > > On Sun, Aug 21, 2016 at 03:04:00AM +0300, Slawa Olhovchenkov wrote: > >> On Sun, Aug 21, 2016 at 12:25:46AM +0100, Bruce Simpson wrote: > >>> Whilst I agree with your concerns about multipoint, I support the > >>> motivation behind Ryan's original change: optimize the common case. > >> > >> Oh, common case... > >> I am have pmc profiling for TCP output and see on this SVG picture and > >> don't find any simple way. > >> You want to watch too? > > > > At time peak network traffic (more then 25K connections, about 20Gbit > > total traffic) half of cores fully utilised by network stack. > > > > This is flamegraph from one core: http://zxy.spb.ru/cpu10.svg > > This is same, but stack cut of at ixgbe_rxeof for more unified > > tcp/ip stack view http://zxy.spb.ru/cpu10u.svg > ... > > I appreciate that you've taken the time to post a flamegraph (a > fashionable visualization) of relative performance in the FreeBSD > networking stack. > > Sadly, I am mostly out of my depth for looking at stack wide performance > for the moment; for the things I look at involving FreeBSD at work just > at the moment, I would not generally go down there except for specific > performance issues (e.g. with IEEE 1588). > > It sounds as though perhaps you should raise a wider discussion about > your results on -net. I would caution you however that the Function > Boundary Trace (FBT) provider for DTrace can introduce a fair amount of > noise to the raw performance data because of the trap mechanism it uses. > This ruled it out for one of my own studies requiring packet-level accuracy. > > Whilst raw pmc(4) profiles may require more post-processing, they will > provide less equivocal data (and a better fix) on the hot path, due also > to being sampled effectively on a PMC interrupt (a gather stage- poll > core+uncore MSRs), not purely a software timer interrupt. Thanks for answer, I am now try to start discussion on -net.