SPIM buffer lengths -- how to calculate and specify

[RVM]

I am trying to use SPIM2 on an NRF52840 based board. The SDK is 17.0.2.

For the life of me I cannot understand how to 'consistently' determine the values to be specified as 'tx_length' and 'rx_length' to be provided to the calls to the transfer function.
My SPI slave device is the MCP2515 which uses a protocol where the first byte of the transfer represents the command and subsequent bytes are either input or output data bytes.

Take for example a command to read 10 bytes. The command itself takes 1 byte, and therefore the total transaction spans 11 bytes (1 + 10).

So far, the only way I have been able to get this transaction to happen correctly is if I set the tx_length and rx_length input parameters BOTH to 11.
Intuitively that makes sense since the channel has to transfer 11 bytes in each direction.

BUT --- WHY BOTHER ASKING THE USERS TO SPECIFY BOTH PARAMETERS.

Why not use a single parameter and use it -- or conversely when (if at all in the case of SPI interactions) would the driver require and leverage different values for TX and RX length?

[mrono]

This is what the datasheet says:

When the maximum number of bytes in the receive buffer is larger than the number of bytes in the transmit buffer, the contents of register ORC on page 424 will be transmitted after the last byte in the transmit buffer has been transmitted.

So it is a feature. No need to specify a tx buffer larger than necessary. I'm not sure how the spim driver handles that. Based on your description not very well.

[RVM]

From my understanding, SPI systems are 'serial' and 'duplex' so I fail to understand why the need to compare the maximum number of transmit bytes to the maximum number of receive bytes -- one should simply pick an order and stream all the bytes sequentially. In my specific case it turns out to be that the SPIM should stream OUT 1 command byte and then stream IN the next 10 receive bytes -- for a total of 11 data transmit clocks. I simply do not see why there is a need to expect any other values for the two 'length' parameters (such as the 11 I had to specify to get the SPIM to talk correctly to the MCP2515)