From owner-freebsd-current Mon Mar 1 11:51: 2 1999 Delivered-To: freebsd-current@freebsd.org Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (Postfix) with SMTP id 62D0115422 for ; Mon, 1 Mar 1999 11:50:54 -0800 (PST) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id OAA29166; Mon, 1 Mar 1999 14:57:17 -0500 From: Bill Paul Message-Id: <199903011957.OAA29166@skynet.ctr.columbia.edu> Subject: Re: Request for review: changes to if_vlan.c To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Date: Mon, 1 Mar 1999 14:57:16 -0500 (EST) Cc: current@FreeBSD.ORG In-Reply-To: <199903011633.LAA16808@khavrinen.lcs.mit.edu> from "Garrett Wollman" at Mar 1, 99 11:33:06 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 6692 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Of all the gin joints in all the towns in all the world, Garrett Wollman had to walk into mine and say: > < 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 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