libbladeRF: reject stream configs that exceed the usbfs memory budget

[wormuz]

Every in-flight USB transfer is pinned by the kernel, so a stream needs num_transfers * buffer_size_bytes of usbfs memory simultaneously. The default limit is 16 MiB.

Exceeding it fails far from its cause: bladerf_sync_config() returns success, submit_transfer() then fails asynchronously with LIBUSB_ERROR_NO_MEM, and the caller only sees BLADERF_ERR_MEM from the first bladerf_sync_rx() — with nothing pointing at the transfer count.

Measured on a bladeRF 2.0 micro xA4 (FX3 2.6.0, FPGA 0.16.0), SC16_Q11_META at 61.44 Msps with buffer_size=131072 samples:

num_transfers=31  ->  ok
num_transfers=32  ->  ERR_MEM from the first sync_rx

32 × 512 KiB is exactly the 16 MiB limit. The larger GPIF buffers in FX3 2.6.0 make this much easier to hit than before.

The check runs in async_init_stream() and returns BLADERF_ERR_INVAL with the numbers and the maximum transfer count that fits:

Stream needs 16 MiB of in-flight USB buffers (32 transfers x 524288 bytes),
but usbfs_memory_mb is 16. Use at most 28 transfers, or raise the limit with
'echo <MiB> > /sys/module/usbcore/parameters/usbfs_memory_mb'.

The limit is read from sysfs on Linux and falls back to the kernel default of 16 MiB elsewhere. A second commit documents the constraint on the num_transfers parameter.

[CLAassistant]

All committers have signed the CLA.