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

41–50 of 62 posts

Re: Designing an Ethernet Switch ASIC

#41

Post by userbinator »

inigyou wrote: post #30
icedchai wrote: post #14

Earlier quoted context omitted.

So he didn't want to google it?

If you Google it, you find many copies of theory, but not a single reference to a cut-through switch ever existing in real life.

What "real life" are you living in? The references in https://en.wikipedia.org/wiki/Cut-through_switching already link to several. Here's a few more from all the major vendors.

Cisco:

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/ne...

HPE Aruba:

https://arubanetworking.hpe.com/techdocs/AOS-CX/AOSCX-CLI-Ba...

Fortinet:

https://docs.fortinet.com/document/fortiswitch/7.2.7/adminis...

Arista:

https://arista.my.site.com/AristaCommunity/s/question/0D55w0...

Nvidia/Mellanox:

https://enterprise-support.nvidia.com/s/article/switch-forwa...

Extreme Networks:

https://documentation.extremenetworks.com/Switch%20Engine%20...

Re: Designing an Ethernet Switch ASIC

#42

Post by userbinator »

icedchai wrote: post #33
stinkbeetle wrote: post #26

Earlier quoted context omitted.

I see you've never had a run-in with a blowhard in a position of power. Lucky.

I've had it happen in an interview, many years ago. I told him we'd have to agree to disagree. After I was hired, he admitted he looked it up and I was correct (some weird SQL question he asked.)

After I was hired, he admitted he looked it up and I was correct

The best possible outcome.

Re: Designing an Ethernet Switch ASIC

#43

Post by userbinator »

inigyou wrote: post #5
noncoml wrote: post #2

“ Cut-through vs Store-and-Forward” I had a Google interview collapse because the last interviewer was a Principle Engineer who just couldn’t accept that a switch will ever forward a frame before reading in full and checking the FCS. I was too much of an idiot to go along with it and instead ended up having an argument with him.

Cut-through is applicable in a minority of scenarios which are sometimes common. The majority of switches, especially the ones that support any advanced features at all, can't use it. Even when you can use it, you still can't use it all the time because of port conflicts. As far as advanced features go, even adding and removing VLAN tags is a headache in a cut-through switch.

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 references" needed.

Re: Designing an Ethernet Switch ASIC

#45

Post by imtringued »

zrobotics wrote: post #19

This is extremely cool, I've played with FPGA design but never really even looked into custom ASIC design due to budget concerns. I hadn't heard of the tinytapeout project. Any recommended links for getting started? I have a (really dumb, kinda meme-y) project involving a dead hakko soldering iron and "Internet of Soldering", a custom ASIC for the actual front-end would be the appropriate level of silly and possibly…

The tiny tapeout project doesn't really fix the economics either. There's the obvious IO bottleneck, but worse than that, a 1000 LUT FPGA fits bigger designs and costs almost nothing. Like $2.50/FPGA at 1000 units.

Re: Designing an Ethernet Switch ASIC

#46

Post by crote »

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

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.

Re: Designing an Ethernet Switch ASIC

#47

Post by crote »

userbinator wrote: post #43
inigyou wrote: post #5

Earlier quoted context omitted.

Cut-through is applicable in a minority of scenarios which are sometimes common. The majority of switches, especially the ones that support any advanced features at all, can't use it. Even when you can use it, you still can't use it all the time because of port conflicts. As far as advanced features go, even adding and removing VLAN tags is a headache in a cut-through switch.

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 intentionally send out the wrong FCS on transmit if you determine the receive FCS is invalid.

Re: Designing an Ethernet Switch ASIC

#49

Post by inigyou »

crote wrote: post #46
inigyou wrote: post #29

Earlier quoted context omitted.

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

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.

Re: Designing an Ethernet Switch ASIC

#50

Post by zamadatix »

crote wrote: post #46
inigyou wrote: post #29

Earlier quoted context omitted.

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

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"?
Post reply on HN