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.
Designing an Ethernet Switch ASIC
31–40 of 62 posts
Re: Designing an Ethernet Switch ASIC
#32Earlier 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.
“Arista data planes support these packet forwarding modes: Store and forward: the switch accumulates entire packets before forwarding them. Cut through: the switch begins forwarding frames before their reception is complete.”
Re: Designing an Ethernet Switch ASIC
#33Earlier quoted context omitted.
So he didn't want to google it?
I see you've never had a run-in with a blowhard in a position of power. Lucky.
Re: Designing an Ethernet Switch ASIC
#34This 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…
As the designer of "an ethernet connected beacon that counts and never overflows until the heat death of the universe" ( https://talesonthewire.com/projects/until_heat_death_do_us_p... ) I believe you have found the perfect audience for a memeish hardware project. So don't expect anything but my upmost support. :) I detailed the roadmap for custom ASIC design a bit here: https://talesonthewire.com/projects/two_weeks_…
Although I should point out that you missed the opportunity tor making the world's slowest counter and avoiding needing any expensive memory. Just declock it to an extreme degree. Hard to debug a design that never outputs anything for literal eons though.
Re: Designing an Ethernet Switch ASIC
#35Earlier 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.)
No, he didn’t want interrupt the interview to start checking out phones.
“I told him we'd have to agree to disagree.”
That’s where I went wrong. But I like to think learned my lesson.
Re: Designing an Ethernet Switch ASIC
#36Earlier quoted context omitted.
> So for everyone else also running multiple instances of experimental hardware on their local network I have added an additional 2 Byte magic number using the all so original 0xCAFE (little endian) allowing packet parsers to distinguish between this ASIC’s experimental traffic and your other experimental traffic. Just saying, it's good form to do network stuff in big endian. Although since it's already done I dunno…
If your 0xCAFE gives you a 0xFECA1A55, stop going there...
Re: Designing an Ethernet Switch ASIC
#37Earlier 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…
The two scenarios I can think of that definitely make use of cut-through are timekeeping systems, and HFT. The latter goes even further, where the switches at the exchange do cut-through, but also ensure the packet is broadcast to multiple ports at the exact same time. This is done so that no specific HFT firm get an advantage from being on port 10 rather than port 20. They even measure out the outgoing fibers to be…
Re: Designing an Ethernet Switch ASIC
#38That 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…
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.
Re: Designing an Ethernet Switch ASIC
#39“ 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.
Then I was disappointed to enter the real world of networking and learn that it wasn’t actually used as often as I had been led to believe due to conflicting with higher priority features.
So the interview may have been a conflict between textbook learning and the Google engineer’s practical experience. It’s tough to encounter that conflict in interviews because you get two people talking past each other.
Re: Designing an Ethernet Switch ASIC
#40Earlier quoted context omitted.
As the designer of "an ethernet connected beacon that counts and never overflows until the heat death of the universe" ( https://talesonthewire.com/projects/until_heat_death_do_us_p... ) I believe you have found the perfect audience for a memeish hardware project. So don't expect anything but my upmost support. :) I detailed the roadmap for custom ASIC design a bit here: https://talesonthewire.com/projects/two_weeks_…
Thanks for the pointers, hopefully I get some time to get started in that project soon! Although I should point out that you missed the opportunity tor making the world's slowest counter and avoiding needing any expensive memory. Just declock it to an extreme degree. Hard to debug a design that never outputs anything for literal eons though.
So, since clocking low can't save you many bits, might as well give it enough bits to handle any clock up to the limits of your transistors.