From owner-svn-src-head@freebsd.org Sat Aug 20 21:44:14 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 28867BC0FEB; Sat, 20 Aug 2016 21:44:14 +0000 (UTC) (envelope-from bms@fastmail.net) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 EB8F11F93; Sat, 20 Aug 2016 21:44:13 +0000 (UTC) (envelope-from bms@fastmail.net) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 71159202A9; Sat, 20 Aug 2016 17:44:12 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sat, 20 Aug 2016 17:44:12 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=4tDGJUWkgw6O2b3yyyB14QlnOBw=; b=YNfFak ccUFbmvGTvs9djkypX2pDjGfEHm4zDisLmeS5UBSLLPbc3imw//1pcTV7cehBmt3 K1CL01CucWxF1b3MNwGgQ/Ha1V4wxpRHXO3owUWrrMENaNeTb62bLlEz2CzvnzTI rG9fIZwaaLdwhiP7htkZGUL4sH5opzm3SyoXs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=4tDGJUWkgw6O2b3 yyyB14QlnOBw=; b=rFaiYVl1WWa3CzHThzRZX1Ha+D1uWN+ap45Z4Km+x3pbW32 KtHzxriqanIr3BY6L0ON7+Vgl3gCv6EepcbTcK+0ArcKgASYKuYcxA8cJfrYjRWE u7+Ux63oNlhW78s7wGF7bW/hoSY+95wjSLPBBnDx6kJTNoYaKvJd6AdZERdg= X-Sasl-enc: rRPDW19BbktxvWNZkTIKvCOjeCjZeF4jxYUK/Gypz7Qw 1471729452 Received: from pion.local (cpc96954-walt26-2-0-cust843.13-2.cable.virginm.net [82.31.91.76]) by mail.messagingengine.com (Postfix) with ESMTPA id 4A850CCE68; Sat, 20 Aug 2016 17:44:11 -0400 (EDT) Subject: Re: svn commit: r304436 - in head: . sys/netinet To: Slawa Olhovchenkov 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> Cc: Ryan Stone , "svn-src-head@freebsd.org" , Ryan Stone , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , Adrian Chadd From: Bruce Simpson Message-ID: Date: Sat, 20 Aug 2016 22:44:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <0acba141-4701-d9c2-0ddb-46d1f60ff55b@fastmail.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 21:44:14 -0000 On 20/08/16 22:17, Bruce Simpson wrote: > 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) The main motivation for this: retain the original meaning of M_BCAST. (in addition to Ryan's intended new meaning that IP indicate to itself "This is IPv4 broadcast" and to others - it could be used to expedite delivery with some form of map). But, say, let's add a second flag which allows for controlled stacking of L2 in situations like this. Let's call it M_BCPROXY. It can be tracked for the original meaning, i.e. without the new meaning Ryan proposes for M_BCAST. When M_BCAST is set and M_BCPROXY is clear, we know the packet is broadcast, but we don't know for sure that this isn't because IP inspected it, and set the M_BCAST flag due to the destination IPv4 address being identified as such (and valid for its link, if you are enforcing the Strong IP End-Station model, RFC 1122 style, as is the BSD default). However, if we set M_BCPROXY at the same time, then, in situations where we might potentially re-enter the stack holding the same broadcast packet, we know that IP marked the packet as broadcast, and - on entry - can change our routing/switching/allocation/replication strategies accordingly. (This is not information which, on its own, holding the origin ifnet pointer provides; the flag is needed to sense direction in the stack.) So, as the mbuf chain is handed-off between other L2 entities (this can easily happen with stacked VLAN tags, in Q-in-Q and provider environments, which pfSense can service very well) - and, if the node itself determines that it is also a recipient of the broadcast, for correct hand-off if the broadcast does need to be forwarded by some other FreeBSD subsystem. It could also be checked by firewalls: e.g. for a corroborated check, from the mask of these two flags, where in the stack (or link forest) a purported broadcast packet actually originated from. (Pretty much essential for maintaining audit trail if a Smurf-like amplification attack is caught in the act, or if an NTP relay (or other association) terminates in an NTP broadcast association. And, of course, to trace dodgy broadcast Sun-style XDR RPC back to its source.)