Dropping that length into the old packet power/length calculator (link below) for a preamble length of 64 that would give a packet duration of 111.54 us for the poll and
119.74 for the response.
You’ve got 32 bytes of data, 10 bytes of timestamp data and call it at least another dozen bytes of status information as a minimum so call it 55 bytes of data over SPI. Assume you have the bus at 10MHz that’s 44us of SPI activity. Double that it to allow for chip select setup delays and various other overheads and round up, call it 100 us of processor activity sorting out the response. That means that a POLL_RX_TO_RESP_TX_DLY_UUS in the 250 us region should in theory be possible with those packet sizes.
Total ranging time would then be in the region of 400 - 500 us depending on processing time for the calculations.
Personally I run a delay of 410 us on a packet that is 260 us long, giving me around 150 us for processing and packet turnaround. So it is possible to hit that sort of time given the packet duration you have.
I don’t know what your code is doing so you may need a larger margin, but ultimately if you only need 100 Hz you could make the delay 1ms, that should be easily achievable with those packet sizes and still be plenty fast enough.
One thing to make sure is that your initiator doesn’t have a delay set between its transmit finishing and its receiver being enabled, you want that delay to be 0 at least initially.
Old DW1000 power calculator - Decawave published this way back (with a java wrapper to hide the underlying sheet) and then it silently vanished from their site years ago. It predates the DW3000 but as long as you don’t use STS the packet duration calculations are still valid.