svn commit: r304436 - in head: . sys/netinet

[Slawa Olhovchenkov]

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.