Date: Sat, 20 Aug 2016 22:17:27 +0100 From: Bruce Simpson <bms@fastmail.net> To: Slawa Olhovchenkov <slw@zxy.spb.ru> Cc: Ryan Stone <rysto32@gmail.com>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, Ryan Stone <rstone@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, Adrian Chadd <adrian@freebsd.org> Subject: Re: svn commit: r304436 - in head: . sys/netinet Message-ID: <0acba141-4701-d9c2-0ddb-46d1f60ff55b@fastmail.net> In-Reply-To: <20160820204106.GW8192@zxy.spb.ru> References: <fcb33eac-ec99-03c7-57b5-f24f86c4f41a@fastmail.net> <CAFMmRNwDPy4Hd35DrfREZQzjvd89qw=zhEriddG8U8NV7tD=EA@mail.gmail.com> <6f4449f2-d145-8b49-c3f0-433e8ff4d2a2@fastmail.net> <CAFMmRNypgJc00XH277oB3EEGje4xq%2B8_qcJfZu4jjBfTfa7GGQ@mail.gmail.com> <20160820173050.GQ22212@zxy.spb.ru> <CAFMmRNx=2v=M8GCBQ_cN4pnuZ4VnyzncwAgsqMUE=ebz7pkp2A@mail.gmail.com> <20160820184506.GV8192@zxy.spb.ru> <CAFMmRNy-e1uzdtz2cb5DAa9kRd%2BkHg%2BmWbf=HNDWVdGGjOPUWA@mail.gmail.com> <eb4c228e-8efe-b519-e85b-87800b3ec7a1@fastmail.net> <0f42c5fb-f930-c6e3-75d6-df97f67c201d@fastmail.net> <20160820204106.GW8192@zxy.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0acba141-4701-d9c2-0ddb-46d1f60ff55b>