Many switch vendors will claim their solutions support programmability, yet almost none of them mean the same thing by it. This makes side-by-side evaluation close to impossible unless you decide in advance what you are measuring.
This ethernet switch buying guide gives you ten lines of questioning to take to your potential vendor to help you determine whether a programmable switch will actually serve an AI workload. By asking these, you'll be able to separate real programmability from a mere configuration API. The questions cover things like where the programmability sits, whether the instruction set is documented, what happens at line rate, how the parser handles unfamiliar protocols, how state is held, what the accelerators cover, how telemetry is gathered, whether load balancing can be changed in software, what the toolchain requires, and whether your work survives the next silicon generation.
For each of the questions below, we've included what the question is about, why it matters for AI traffic, what a good answer sounds like, and how to test a vendor's claim.
What it's about: Whether you can change how packets are processed in the data path itself or only configure a fixed pipeline through an API.
Why it matters: AI workloads keep introducing behavior nobody anticipated at design time, and a configuration API can only expose what the designers already built.
A good answer from the vendor: “There's a documented instruction set with direct access to the engines and a worked example of a non-standard protocol implemented without vendor involvement.”
How to test the vendor's claim: Ask what happens if you need a header format the vendor has never seen. If the answer is a feature request, that is configurability, not programmability.
What it's about: Whether the interface your code targets is a public document or a private contract.
Why it matters: This is what determines whether your engineering investment is portable or stranded. It also determines whether anyone outside the vendor can build tooling for it.
A good answer from the vendor: “The specification is openly available for you to read before you buy.”
How to test the vendor's claim: Ask for the ISA document, not a datasheet or SDK reference, but the instruction set with encodings and semantics. Then ask whether it is available without an NDA and under what license.
What it's about: Whether programmability costs throughput and at what packet size performance starts to fall.
Why it matters: Line rate at large frames is easy. AI east-west traffic carries substantial small-packet volume, which is where fixed pipelines start recirculating.
A good answer from the vendor: “The line rate is sustained at small packet sizes with a real program running and a stated instruction budget per packet.”
How to test the vendor's claim: Ask for line-rate figures at minimum packet size with your own program loaded, not a default profile, and whether recirculation is used and what it costs.
Demonstrated in: the IPv4 forwarding tutorials, which show a full program and its instruction cost.
What it's about: How far into a packet the parser can see, how many headers it can traverse, and whether you can define new ones.
Why it matters: Encapsulation keeps stacking up. If the parser runs out of depth, everything beneath it is invisible to your logic.
A good answer from the vendor: “The parser is programmable with its own instruction set, an explicit protocol-graph mechanism, and an accelerator for skipping headers you do not care about.”
How to test the vendor's claim: Ask how the parser handles a protocol graph it has not been programmed for, whether skipping uninteresting headers costs cycles, and what the header-length limit is.
Demonstrated in: Simple IPv4 and Non-Trivial IPv4, which show parser programs of increasing depth.
What it's about: Lookup types impact how much per-flow state the silicon can hold and how tables are shared.
Why it matters: AI fabrics carry fewer, larger, longer-lived flows, and congestion logic must track them. Table capacity and lookup flexibility set the ceiling on what you can implement.
A good answer from the vendor: “Multiple lookup types are supported; elastic resource allocation rather than per-stage binding, and a documented way to allocate structures in processing memory.”
How to test the vendor's claim: Ask which lookup types are available, exact, longest-prefix or ternary, and whether table resources are bound to fixed stages or shared across the device.
Demonstrated in: IPv4 Counters, which shows table and counter allocation in practice.
What it's about: Which common operations are done in hardware rather than costing you instructions: checksums, hashing, metering, counters, atomics.
Why it matters: Accelerators are what let a programmable device stay at line rate, and the set on offer determines what you can afford per packet.
A good answer from the vendor: “The published accelerator set covers checksum, hash, meters, counters, and atomics, with an explicit mechanism for launching them asynchronously and checking completion.”
How to test the vendor's claim: Ask for the list and whether each runs asynchronously alongside instruction execution or blocks the thread.
Demonstrated in: IPv4 Counters and the Network Calculator tutorial.
What it's about: What the device can measure about its own behavior, and how much of that you can define.
Why it matters: Congestion control depends on measurement. If the device cannot surface the signals your algorithm needs at the moment it needs them, you cannot implement the algorithm. In practice, in-band network telemetry via programmable data planes is made possible when the switch can attach state to the packet itself as it moves.
A good answer from the vendor: “There are programmable counters and queue-state signals that a program can query and branch on in the same pass. Congestion measurement can be defined rather than simply consumed.”
How to test the vendor's claim: Ask whether counters and measurement points are fixed or programmable, what queue-state signals the data path can query, and whether the result can be acted on within the same packet's processing rather than reported afterward.
Demonstrated in: IPv4 Counters.
What it's about: Whether hashing and path selection are fixed functions or something you can define.
Why it matters: ECMP hashing behaves poorly on few, large, long-lived flows, and is a common cause of fabric imbalance in AI clusters.
A good answer from the vendor: “This is possible through programmable hashing and a dynamic load-balancing primitive, with the selection logic exposed to your program.”
How to test the vendor's claim: Check that the hash function and the load-balancing decision can be modified in software and whether the device supports dynamic rather than static distribution.
What it's about: What you write in, what compiles it, and who controls that compiler.
Why it matters: A toolchain controlled entirely by the vendor is a dependency, however open the silicon is. Language choice also decides who on your team can contribute.
A good answer from the vendor: “Both routes are possible: P4 for portability, and assembly for what P4 cannot express. There is enough published information that a third party could build a compiler against the ISA.”
How to test the vendor's claim: Ask whether you can write at assembly level as well as through a higher-level abstraction and whether a third party could build a compiler for the ISA.
What it's about: Whether the programs and skills you build now transfer to the vendor's next generation.
Why it matters: It is the difference between an investment and an expense, and the criterion most likely to be answered with a roadmap slide rather than a commitment.
A good answer from the vendor: “There's a consistent programming model across generations, with the previous transition described concretely.”
How to test the vendor's claim: Ask whether the instruction set is stable across generations and what happened to customer code at the last change. Ask for the migration story, not the intention.
Selecting a programmable switch is not just about meeting today's requirements; it is about protecting the fabric you will depend on tomorrow. Test your potential vendors against these ten criteria before you buy.
In doing so, you'll reduce the risk of discovering too late that a switch cannot support the protocols, telemetry, toolchains, or performance profile your AI workloads require. Reducing that risk means fewer stranded engineering investments, fewer expensive replacement cycles, and less time spent redesigning around unsuitable hardware.
The right programmable ASIC should give you room to adapt, not force you back to the procurement table when requirements change.
Several of these criteria are answerable from the XISA specification itself. The hub sets out what the open instruction set is and what it gives you, and five worked tutorials show the programs behind the answers.