The protocol is kept to a functional minimum but 16 bits per command are barely enough to encode all I need/want, and this leads to some complicated compromises.

I don't know yet how many transactions could happen on the fly, as I count on the buffers to compensate for the host's processing latency (I expect the CPU takes "a while" to process all the activity).

So the idea came that packet-specific commands/control/status words could be prefixed with a transaction number. This would make the implementation quite flexible and activity could be controlled by "credits" that represent the available resources (number of free buffers) on the receiver side.

256 transactions of 2Ki bytes represents 512Ki bytes, it's either too much or not enough depending on the application...

But the protocol works only on one data stream/flux at a time so the transaction ID would address a L2 memory, separate from the faster 2Ki buffer used during transmission. And the size of this L2 would be implementation dependent. The transceiver could be double-buffering for its own purposes, and writing (DMA) to the host memory when a datagram is complete...

But using a prefix with even 8 bits lets us buffer quite a lot of data, and the CPU sends ACK when it has processed them. Or something.