usrp-users@lists.ettus.com

Discussion and technical support related to USRP, UHD, RFNoC

View all threads

getting larger packets out of an rfnoc block

KW
Kevin Williams
Thu, Jul 3, 2025 8:18 AM

Hi,

I've managed to take some steps backwards with my rfnoc work.

In a test using the ADDSUB block and looking at packet sizes I see a maximum
of 2000 samples per packet reported by the streamer, and 8058 byte packets
received in wireshark.

In my block I count valid's to assert tlast, and have been using 256 samples
with "sideband at end".

However, it seems I cannot increase that counter to 1024 samples where I get
these errors (even if I set the streamer SPP to 1024):

[ERROR] [STREAMER] The receive transport caught a value exception.

ValueError: Bad CHDR header or invalid packet length.

(Strangely, I still get the 1024-sample packets according to wireshark, so I
guess its not related to the firmware?)

BTW in my noc shell I have an MTU of 10, and have axis_data_to_chdr fifo's
of 2048 samples.

What do I need to do to ensure I can also get large packets out of my block,
as smaller blocks are causing dropped packet headaches?

Many thanks, Kevin

Hi, I've managed to take some steps backwards with my rfnoc work. In a test using the ADDSUB block and looking at packet sizes I see a maximum of 2000 samples per packet reported by the streamer, and 8058 byte packets received in wireshark. In my block I count valid's to assert tlast, and have been using 256 samples with "sideband at end". However, it seems I cannot increase that counter to 1024 samples where I get these errors (even if I set the streamer SPP to 1024): [ERROR] [STREAMER] The receive transport caught a value exception. ValueError: Bad CHDR header or invalid packet length. (Strangely, I still get the 1024-sample packets according to wireshark, so I guess its not related to the firmware?) BTW in my noc shell I have an MTU of 10, and have axis_data_to_chdr fifo's of 2048 samples. What do I need to do to ensure I can also get large packets out of my block, as smaller blocks are causing dropped packet headaches? Many thanks, Kevin
NS
niels.steffen.garibaldi@emerson.com
Thu, Jul 3, 2025 10:01 AM

Hey Kevin,

As far as I am aware, the FPGA has a fixed MTU size of 8192 bytes, which equates to 2^10 words of CHDR_W 64.

The MTU size is distributed to all RFNoC blocks and as far as I know changing this for an individual block will most likely break a lot of stuff and not work correctly.

Since you say that your MTU is 10, I am assuming that your CHDR_W is 64.

I believe this MTU is for the whole packet,so payload plus the header, potential timestamps and metadata words.
If you set your packet to SPP=1024 just the The payload itself is already at the MTU, and with the header, it’s probably over the MTU of 8192 bytes, and might therefor be to large for some of the buffers in RFNoC.

My suspicion is that when you receive the packet on the host, your packet header claims that the payload has 1024*8 bytes, but the actual payload size in bytes is different due to the MTU limitations on the FPGA.
Maybe you can check your wireshark packet and check if the packet length in bytes specified in the header length field is the same as the actual packet length.(There are some lua disectors that you can add to wireshark to disect UHD packets. )

I am not as familiar with the software side, but maybe if you set spp to something slightly below 1024 it might work, although I do not know if there is any requirements for any of the blocks in your chain for SPP to be a power of 2.

Regards,

Niels.\

Hey Kevin,\ \ As far as I am aware, the FPGA has [a fixed MTU size of 8192 bytes](https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/top/x400/x4xx.sv#L334), which equates to 2^10 words of CHDR_W 64. The MTU size is distributed to all RFNoC blocks and as far as I know changing this for an individual block will most likely break a lot of stuff and not work correctly.\ \ Since you say that your MTU is 10, I am assuming that your CHDR_W is 64.\ \ I believe this MTU is for the whole packet,so payload plus the header, potential timestamps and metadata words.\ If you set your packet to SPP=1024 just the The payload itself is already at the MTU, and with the header, it’s probably over the MTU of 8192 bytes, and might therefor be to large for some of the buffers in RFNoC.\ \ My suspicion is that when you receive the packet on the host, your packet header claims that the payload has 1024\*8 bytes, but the actual payload size in bytes is different due to the MTU limitations on the FPGA.\ Maybe you can check your wireshark packet and check if the packet length in bytes specified in the header length field is the same as the actual packet length.([There are some lua disectors that you can add to wireshark to disect UHD packets.](https://github.com/EttusResearch/uhd/tree/master/tools/dissectors/lua) )\ \ I am not as familiar with the software side, but maybe if you set spp to something slightly below 1024 it might work, although I do not know if there is any requirements for any of the blocks in your chain for SPP to be a power of 2.\ \ Regards,\ \ Niels.\