Re: MAC address issue

On Sat, Jan 19, 2008 at 11:18:41AM +0100, Ignatios Souvatzis
wrote:
> On Fri, Jan 18, 2008 at 10:54:09PM -0800, jonathandsg.stanford.edu wrote:
> > 
> > In message <20080118170120.GL1868che.ojctech.com>David Young writes
> > 
> > >Let us put aside lladdr preferences, and use
only the 'active' flag,
> > >instead.  Only one lladdr may be active at a
time, deleting an active
> > >lladdr is not allowed (EBUSY), and setting a
second lladdr to 'active'
> > >clears the 'active' state on every other
lladdr.
> > 
> > 
> > Huh? What about hardware capable of, and IETF
protocols which call
> > for, multiple active link-level addresses on a
single interface??
> 
> Do those exist? I wasn't aware of that. Can you name
one, so that
> we can consider the exact interface model used? E.g.

The ethernet built into the Atheros SoC has the capability. 
Judging by
tlp_filter_setup(), the DEC Tulip does, too.  I'm sure there
are others.

> > Are you proposing a user/kernel API which makes
those ~impossible?
> 
> I'm actually needing this, because the
per-Macaddr-limit in German
> Telekom's PPPoE routers is set to 1, and I'm using two
providers
> simultaneously. I'm emulating this using bridge(4) and
tap(4). I
> guess this is not desirable in the high performance
case.

When a NIC's address filter has more than one slot for
unicast addresses,
we should take advantage when that will improve bridge(4)
performance.
We should also take advantage of hardware VLAN support such
as the
ADM5120 SoC provides.  To get there, we need for bridge(4)
and member
interfaces to pass messages indicating when interfaces go up
& down, when
they assign new lladdrs, they join & leave multicast
groups, they join &
leave the bridge, et cetera.

I really prefer to treat such optimizations in a separate
proposal.
They seem orthogonal to the problem at hand.

> But wouldn't sub-interfaces (similar to what Solaris
does) be easier
> to use? 

IMO, sub-interfaces are an abomination.  Wherever I
have dealt
with a system that has "child" interfaces hanging
off of a "parent"
interface, it seems either that the parent has become a
vestigial or a
second-class interface, or that the parent->child
relationship is tenuous:
one interface may as well be a peer/sibling of the other.

Dave

-- 
David Young             OJC Technologies
dyoungojctech.com      Urbana, IL * (217) 278-3933 ext 24