While you could make an OpenFlow client that uses this switch chip as the data-plane, it might not be the best as most of the features you would use OpenFlow for would not be able to use the relatively limited hardware fast-path.
OpenFlow is a protocol, switchdev is a driver API for exposing access to essentially the same operation model as OpenFlow targets. You don't replace OpenFlow with switchdev, you might use OpenFlow to integrate a switchdev with an SDN
You want to write code that runs on the switch, whether it's a routing protocol or an intent reconciliation loop or whatever. You don't want to send low-level OpenFlow commands over the network because it ends up being slow and chatty.
A considerable portion of SDN craze involved pretty much this. Even systems that didn't use OpenFlow were incredibly chatty, creating complex chains of NextHop routes from centralized or at least semi-centralized servers to the actual switches.
Even in more sane setups, it's not actually uncommon to have control plane talk over network to actual forwarding plane - IIRC Cisco Nexus operates this way, with actual forwarding engines talking with control plane over Ethernet link.
I like the code to run on the switches directly, but SDNs very often eschewed that for dumber forwarding engines controlled OpenFlow way, even if actual protocols used weren't OpenFlow.
Ironically it could also be said OpenFlow was not generic enough. More and more networking hardware continues to move towards having a fully programmable pipeline but OpenFlow isn't the most flexible way to define a completely arbitrary pipeline.
It mapped very well to HW, but only to dumbest part of the hw.
at least from pov of someone dabbling in SDNs around 2014-2017 including deep guts implementation details of one commercial one...
OpenFlow encoded the approach of dumb ethernet switches, combined with Cisco Express Forwarding - which is a common aspect of many switching ASICs, but not entirety of them, even for Cisco.
It never abstracted that historic aspect, if anything the leaking was the internal model of OpenFlow (editing forwarding table) rather than internals HW (which sometimes was a systolic array of CPUs that exposed "tables" as detail of interaction but nothing actually fundamental).
All was fine so long, like CEF, you dumped everything to CPU/northbound API outside "IP with this address should go there, and TCP flow with those parameters go there", in case of early openflow bejbf essentially "packet with dstMAC shall go to port X".
This does not work well with acceleration engines, or in beefier chips the aforementioned systolic arrays or similar arrangements, outside of hardcoding idea of specific accelerators and their interface tables.
