Date: Mon, 1 Mar 1999 14:57:16 -0500 (EST) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Cc: current@FreeBSD.ORG Subject: Re: Request for review: changes to if_vlan.c Message-ID: <199903011957.OAA29166@skynet.ctr.columbia.edu> In-Reply-To: <199903011633.LAA16808@khavrinen.lcs.mit.edu> from "Garrett Wollman" at Mar 1, 99 11:33:06 am
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Garrett Wollman
had to walk into mine and say:
> <<On Sat, 27 Feb 1999 23:37:10 -0500 (EST), Bill Paul <wpaul@skynet.ctr.columbia.edu> said:
>
> > Interested persons should review the diffs and pipe up if they have
> > some passionate argument argument against them.
>
> Patches look mostly fine.
Okay. I noticed one other thing while playing around today: when
calling SIOCSETVLAN to disassociate a vlan interface with a real
interface, the code should probably be removing the MAC address
in addition to everything else. (The parent interface's address is
added when the association is made, but not removed when the association
is broken.)
> > Also, I should point out that while if_vlan provides the necessary
> > kernel hackery to implement VLANs, there isn't any user space utility
> > for configuring vlan interfaces (ifconfig doesn't seem to have any
> > vlan-specific code that I could see, and is no vlanconfig).
>
> I stopped development on vlan(4) when the switch we had that spoke
> 802.1Q was returned to the vendor at the end of our demo period. I
> have 28 on order right now, and should resume work on the driver after
> I get those switches deployed. For interfaces like yours, I would
> have preferred a subinterface mechanism, but I never had the time to
> implement that.
Well... correct me if I'm wrong, but the current code looks like it does
implement "subinterfaces" of a fashion. I could hack the driver to do
what if_vlan.c does, but why do that if if_vlan.c already exists and
does almost exactly what I need it to do.
> Care to implement GVRP while you're at it?
Care to tell me what that is? :) (No, I don't really want to do it now,
whatever it is.)
> > There also is no vlan(4) man page.
>
> See above.
I could probably write them myself, if you like.
> > otherwise I'm going to take it upon myself to hack up ifconfig and
> > write the man pages myself.
>
> I believe ifconfig is the wrong program for the task. There should be
> a separate vlanconfig program. (I wrote one, but it's on my
> laptop where I can't conveniently get to it right now.)
I don't know about that. It seems to me ifconfig is precisely the right
program to use for this task. I already hacked up a local copy of ifconfig
to support it:
router3# ./ifconfig vlan0 vlan 1234 vlandev ti0
router3# ./ifconfig vlan0
vlan0: flags=1843<UP,BROADCAST,RUNNING,SIMPLEX,LINK0> mtu 1496
ether 00:60:08:21:53:6c
vlan: 1234 parent interface: ti0
Took me only about an hour or so to do it (and I was watching TV at
the time). Tell me why a separate program is preferable.
> There are a couple of areas where vlan(4) needs to get some help from
> the underlying driver:
>
> - Promiscuous mode doesn't work at all. It ought to be possible to
> put just a specific VLAN into promiscuous mode, without affecting all
> the others. This probably involves repeating all of the BPF
> does-this-packet-look-like-mine? gluck from the physical interface
> drivers.
Hm. Well, it seems to me that the real problem is that to get promiscuous
mode for the vlan interface, you have to put the parent in promiscuous
mode too. You can do that, but then the parent interface driver gets
hit with extra traffic that it doesn't want.
> - Multicast is similarly broken (and a more serious weakness). There
> needs to be a mechanism to pass multicast group membership down to the
> underlying driver. It may also be necessary to do duplicate
> suppression, which is a real challenge.
It may not be that hard. I could probably do it, if you wanted me to.
I wouldn't enjoy it, but I could do it.
> > ! * If the LINK1 flag is set, it means the underlying interface
> > ! * can do VLAN tag insertion itself and doesn't require us to
> > ! * create a special header for it. In this case, we just pass
>
> Are we certain that all drivers are now doing if_media and no longer
> using IFF_LINK1 for that purpose?
I think you may have missed the point (or maybe I didn't explain it
well). I want to set the LINK1 bit on the _VLAN_ interface (vlan0,
etc...), _NOT_ the parent interface. The problem is that the parent
doesn't want packets with the ethernet vlan header on them, and we need
some way to tell the vlan intertface "Don't bother with rewriting the
packet header; the parent interface will do it for you." Using the LINK1
(actually, I probably should have said LINK0; LINK1 was just the first
thing that popped into my mind last night). The vlan interfaces don't use
ifmedia so there is no conflict.
The idea is, the user (er, admin) knows that he's going to be attaching
to a parent device that can handle vlan header mangling internally, so
he configures the vlan interfaces attached to this particular parent
with a LINK flag that tells it "skip the header mangling". Nothing gets
changed on the parent interface.
> Grammar fault -- core dumped.
>
> (The wording was correct as it was.)
That's why I didn't commit anything yet.
> > * Set the interface MTU.
> > + * This is bogus. The underlying interface might support
> > + * jumbo frames.
> > */
> > if (ifr->ifr_mtu > ETHERMTU) {
> > error = EINVAL;
>
> I belong to the religion which as that if the interface is doing
> ``jumbo frames'' than it's not doing ``Ethernet''. There are all
> sorts of crocks which were perpretrated to allow bridging of FDDI and
> Ethernet, and I have no intention of supporting the same crocks here.
Well I belong to the religion that doesn't like to hear people whine and
complain that "Linux supports this, why don't you?" This isn't to say
that we should pay attention to everybody who complains since some of
them are just out and out crackpots, but I happen to think the jumbo
frame support is a big win (based on the performance stats I've seen).
Maybe we can add another IFT type like IFT_JUMBOETHER and allow setting
of larger MTUs only for IFT_JUMBOETHER interfaces. Hm, no wait... that
won't work. A lot of code in /sys/net explicitly wants IFT_ETHER. I could
change it to accept IFT_ETHER || IFT_JUMBOETHER though.
-Bill
--
=============================================================================
-Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu
Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research
Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City
=============================================================================
"It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness"
=============================================================================
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903011957.OAA29166>