[jandrese]

That memory constraint is a real killer on the chip, even one that is a first generation toy like this. Only having 4 entries in the forwarding table is going to be an immediate problem if that switch is ever connected to another switch.

I wonder if it wouldn't make sense for one of the ports to be designated the "uplink" port and if the switch receives a packet destined for something not in the table it forwards it out the uplink port so long as the packet did not arrive via that port. It could even save a bit of memory by not storing entries for the uplink port in the table.

[inigyou]

Correct ethernet switch behavior forwards a packet to all ports if the destination MAC is unknown

[jandrese]

Which would work but in this case is not ideal because the majority of traffic arriving at the switch may not be on the table. Also, it will be constantly blowing away the existing entries in the table causing it to forget about the locally connected devices. Your switch would effectively turn into a hub. The uplink port solution is slightly more clumsy but hopefully prevents it from decaying to the worst case scenario most of the time.

[crote]

Sure, but at that point you're just building a complicated hub, and trying to actually operate it at speed would result in most packages getting dropped due to collisions as it is pretending to be full-duplex while actually only being half-duplex.

[zamadatix]

What do you mean by "pretending to be full duplex"?

[inigyou]

Modern Ethernet networks can be full-duplex because of all the buffering and separation between ports. If you're running ethernet on an actual shared medium like 10BASE5 or hubbed ethernet, it has to be half duplex to handle collisions better.

And the proposed switch design - transmitting most packets to most ports without buffering - is basically a hub. If you transmit two packets at the same time you will most likely create a collision. A real switch can buffer one of the packets.

[zamadatix]

What you're describing are drops, which behave differently than collisions. No frame is successfully delivered in a collision while one is during a drop. This project cannot have collisions because the links are full duplex.

Unknown flooding is actually a pretty base requirement of ethernet switches per the 802.1 standard, even when the table is not full, anyways. Without it you can't form switched paths unless every switch in the path has recently heard a broadcast (or following regular flow) from the intended receiver. If you start each test case as a short loved one with an IPv4 client ARPing for neighbors or in a simple topology the this can easily be missed but wreak havoc in the real world. To not do so is as egregious to say you're an ethernet switch which does not flood broadcasts in terms of false claims of being an Ethernet compliant switch.

[inigyou]

Ethernet switches are complicated hubs.

[throw0101a]

Some of the 'old' names:

> A network switch (also called switching hub, bridging hub, Ethernet switch, and—by the IEEE—MAC bridge[1]) is networking hardware that connects devices on a computer network by using packet switching to receive and forward data to the destination device.

* https://en.wikipedia.org/wiki/Network_switch

[Taniwha]

On TinyTapeout you can add more tiles up to 16 times the size of this (at which point you likely jump to waferspace)

[phire]

There isn't really a restriction that a downstream device will only have one mac address.

It might be another switch. Even if it's not; VM/container networking is often implemented by bridging the host's NIC to a virtual switch, exposing the MAC addresses of all VMs/containers to the network.

[jandrese]

Right, which is why the tiny 4 entry MAC table might be a problem.