@nathanael-fetue
About
Hi, I'm Nathanael.
MSc graduate from Toulouse INP - ENSEEIHT (N7), France. I work on hardware/software co-design and low-level performance.
I just completed a six-month research internship at INRIA Rennes, where I designed a hardware isolation mechanism for processing-in-memory processors (UPMEM), measured in a cycle-accurate simulator at 5.54% overhead at most, against 26 to 120% for a software scheme, and validated on FPGA.
I write about computer architecture, operating systems, networking (RDMA/InfiniBand) and the move from research to industry. I am looking for my first role in systems and performance engineering, AI infrastructure or low-level software.
Stack: C/C++, Go, Python, Verilog, Linux, RDMA, Terraform, Ansible.
Contact: nathanaelfetuefoko@gmail.com | linkedin.com/in/nathanael-fetue-foko | github.com/NathanaelFetue
Available for
Nothing here yet.
Comments
NF
Thanks, good catch. They weren't pinned: both modes ran on the same three-vCPU VM with the scheduler free to place the client, the server and the rxe softirq work. So part of that 7.7 µs may be placement rather than the wake-up itself. A pinned rerun (timer on one CPU, softirqs on another) would separate the two; if I run it, the result will be in a later post on CPU cost.
NF
Thanks, you picked the three parts that taught me the most. The third reader surprised me: two threads' guarantees don't carry over to a third, so it needed its own reasoning. And the speed question stays open on purpose. No number until there's a benchmark behind it, and TSan doesn't replace a model checker either.
NF
Thanks for reading so closely. "Nothing has raised an alert yet" was hard to write, but a dashboard someone watches is not detection, and I'd rather be trustworthy than impressive. And yes, checking where the probe sits is the lesson I'll reuse most. Next up: four links and a timer for every RDMA write, still on Soft-RoCE, limits included.