switch chip driver

Hello,

I have a driver for 5-port switch, representing the switch as one eth0 device from the OS perspective. I would like to make it have eth0..eth4 ports respectively, so that I could treat each port individually.

As far as I understand, the kernel network machinery for Ethernet works like this:

struct net_device *dev; alloc_netdev(sizeof(private_structure), "eth%d", ether_setup); ... register_netdev(dev); ...

Am I right that I have to implement this sequence for each interface I register in the system's data structures? So for the 5-port switch it'd be something like:

int switch_init(int unit) { struct net_device *dev; alloc_netdev(sizeof(private_structure), "eth", ether_setup); sprintf(dev->name, "eth", unit); ... register_netdev(dev); }

.. or the whole thing is a way more complicated than I think?

Thanks.

--
Mark
Reply to
Mark
Loading thread data ...

Hello,

Mark a écrit :

What kind of switch chip is it ?

If it is a "software" switch (i.e. 4 independent physical ethernet interfaces and one internal virtual interface being eth0, frame switching being done by the software driver like a software bridge), then it may be possible to rewrite the driver in order to use the physical devices as separate devices.

However if it is a hardware switch (the device eth0 being the internal connection to the switch) just like an external switch then this is not possible unless it supports VLANs : then you could create one VLAN per physical port and create VLAN tagged subinterfaces on the internal interface eth0. This way each physical port would be associated to a VLAN subinterface.

Reply to
Pascal Hambourg

That may be a huge mistake. Typical 5-port switches can only separate the ports by using VLAN tagging. If your driver forces this mechanism to be used to create separate interfaces, those interfaces will be unable to support VLAN tagging. You will also force any switching to be done between those ports to be done in software, negating the point of having a 5-port switch.

DS

Reply to
David Schwartz

What I have is bcm5358u - Broadcom's SoC containing MIPS core, 5-port switch core connected to the CPU via internal MII.

I think I should've given more details in my original message.

bcm5358's ethernet driver supports VLANs and currently it seperates these 5 ports in two VLAN groups. Now I'm going to use two ports of bcm5358 to connect to external 24-port switch, thus these two ports will serve as WAN and LAN ports respectively and should be able to have IP addresses on them. I see no other reason rather then make them look distinct interfaces form the point of view of OS.

PS. I've skimmed through

formatting link
and it seems that it's possible to do what I need, although the kernel ported for my platform is older and doesn't have some features used by DSA.

--
Mark
Reply to
Mark

I can't see how it would happen: I'm not disabling switching function, neither do I disable VLAN grouping, i.e. any frame entering a switch port would be switched in hardware according to the forwarding table. So as I understand, as long as I don't assign IP address on those interfaces, everything should work as before; assigning IP addresses will imply NAT on those interfaces.

Please also see my other reply to Pascal.

--
Mark
Reply to
Mark

I thought you wanted to present them as five separate interfaces. If you do that, how can you also have the hardware switch packets between them?

n

Huh? How did NAT get into this?

If you think that just having two operational interfaces with no addresses assigned to them implements some kind of switching or bridging, you are mistaken.

Perhaps I'm misunderstanding you, but it sounds like you don't really understand the basics about specifically what a network interface driver does.

DS

Reply to
David Schwartz

As I wrote earlier to Pascal in this thread, I will basically have 2 internal ports connected to external 24-port switch, and I need these two ports configured as WAN and LAN interfaces. I thought the easiest way would be have the seperate interfaces.

Hm.. now I'm very confused.

I don't really understand this point -- if a packet enters the switch, before it gets any network interface (eth0..eth4) it is supposed to be already hardware switched, unless the switch is configured to forward all frames to the CPU port (in this case it will be processed by the network driver).

That's why I'm here, asking the questions.

--
Mark
Reply to
Mark

David Schwartz wrote: [skip]

Allright, let's reason about this once again. Suupose we have 5 distinct network interfaces, eth0 is for switch port 0, eth1 - port 1 and so on. Now, a frame enters the port 0, the driver picks the frame off the switch and pushes it up the network stack, so in this case all switching/tagging is done in driver or in higher OS layer.

Am I right, is that what you meant ?

On the other hand -- consider the 5-port switch and the driver representing single interface to OS (that single interface is the one connecting the switch to CPU), that's how it's implemented now. Any frame entering the switch port is hardware switched and if necessary (depending on the switch configuration) is also forwarded to the CPU port and will be accepted by the driver and moved, if necessary, up the tcp/ip stack.

--
Mark
Reply to
Mark

This will work fine. I think perhaps David missed the other post where you mentioned the external 24-port switches.

Most small or medium routers work in this way, using VLAN tags to get multiple virtual Ethernet devices from the managed switch. The disadvantage is, as David says, that you can't then pass VLAN tagged packets through the router. But that's okay - if you have such a large and advanced network that you are wanting to pass VLAN tagged packets here then you would probably have faster and more advanced hardware anyway.

I haven't used these Broadcom devices on their own, but I use LinkSys routers with similar devices and OpenWRT firmware. Using the VLAN tagging on the built-in switch gives you enormous flexibility - far more than you get with the original firmware.

If you can't make use of the switch driver code from tomoyo, you could look at openwrt and see if you can use the code from there (although I believe the two projects have a common ancestor, so the code there may be the same).

The external switches will handle switching within their local network. Packets aimed off the network will be passed on to your device (assuming you have the routing and addresses configured correctly). But your two virtual ports eth0.1 and eth0.2 on your device need an ip address so that machines on the network can pass packets to them for forwarding.

It /is/ possible to set up your device as a bridge between eth0.1 and eth0.2 rather than a router, with no IP addresses on the ports, but unless you are doing something really advanced (such as using ebtables to control the bridge), a patch wire between the two 24-port switches would be more efficient.

Reply to
David Brown

ct

ow,

Right, but the hardware switch has no way to do this other than tagging the packet with a VLAN when it comes in and stripping that VLAN off to decide which of the five distinct interfaces to pretend it received the packet on. If you do this, you will be unable to support VLAN tagging because you will be using VLAN tagging to make the switch look like distinct interfaces when it's actually only one switch.

ng

h

the

Right, which enables the switch to act like a switch. It also enables you to set ports to not have their VLAN tags modified, allowing the operating system to support VLAN tagging.

Suppose the switch receives a packet on physical port one. How will you be able to make that packet appear to have been received on interface one if you don't set the physical port to tag the packet? And if you do set the physical port to tag the packet, how can you support VLAN tagging? (You can either use VLAN tagging to make VLANs or to make five interfaces, but I don't see how you can do both.)

DS

Reply to
David Schwartz

Let's try it again, from a simpler point of view.

Suppose the switch receives two broadcast packets on port 1, one tagged VLAN 10 (call this '1,10') and one tagged VLAN 11 (call this '1,11'). Then the switch receives two broadcast packets on port 2, one tagged VLAN 10 (call this '2,10') and one tagged VLAN 11 (call this '2,11').

I presume your intention would be packets 1,10 and 1,11 would come out logical interface 1, tagged with VLANs 10 and 11 respectively. And packets 2,10 and 2,11 would come out logical interface 2, tagged with VLANs 10 and 11 respectively.

Is that a correct description of the effect you want?

Now, how can you get it?

Suppose you configure physical ports to ignore incoming VLAN tags. Now, you can't tell packets 1,10 and 1,11 apart. So you have no way to tag them correctly when you pass them to the operating system.

Suppose you configure physical ports to pass incoming VLAN tags. Now, you can't tell packets 1,10 and 2,10 apart. So you have no way to route them to the correct virtual interfaces when you pass them to the operating system.

Since each of these four packets must be handled differently, you would need to assign them four different tags in order for the driver to tell them apart. However, there is no way to give them four different tags -- you can only either pass the tag or set the tag.

And this is only one problem you would have trying to make this work.

DS

Reply to
David Schwartz

David Schwartz a écrit :

I didn't read any need for external VLAN tagging in Mark's posts.

What do you mean by "ignore" ? Replace the incoming VLAN ID with the one associated to the port ?

Reply to
Pascal Hambourg

Mark a écrit :

[...]

Doesn't that current setup meet this need ? You can assign one VLAN group as WAN and the other one as LAN, using either port of each group to connect to the switch. You just need is to create and use the VLAN subinterfaces for the two VLAN IDs in Linux. Ok, they won't be named eth0 and eth1 but eth0. and eth0..

Reply to
Pascal Hambourg

Mark, could you give us a more precise picture of your setup here?

As I see it, you have an external 24-port switch. Is this a managed switch (that can assign VLAN tags according to port)? If it is not a managed switch, then I can't see why you want to connect both ports on your broadcom device to the switch. If it /is/ a managed switch, then everything you are trying to do with the broadcom device can be handled more easily using the managed switch.

I have been under the assumption that you have one port of the broadcom device switch connected to your WAN network (such as an ADSL modem), while another port is connected to an unmanaged external switch for a LAN.

Reply to
David Brown

My point is that his driver could not support VLAN tagging. It also could not support hardware switching.

Replacing the tag is one way of ignoring it. Stripping it off is another way.

DS

Reply to
David Schwartz

5
e

to

look

Do you understand the way people would normally do this? They would assign one VLAN ID to the first port and one to the second, say 1 and

  1. They would then use the operating system's VLAN support to create interfaces 'eth0.1' and 'eth0.2', each of which can be assigned an IP address and treated as a distinct interface by the OS.

This has two huge benefits over your approach:

1) They could still set a third port to preserve VLAN tags and connect it to an intelligent switch. This would allow them to extend both interfaces over a single link. 2) They could add a third port into either VLAN and preserve the hardware switching capability.

Distinct interfaces would make both of these things impossible.

DS

Reply to
David Schwartz

There was perhaps misunderstanding on both sides, so I've drawn a small picture at

formatting link
describing the architecture of the device.

Port 0 is WAN, port 1 is for LAN of internal switch are fixed, port 5 internal MII to CPU, other ports will not be used. Ports A and B of the managed 24-port switch are fixed and wired to port 0 and 1 respectively.

So, there will be two VLAN groups on the managed switch:

SwitchGroup 1 - port A.... for WAN SwitchGroup 2 - port B... for LAN

(such are the requirements). On the other hand, the CPU will have two vlan groups:

Group 1 - port 0 & 5 (wan) Group 2 - port 1 & 5 (lan)

These groups on CPU are managed and created by the Ethernet driver, so they are not visible to OS. As you suggested, I should use, for example, vconfig tool to create two vlan interfaces:

eth0.vlan1 (wan) eth0.vlan2 (lan)

where the underlying interface is only eth0.

Does it look fine now ?

PS. And to make the ir work, I will also have to set up NAT and iptables on CPU side.

--
Mark
Reply to
Mark

There was perhaps misunderstanding on both sides, so I've drawn a small picture at

formatting link
describing the architecture of the device.

Port 0 is WAN, port 1 is for LAN of internal switch are fixed, port 5 internal MII to CPU, other ports will not be used. Ports A and B of the managed 24-port switch are fixed and wired to port 0 and 1 respectively.

So, there will be two VLAN groups on the managed switch:

SwitchGroup 1 - port A.... for WAN SwitchGroup 2 - port B... for LAN

(such are the requirements). On the other hand, the CPU will have two vlan groups:

Group 1 - port 0 & 5 (wan) Group 2 - port 1 & 5 (lan)

These groups on CPU are managed and created by the Ethernet driver, so they are not visible to OS. As you suggested, I should use, for example, vconfig tool to create two vlan interfaces:

eth0.vlan1 (wan) eth0.vlan2 (lan)

where the underlying interface is only eth0.

Does it look fine now ?

PS. And to make the ir work, I will also have to set up NAT and iptables on CPU side.

-- Mark

Reply to
Mark

OK, I think I see what you are doing now. And it looks like you are trying to do double the work.

Here is how I would arrange things:

On the external managed switch, set up a VLAN for the WAN group (say, VLAN 1). You probably only need a single port in that group - set that port to untagged VLAN 1.

Set up a second VLAN (say VLAN 2) for the LAN group. Put as many ports as you want on that group, all untagged.

Have one port (such as "A") on the switch in both VLAN 1 and VLAN 2, set for tagged packets. This port is connected to a single port on the broadcom device.

Don't use the broadcom switch at all. All the packets coming in to the ethernet port are already tagged as VLAN 1 or VLAN 2. In your Linux setup, simply set up two virtual ethernet ports eth0.1 and eth0.2 - these are your WAN and LAN interfaces.

That way you have full separation of the two networks, and full control (at the external switch) of which ports are on which networks. On the Linux side, you can use NAT, iptables, and whatever between these two interfaces.

This saves all the effort in configuring the broadcom switch. And if you ever want to make more isolated LANs, you just make a new VLAN group on the managed switch and a new virtual ethernet port on the router. You can also use tagged trunks to let you split up the VLANs further up the line if you want.

If you are dealing with a PHB that says there must be two cables from the managed switch to your box, with LAN traffic on one and WAN traffic on the other, then set port A on the switch to tagged packets VLAN 1, and port B on the switch to tagged packets VLAN 2. Connect both to the broadcom switch, but leave the switch as unmanaged so that the tags all pass through to your Linux kernel.

Reply to
David Brown

David, thank you very much for this suggestion, it looks simpler and more obvious. Just to make sure I got what you suggest:

(1) VLAN group 1 (untagged) on the external switch - port A + any portwhich will serve as WAN port. (2) VLAN group2 (untagged) on the external switch - port A + as many ports as I want to be included in LAN group (3) Port A is set tagged (for example, if a frame arrives a port of group 1 it will leave the group as tagged with vlan1; if the frame arrives group 2, them it leaves the group 2 tagged with vlan2 -- I believe that is correct?) (4) I need only *one* port connecting Broadcom to the ext. switch.

The one fundemantal question remained though:

- any intelligent switch processes incoming frames according to forwarding and VLAN tables; but why do you always mention of tagged frames? As far as I can understand the 802.1q standard, a switch not necessary has to tag all incoming packets, it may have some other associative rules to apply to the packets.

-- Mark

Reply to
Mark

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.