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

[Bruce Simpson]

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).