From owner-svn-src-all@freebsd.org Sat Aug 20 21:17:38 2016 Return-Path: Delivered-To: svn-src-all@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 4C311BC07F3; Sat, 20 Aug 2016 21:17:38 +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 1C12411E6; Sat, 20 Aug 2016 21:17:37 +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 A5EC220439; Sat, 20 Aug 2016 17:17:36 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sat, 20 Aug 2016 17:17:36 -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=O6Z7xG76TTuAkgoUdfUY2eoEuoI=; b=C6mbdP PH9svkcWDsV50MurSQeeMJ1yVaTXJwolUv1RxzW34VHSIl/ibyqMT5vorl9SaP34 SxzP7XJzo/k7VmvVeCAQqdUQ1676aO8zoeYvwHs2qI9AhSK9lU31a1QETc1r1Rzp 2kR/4dlkEYGltRv+T242LAwveRs9FAJph+YRw= 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=O6Z7xG76TTuAkgo UdfUY2eoEuoI=; b=ER/hqcGoq8Fv0lcRpzQiA0H00tsgJd4D5K7mb774KsN1/gl NpIt699cxcnS6/pqXoajYa/FEuP2e1OxDlmARKYXBt5aFZqUyDzM103HrBVnJLaa 2z2qrenIXKg9j8bW5OS5TjhIiedszhtFrsmpU5HBh1wpsQ0rkjV7ZBpkOtfU= X-Sasl-enc: QA6B73tyS1i9DvM8kfr4NMEayXNK3yiKbN8mXfF9N7Z1 1471727856 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 9EF7BCCDC5; Sat, 20 Aug 2016 17:17:35 -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> 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: <0acba141-4701-d9c2-0ddb-46d1f60ff55b@fastmail.net> Date: Sat, 20 Aug 2016 22:17:27 +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: <20160820204106.GW8192@zxy.spb.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 21:17:38 -0000 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. 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... 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. 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).