I seem to be developing a misunderstanding of MAC -- how necessary it can be in specifica cases. Let me give an example: I have a SoC, consisting of ARM-based proccessor with some peripherial (serial interfaces, timers etc.) and switching fabric - everything is on the same chip. The only interface between the control processor and the switch is DMA logic, i.e. CPU receives/transmits packets only via DMA.
This puzzles me: how come that CPU doesn't have MAC block? Isn't it required by the standard to present? Isn't it required by operating systems for proper implementation of device drivers? And lastly - how is MAC address assigned to CPU port in such case ?
A MAC (Medium Access Control) entity is only required for a *network* interface. You said that all you have is a processor, serial ports, timers, and a switching fabric--no network interface(s), hence no MAC.
MAC addresses are not ordinarily assigned to CPU ports, but to network interfaces
-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX
Except for Sun. Well, many Sun boards have ethernet on the same board as the CPU. I beleive that even ones that don't, have the MAC address PROM on the CPU board. When sending a board in for repair (usually exchange), Sun wants one to remove the PROM before sending the board in.
I might have expressed myself not very clearly. The software runs on the CPU; device driver, being a part of that control software, obviously should treat a switch fabric as network interface. If it so, then MAC is necessary, isn't it ?
I have a Realtek switch, which when run 'show mac address-table' shows a MAC address belonging to a CPU port, something like this:
MAC Address Port VLAN FID Static Age
----------------------------------------------------------- xx:xx:xx:xx:xx:xx Fa0/18 1 0 0 6 ... lots of MACs here aa:aa:aa:00:00:01 CPU 1 0 1 15 ...
Which is exactly why I said MAC addresses are not *ordinarily* assigned to CPU ports. Sun uses (used?) the model that I actually prefer, i.e., that the MAC address identifies the *station*, rather than the network interface. There is a discussion of these two models in "The Switch Book," excerpted here:
"There are actually two philosophies for interpreting unicast addresses. One philosophy follows the premise that a unicast address identifies a device (e.g., a workstation or server), as opposed to a network interface installed within the device. Under this philosophy, when a device has multiple interfaces, it uses the same address on all of them. This approach was used in the original Xerox Network System (XNS) and most Sun Microsystems=92 products.
The other philosophy, that an address uniquely identifies the interface rather than the device, sees more widespread application today, and is the model assumed in this book (even though the author has an affection and longing for the 'architectural purity' of the single address per device model). Using the address-per-interface philosophy, a device with multiple interfaces will have multiple unicast addresses assigned to it.
Both philosophies are valid, in the sense that both can be made to work properly in a practical network. In neither case is there any ambiguity about the destination for a frame sent to a given unicast address."
Rich Seifert, The Switch Book (Wiley, =A9 2000) All rights reserved.
-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX
Why would a CPU directly connected to a switch fabric treat the fabric as a network interface? Does the CPU appear as a station on the network being switched by the fabric, or is it simply the control processor?
In this case, the CPU port appears as a station on the network, hence the CPU is assigned a MAC address. This allows stations connected to other ports on the switch to send messages to the switch CPU. If this is also the case with your SoC application, then you may also need to assign a MAC address to the CPU.
However, this does NOT mean that the CPU must "talk" to the switch fabric through a MAC entity, e.g., an Ethernet-like interface. The CPU can talk to the switch fabric through whatever means are available (i.e., a DMA channel), and receive messages sent to it by decoding the MAC address assigned to the CPU. Don't confuse the function of assigning a MAC *address* to a CPU (for the purpose of determining whether messages are being sent to that CPU or not) with the inclusion of a network interface containing a MAC entity (such as an Ethernet interface).
Does that make sense?
-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX
Actually, the switch' SDKs I saw were designed in this way (although they supported only one operating system - Linux). Perhaps this is because among the driver models available in Linux (character, block, network, PCI, USB drivers), the network driver is the most appropriate to match requirements.
[skip]
I think, now it is clear to me. Thanks a lot for clarifications.
Cabling-Design.com Forums 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.