Network FPGA Engineer, @oxidecomputer
PhD, University of Washington '25
Princeton University '18
Sometimes networking and computer architecture. Mostly cats.
she/her
Network FPGA Engineer, @oxidecomputer
PhD, University of Washington '25
Princeton University '18
Sometimes networking and computer architecture. Mostly cats.
she/her
Since it's #worldbeeday, let me suggest reading @Hello_KayT's recent paper on Beehive, a flexible networking stack for direct-attached FPGA accelerators:
Direct-attached accelerators, where application accelerators are directly connected to the datacenter network via a hardware network stack, offer substantial benefits in terms of reduced latency, CPU overhead, and energy use. However, a key challenge is that modern datacenter network stacks are complex, with interleaved protocol layers, network management functions, and virtualization support. To operators, network feature agility, diagnostics, and manageability are often considered just as important as raw performance. By contrast, existing hardware network stacks only support basic protocols and are often difficult to extend since they use fixed processing pipelines. We propose Beehive, a new, open-source FPGA network stack for direct-attached accelerators designed to enable flexible and adaptive construction of complex network functionality in hardware. Application and network protocol elements are modularized as tiles over a network-on-chip substrate. Elements can be added or scaled up/down to match workload characteristics with minimal effort or changes to other elements. Flexible diagnostics and control are integral, with tooling to ensure deadlock safety. Our implementation interoperates with standard Linux TCP and UDP clients, with a 4x improvement in end-to-end RPC tail latency for Linux UDP clients versus a CPU-attached accelerator. Beehive is available at https://github.com/beehive-fpga/beehive
This is me. Probably clear from some of the details in there. I wrote this in one morning after getting tired of all the ass covering and one-sided statements where the department gets to put out whatever narrative it wants at the expense of others. Irene, in this case.
I'm just getting used to being able to offer up more details. Up until January when the investigation ended, it was about 9 months of being strongly advised to not say anything, even within the department.
This was not the first time I was asked not to speak publicly about lab issues.
I reference another go-around with the department in trying to get systemic problems in a different lab addressed in my second year. It was a much more "routine set" of problems (MIA advisors, bad advising, unrealistic expectations, ect.) in that case. Again, we were asked not to speak about it public because the department was working with us in good faith.
A perspective from one of the UW women. I’ve linked it in my blog post. https://irenezhang.net/uw-women-statement.txt
Awful but sadly not unexpected.
You can tell how sloppy and vindictive this is by the fact that it includes a joke on discuss.systems, including my full, unredacted name and handle for an “anonymized report”.
I don’t even go to school here! I’m not even supposed to be here today!
https://discuss.systems/@irene/113941249795492715
For everyone that has been following the situation at the University of Washington Allen School, the HR report is done after 6 months. The full report is linked in this article. https://www.dailyuw.com/news/independent-investigation-finds-uw-systems-lab-conduct-not-harassment/article_d0dce740-e1ed-11ef-9c45-5fc644de6b05.html