From owner-svn-src-head@freebsd.org Sat Aug 20 22:05:16 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 7BA87BC0325; Sat, 20 Aug 2016 22:05:16 +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 3AD7618B5; Sat, 20 Aug 2016 22:05:16 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1bbEO6-000Ah9-VS; Sun, 21 Aug 2016 01:05:10 +0300 Date: Sun, 21 Aug 2016 01:05:10 +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: <20160820220510.GX8192@zxy.spb.ru> References: <6f4449f2-d145-8b49-c3f0-433e8ff4d2a2@fastmail.net> <20160820173050.GQ22212@zxy.spb.ru> <20160820184506.GV8192@zxy.spb.ru> <0f42c5fb-f930-c6e3-75d6-df97f67c201d@fastmail.net> <20160820204106.GW8192@zxy.spb.ru> <0acba141-4701-d9c2-0ddb-46d1f60ff55b@fastmail.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0acba141-4701-d9c2-0ddb-46d1f60ff55b@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: Sat, 20 Aug 2016 22:05:16 -0000 On Sat, Aug 20, 2016 at 10:17:27PM +0100, Bruce Simpson wrote: > On 20/08/16 21:41, Slawa Olhovchenkov wrote: > > On Sat, Aug 20, 2016 at 09:34:06PM +0100, Bruce Simpson wrote: > >> So, Ryan -- your original reading of how in_broadcast() behaves is > >> correct, modulo the all-ones bypassing it. > > What purpose to analyse L2 header? > > I was just checking for possible edge cases for a substitution of the > in_broadcast() check with some other way of logically summarising the > real broadcast disposition of the interface in bits, given your mGRE > example below. I am think this substitution is very bad idea (by design). Also, on transmit side this is must be irrelevant on received L2 header (and this in many cases this is will be L2 unicast packet). For other cases packet will be created on host and don't have any received information. On received side for host relaing on L2 information for accepting packet as host targeting sound like security hole. In router case receiving broadcast packet in any way need additional check for dst IP address (host part is all zero or all one? what about handling this broadcast type (RFC talk about conroling variation of this)? what about sysctl control of receiving routed broadcast packets? what about handling 255.255.255.255?) In any way, this is irrelevant to L2 broadcast MAC and present L2 broadcast flags. > Like M_BCAST, but 'This packet is flagged as broadcast, but only by a > proxy method, not L2'. > > > Yes, curently FreeBSD don't support multiaccess media other then > > ethernet (i.e. ATM, FrameRelay), but in case of mGRE L2 header will be > > absent. > > Exactly! People forget that certain legitimate multipoint protocols > already exist as overlays already. It is easy when all we grow up with > is Ethernet. :-) Until we peek under the hood, we may not know. > > Slawa, you have hit the nail on the head. > > The situation can naturally arise anywhere we bridge L2/L3 in certain > directions, be that in VPN aggregation or PPPoE aggregation. > > In many ways I regret never being able to have executed work on a design > for ng_pppoa in 2005/6. But, given the pain people in the UK are having > with BT and VDSL modem provision right now... it comes as no surprise > that the next generation of DSL access, for us, can be as bad. > > For some, multipoint is less important now we have SR-IOV VFs and other > means of allocating discrete unicast Ethernet MACs and using them as > links, but... Multipoint is mandatory for DMVPN. > Roundabout the time I merged M_PROMISC from NetBSD to FreeBSD in 2006/7, > I considered that we should add an abstraction to ifnet to permit > multiple unicast (or special) MACs to be bound to existing ifnets, and > -- where the card permits it, expedite that MAC in some way. > > That capability was present on the (legacy) Adaptec Starfire quad 100TX > from that era. Today, it exists in e.g. Chelsio T4/5 TCAM filter, or > multiple perfect hashes on the previous generations of cards. (Currently > the FreeBSD stack does nothing about such.) > > I suspect it is less important now we have RSS for raw TCP throughput, > but, for those of us -- e.g. in internet service provider (ISP) type > environments, we have to keep a careful eye on how well FreeBSD plays > nice with other Ethernet equipment, with a view to these types of > potential optimizations in future. May be only as options, per NIC based? I.e. check for L3 broadcasy only when NIC flaged? w/o check L2 dst MAC for broadcasting, because this is excessively and don't give any speed up (in any case need check for L3 broadcast). > However, we still have to keep the FreeBSD-on-Ethernet ship sailing > smoothly. The intent of the original input path change is clearly for > performance, but perhaps slipping the M_BCAST tag in the stack is the > right way forward. > > I would also suggest: we add ability to qualify where in the stack > M_BCAST was raised (in case of any possible re-entry), by allocating one > more MBUF flag to Layer 2. > > Then, the same M_PROMISC flag trick can be applied... and Ryan's > broadcast performance boost could perhaps even carry across L2 bridging > tiers, e.g. stacked if_bridge or netgraph, providing we know what > direction in the stack it's traveling in (and its absolute ifnet origin). > Because L3 broadcast check need be in any case (and can be perform by hash lookup in same time as host ip check) L2 broadcaste check needless.