Hi Ben, Thanks for writing back. More inline below.... On Wed, 20 Jul 2005 10:42:56 -0700 Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote: > Alex Zeffertt wrote: > > Hi list, > > > > I need the vlan code to do something rather unusual, and I think I know how to do it but I > > thought I'd check it with you first to see if it is sane.... > > > > We've designed a PowerPC based embedded board whose integrated MII bus is attached to a switch > > fabric containing 10 other ports. What we want is for this to be made to look like 10 seperate > > NICs, namely eth0, eth1, ..., eth9. > > > > My idea is to configure the switch fabric to tag each frame entering the PHY from the outside > > world with a VID which identifies the port on which it entered. In the other direction frames > > from the CPU would have their tags removed by the switch fabric and used to determine to which > > port they should be sent. This way all I need to do is to use the vlan module to create 10 > > net_devices over the top of the original net_device. > > > > This leaves two remaining problems: > > > > i) How do I make the vlan devices look like eth0 ... eth9 > > > > ii) How do I enable mii-tool ethN to configure portN of the switch fabric. > > > > Here are my ideas... please let me know what you think of them: > > > > i) I need to add a new VLAN_NAME_TYPE, say VLAN_NAME_TYPE_NEXT_ETH_N. This will require > > changing vlan.c, vlanproc.c, and vconfig.c. If this is selected then vlan_name_type will be > > rewritten to"eth%d". I also need to ensure my original device is called something other than > > eth0, say raw0. > > How about just using user-space tools to rename the interface? Since it will actually > be passed (and receive) 802.1Q VLAN frames, you might want to leave it named vlan.foo. > I thought about that. My device driver could register eth0. Then I could use iproute2 to rename eth0, and all the vlan devices eth0.10, eth0.11,..., eth0.19: ip link set eth0 name raw0 ip link set eth0.10 name eth0 ... ip link set eth0.19 name eth9 This solves problem (i) but not problem (ii). Whenever mii-tool (or any other userspace tool) calls device ioctls for eth0, ... , eth9 it will end up being routed to the vlan module which doesn't implement dev->do_ioctl(). I see your point about leaving the vlan tag in the name but I don't think it is valid in this particular scenario. Although each frame sent to the CPU over the MII has a tag, the frame does not have a tag when it enters the switch via one of the other ports. Similarly, when the CPU sends a frame over the MII it is tagged, but the switch removes the tag before sending it out. Therefore the tags are used solely on the MII bus as a way of indicating on which port the frame was received/to which port it should be sent. This is an implementation detail that I want to hide and make it look like I've just got 10 NICs. Leaving it named vlan.foo is not right for us for another reason too. We already have a lot of user space code (currently compiled for another platform) that assumes eth0, eth1, ... exist. > > ii) I need to add an ioctl handler to vlan.c and set newdev->do_ioctl. This handler needs > > to pass all ioctls on to realdev->do_ioctl() EXCEPT for SIOCGMIIPHY and SIOCDEVPRIVATE. These > > latter ioctls ask the driver what the PHYs MDIO address is. The original driver cannot know > > this since the device to which it is connected contains several PHYs and responds to several > > MDIO phy addresses. > > > > Therefore I think this needs to be specified when the vlan device is created with an optional > > extra parameter, e.g. > > > > vconfig add <interface-name> <vlan_id> [<phy_addr>] > > I would rather keep this out of the official VLAN code, though you are welcome to hack > your private coppies, of course. My suggestion here is to use your switch0 device to handle > the custom IOCTLs. > Fair enough. I didn't think it would be useful to *that* many other people. I cannot make it work by *only* changing my device driver though. This is because mii-tool &c. put the device name in the ioctl arguments and this is used to route the ioctls to the right place. Therefore, the ioctl will initially end up in the vlan code, which currently doesn't implement them. > > When mii-tool is run it will first ask the vlan module what the phy address is. The vlan module > > will then respond with the phy address specified on the vconfig command line. Then mii-tool > > will ask the vlan module to read or write some data using the phy_address it just obtained. The > > vlan module will then just relay this command to realdev->do_ioctl() which controls the MDIO > > hardware. > > Since this would require user-space to know the address anyway (when it creates the VLAN), > just get the mii to get the physical address from where-ever the creator of the VLAN would > have gotten it from. Instead of having vlan relay the ioctl, just send it directly to your > raw device. > > Btw, sounds like an interesting device...is this available for public consumption? > > Ben > It's the marvell 88e9095. All information regarding this device is under NDA. However, there are many switch fabrics out there which can do similar things. The KS8995 is an example. These chips make a cost sensitive way of building managed switches. If this tagging business can be made to work it would also be a cheap way to build a multi ethernet port router. Alex
