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

11–20 of 62 posts

Re: Designing an Ethernet Switch ASIC

#11

Post by sophacles »

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.

I'm struggling to think of any real-world networking scenario where cut-through switching for ethernet can provide any sort of benefit.

Most data-center networks are involve aggregation/spine/core switches at higher speed than TOR/leaf switches - so the packet has to be buffered.

Most every workload is going to involve port collisions (2 packets at the same time needing the same output port) - again a full buffering required (or drops and throughput reduction).

Bigger networks start using vlans, mpls, ip routing at switches, and vxlan - requiring more lookups per-packet, larger "minimum chunks of packet seen before port is determined" sizes, etc reducing the value of cut-through.

And so on.

But i also struggle to find a scenario where a principle engineer at google is refusing to accept that cut-through switches exist, but rather, was refusing to accept that the scenario they're talking through with you would ever involve an effectively deployed cut-through switch (since that's basically never).

Re: Designing an Ethernet Switch ASIC

#12

Post by noncoml »

sophacles wrote: post #11
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.

I'm struggling to think of any real-world networking scenario where cut-through switching for ethernet can provide any sort of benefit. Most data-center networks are involve aggregation/spine/core switches at higher speed than TOR/leaf switches - so the packet has to be buffered. Most every workload is going to involve port collisions (2 packets at the same time needing the same output port) - again a full buffering…

> but rather, was refusing to accept that the scenario they're talking through with you would ever involve an effectively deployed cut-through switch (since that's basically never).

Nope, the argument was exactly if a cut-through switch exists or ever existed

Edit: Actually the conversation came back to me:

He asked me about the frame format. Once I drew that on the board, he asked why is the DST before the SRC. My answer was in order for the switch to start doing the lookups ASAP and that's when I mentioned that a cut-through switch can switch the packet before it even finishes receiving it.

After that we spend the rest of the interview time arguing if cut-through switches actually exist or not. Both he and I having too big of an ego to let it go..

Re: Designing an Ethernet Switch ASIC

#13

Post by BornToLag »

sophacles wrote: post #11
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.

I'm struggling to think of any real-world networking scenario where cut-through switching for ethernet can provide any sort of benefit. Most data-center networks are involve aggregation/spine/core switches at higher speed than TOR/leaf switches - so the packet has to be buffered. Most every workload is going to involve port collisions (2 packets at the same time needing the same output port) - again a full buffering…

Ethernet frame preemption has been standardized for about 10 years for ultra low latency applications. See 802.1Qbu:

"Defines a class of service for time-critical frames that requests the transmitter in a bridged Local Area Network to suspend the transmission of a non-time-critical frame, and allow for one or more time-critical frames to be transmitted. When the time-critical frames have been transmitted, the transmission of the preempted frame is resumed. A non-time-critical frame could be preempted multiple times."

Re: Designing an Ethernet Switch ASIC

#14

Post by icedchai »

noncoml wrote: post #12
sophacles wrote: post #11

Earlier quoted context omitted.

I'm struggling to think of any real-world networking scenario where cut-through switching for ethernet can provide any sort of benefit. Most data-center networks are involve aggregation/spine/core switches at higher speed than TOR/leaf switches - so the packet has to be buffered. Most every workload is going to involve port collisions (2 packets at the same time needing the same output port) - again a full buffering…

> but rather, was refusing to accept that the scenario they're talking through with you would ever involve an effectively deployed cut-through switch (since that's basically never). Nope, the argument was exactly if a cut-through switch exists or ever existed Edit: Actually the conversation came back to me: He asked me about the frame format. Once I drew that on the board, he asked why is the DST before the SRC. My a…

So he didn't want to google it?

Re: Designing an Ethernet Switch ASIC

#16

Post by brcmthrowaway »

sophacles wrote: post #11
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.

I'm struggling to think of any real-world networking scenario where cut-through switching for ethernet can provide any sort of benefit. Most data-center networks are involve aggregation/spine/core switches at higher speed than TOR/leaf switches - so the packet has to be buffered. Most every workload is going to involve port collisions (2 packets at the same time needing the same output port) - again a full buffering…

What do HFT switches do?

Re: Designing an Ethernet Switch ASIC

#17

Post by gjvc »

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.

"principal"

Re: Designing an Ethernet Switch ASIC

#19

Post by zrobotics »

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 could fit in the project budget.

Re: Designing an Ethernet Switch ASIC

#20

Post by toast0 »

sophacles wrote: post #11
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.

I'm struggling to think of any real-world networking scenario where cut-through switching for ethernet can provide any sort of benefit. Most data-center networks are involve aggregation/spine/core switches at higher speed than TOR/leaf switches - so the packet has to be buffered. Most every workload is going to involve port collisions (2 packets at the same time needing the same output port) - again a full buffering…

> I'm struggling to think of any real-world networking scenario where cut-through switching for ethernet can provide any sort of benefit.

When it works, it reduces latency and reduces buffer memory usage a smidge. This ASIC switch can't afford to buffer any packets, so cut through is the only option... AFAIK, most ethernet switches have at least some buffer memory...

> Most data-center networks are involve aggregation/spine/core switches at higher speed than TOR/leaf switches - so the packet has to be buffered.

If you have traffic flowing within a rack, you can cut through for that where the machines attach to the TOR switch at the same speed.

If you have traffic between racks, and it goes through a spine, it likely needs to buffer at the TORs, but it could cut through at the spine.

> Most every workload is going to involve port collisions (2 packets at the same time needing the same output port) - again a full buffering required (or drops and throughput reduction).

Depends on the workload and redundancy requirements. If you want to have dual link aggregation and no loss of throughput with a single lost link, you'll upgrade line speed when link utilization is at 50%, so maybe 50% of packets could be cut through (depending on burstiness). If latency is a key driver, you may have line speed much higher than throughput and have very little utilization.

Post reply on HN