I seem to recall Oxide having to switch suppliers over this?
I'm not complaining but it's weird that they're open sourcing the SDK now. Maybe it's to support Mount Evans.
https://bcantrill.dtrace.org/2024/12/08/why-gelsinger-was-wr...
I'd love to be wrong, this is just what people said.
cisco silicon one uses p4 fwiw. internal development though, but the language makes sense for what the things are.
And they would have been nice CV boosters as well (my real motivation!)
From the "P4 workflow" described at https://p4.org/ I see mentions of compiling to x86, but no mention of ARM, and no mention of BPF. So, as someone who discover it, I wonder if this project is still relevant in 2025.
Regardless, OSS is probably the best way to get it onto other architectures.
They went from "we have tons of 3rd party IP in these!" to, "you don't need to download anything, it's in kernel mainline now" in a generation and they're off to the races after that.
Maybe their Ethernet drivers were open before that, I don't remember but, video drivers made them pass a threshold in maturity IMHO.
There are a good number of people that would LOL at this statement, myself included.
Maybe they have such processes now, because at one point . . . Well “mistakes were made”.
So, let's take the next paragraph: "Before P4, vendors had total control over the functionality supported in the network (...) controlled the rollout of new features (e.g., VXLAN), and rollouts took years"
Anyone has a pointer to any actually available hardware capable of L2 and L3 packet processing where I could have implemented VXLAN in, say, weeks using P4? Again, as far as I can tell, it's all either killed-off-a-long-time-ago, "contact us" vaporware, or exotic 40/100-Gb-only Top-o-Rack gear, and even for those, there is nary an "add to cart" button in sight...
P4 is really only needed in data center networks because slower campus/home networks can usually get away with software processing and their lower prices probably can't support the R&D of a programmable architecture.
Nah. 5 years ago this would've been bold. Now it's ridding yourself of the baggage of an almost-dead platform that you're about to make fully dead.
Still appreciate getting the tooling as FOSS rather than just terminating it, but let's not go for delusions here.
The only "cool" player is Microchip, who have been providing full datasheets, register maps, and open sourcing their drivers for years now. But I'm under no illusions they're doing this out of the goodness of their heart, they're doing it because it's one of very few competetive advantages available to them.
(Which is perfectly fine! FOSS drivers are a great competetive advantage! It's not working super well sadly :/ — but part of the problem here is Broadcom's anticompetetive behavior. To my knowledge, any switch OEM producing Broadcom-based gear will get their NDAs and silicon access revoked if they so much as dream about making devices with non-Broadcom silicon.)
¹ Intel has already exited this business some while ago, they only bought Fulcrum Micro to get better NICs basically since every NIC is nowadays also a switch. Tofino was always a "special beast", not quite competing against e.g. Qumran or Trio. Tofino is (was?) better thought of as special purpose FPGA…
I particularly enjoy the winter trips to SF to show my colleagues pictures of the latest cold water surf adventure.
The reality is, you end up with a complex stack with no or homegrown documentation that requires experienced engineers to operate and maintain.
In some environments, that's a perfectly fair trade-off. In most, it isn't.
does anyone know if someone can make this switchdev friendly?
Writing a switchdev driver is an enormous amount of work so it only happens when someone (usually the chip vendor) pays for it. Any code open-sourced by Intel probably won't meet Linux kernel standards so it would have to be completely rewritten (like the tg3 driver from the old days).
Still, of course it would've been better to have released it sooner.
And guess what, the switch may decide to print informational or environmental messages interleaved with the command output, because the commands were meant to be run by a human. Good luck knowing if your state-altering command succeeded when you receive broken JSON.
I ended up regex-removing known environmental messages from command outputs..
You can already run plain Debian on a Mellanox Spectrum device, treat it like a Linux software router, and by the power of magic your routes get pushed into hardware. (Source: device on my table to my right :D) Microchip's SparX-5 should be similar though I don't have one of those to test.
The only switching/routing vendor with an API worth a damn was Juniper - in fact they were the only vendor who was applying CLI changes to the box via their own API, the Way It Should Be Done™.
These days you are spoilt for choice (and price point) with the likes of Arista, HPe (AOS-CX), Cisco (NX-OS, IOS-XR) and plenty of others entering the space.
Vote with your wallet!
As you might imagine, this move from Intel is something that we at Oxide have advocated for strenuously -- and it is a tremendous tribute to the former Tofino team at Intel that this got done. As I hope I made clear in my blog entry: the folks working on Tofino at Intel have been great to work with; they deserved much better than their (former) executive leadership.
[0] https://oxide-and-friends.transistor.fm/episodes/intel-after...
[1] https://bcantrill.dtrace.org/2024/12/08/why-gelsinger-was-wr...
Linux and x86 became unbeatable in the space for 20 years.
They have known how important it is. They won't forget.
The open source part came later, starting with CPU and chipset support, then Ethernet, then GPUs IIRC.
The biggest and sweetest side-effect is Desktop/Personal use Linux support as long as the hardware doesn't do anything janky, or too janky.
Cisco Meraki did; their low end switches are Marvell and their "high end" switches (MS420, MS425, MS450, MS350, MS355) were all Broadcom based. Were because about a year ago they announced the End of Sale of all Broadcom based switches.
Everything above the low end stuff is now Cisco Catalyst. (Although one can argue everything from Meraki is low end apart from their prices)
> Marvell and Microchip are fighting for the scraps
Realtek also. Lots of smaller L2 managed switches based on the RTL93xx series. [1]
But I am not seriously comparing Realtek to Tofino, that's like comparing Hot wheels to the actual car.
This is hilariously accurate.
But like Tofino, it's mostly stuff that is "behind the curtain"at hyperscalers or deep inside closed box switches
Nokia use Broadcom silicon for low-end, in-house for the rest.
I have BeeLink S12 Pro, which I post this comment from, and I like it. However I/O wise, it's not the fastest (x1 NVMe + 2.5" SATA SSD). I also have a GMKTec G3, which has a x2 NVMe and M.2 SATA Slot. I have recently seen a "Minix Z100" fanless, which has x4 NVMe but no SATA, however it has 2.5gbE. Lastly, my parents are using a similar N95 system on Windows 11, and it works pretty nicely for them. All of these systems support 32GB of single channel RAM, but they're plenty fast for simple jobs or simple desktop systems which you won't try to conquer the world.
If you have no power/heat/noise/money upper limit, you can get them in more packed configurations, but that's not what I need, actually.
Their firmware is crap quality, and their bugs are just absolutely astoundingly bad.
At one job we literally had to fix their firmware for them after several months of back-and-forth, engineers spotted the absurdly obvious bug in minutes of seeing their code.