Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Designing an Ethernet Switch ASIC

essenceia.github.io

Post reply on HN
Print view View original

51–60 of 62 posts

Re: Designing an Ethernet Switch ASIC

#51

Post by bcrl »

crote wrote: post #47
userbinator wrote: post #43

Earlier quoted context omitted.

As far as advanced features go, even adding and removing VLAN tags is a headache in a cut-through switch. Not really; it just needs to inject the tag right after the source address, or not pass it through at all; and of course recompute throughout and replace the FCS at the end. Other more advanced packet editing can be done in a streaming fashion too, with the latency only limited by the length of any "forward refer…

But "just recompute the FCS" isn't quite the right approach, is it? With a traditional cut-through switch the entire packet is passed as-is, so you're not modifying a corrupt package. You don't drop it, but the corruption is trivially detectable on the other side. If you naively recompute the FCS on transmit you essentially mark a corrupted package as valid, so you have to compute the FCS on transmit and receive, and…

It's easy enough to write a bit of Verilog to perform partial updates on the CRC to only compensate for what has changed. I did so for an FPGA project I implemented a number of years ago when processing VLAN tags and doing IP forwarding.

That said, there are lazy hardware designers that just slap on a block to recompute the CRC and replace the old one with the new. An experience I had years ago at Red Hat taught me that the hard way as a shiny new Cisco ethernet switch IT deployed ended up costing us weeks of frustration and delayed a release when it caused bit flips in NFS packets during stress testing. The switch was so awesomely advanced that it recomputed the CRC on the bit flipped packets causing kernel builds to fail.

Re: Designing an Ethernet Switch ASIC

#52

Post by throw0101a »

inigyou wrote: post #49
crote wrote: post #46

Earlier quoted context omitted.

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.

Ethernet switches are complicated hubs.

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

Re: Designing an Ethernet Switch ASIC

#53

Post by jandrese »

phire wrote: post #38
jandrese wrote: post #24

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…

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.

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

Re: Designing an Ethernet Switch ASIC

#54

Post by inigyou »

zamadatix wrote: post #50
crote wrote: post #46

Earlier quoted context omitted.

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.

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

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.

Re: Designing an Ethernet Switch ASIC

#55

Post by foobiekr »

bcrl wrote: post #51
crote wrote: post #47

Earlier quoted context omitted.

But "just recompute the FCS" isn't quite the right approach, is it? With a traditional cut-through switch the entire packet is passed as-is, so you're not modifying a corrupt package. You don't drop it, but the corruption is trivially detectable on the other side. If you naively recompute the FCS on transmit you essentially mark a corrupted package as valid, so you have to compute the FCS on transmit and receive, and…

It's easy enough to write a bit of Verilog to perform partial updates on the CRC to only compensate for what has changed. I did so for an FPGA project I implemented a number of years ago when processing VLAN tags and doing IP forwarding. That said, there are lazy hardware designers that just slap on a block to recompute the CRC and replace the old one with the new. An experience I had years ago at Red Hat taught me t…

Wow that rings a bell.

The lack of end to end ECC protection in some packet paths on very high end ASICs is something I just can’t get over.

Re: Designing an Ethernet Switch ASIC

#57

Post by jandrese »

inigyou wrote: post #29
jandrese wrote: post #24

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…

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

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.

Re: Designing an Ethernet Switch ASIC

#58

Post by userbinator »

crote wrote: post #47
userbinator wrote: post #43

Earlier quoted context omitted.

As far as advanced features go, even adding and removing VLAN tags is a headache in a cut-through switch. Not really; it just needs to inject the tag right after the source address, or not pass it through at all; and of course recompute throughout and replace the FCS at the end. Other more advanced packet editing can be done in a streaming fashion too, with the latency only limited by the length of any "forward refer…

But "just recompute the FCS" isn't quite the right approach, is it? With a traditional cut-through switch the entire packet is passed as-is, so you're not modifying a corrupt package. You don't drop it, but the corruption is trivially detectable on the other side. If you naively recompute the FCS on transmit you essentially mark a corrupted package as valid, so you have to compute the FCS on transmit and receive, and…

so you have to compute the FCS on transmit and receive, and intentionally send out the wrong FCS on transmit if you determine the receive FCS is invalid.

Yes, exactly; but that isn't particularly difficult either, compared to all the other packet-editing capabilities that switch ASICs have.

Re: Designing an Ethernet Switch ASIC

#59

Post by lukeh »

You might want to make the port index instead a bit mask, that will let you support multicast and also selective broadcast flooding (although if you have limited space you’ll likely make broadcast flooding the default).

Re: Designing an Ethernet Switch ASIC

#60

Post by zamadatix »

inigyou wrote: post #54
zamadatix wrote: post #50

Earlier quoted context omitted.

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

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 like…

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.

Post reply on HN