Hello How do i increase the receive buffer size.... till now i have done following... 1. increase the receive Depth of TSE Mac... 2. Increase the MAXBIGPKTS from 30 to 512 in "ipport.h" 3. Increase the NUMBIGBUFS in "ipport.h" from 30 to 512 4. putting .heap and .stack in different memory region but till now there is no success. i have a image server who sends 512 UDP packet of size 512....on another end nios based receiver is running his job is to collect all these UDP packet in either internal or external memory...and send serieally to other cyclone device for further processing... currently i am able to receive 4 UDP packets of size 512...not more then that.. regards kaushal

You can try to enable -O3 optimization, which would increase the stack speed, but I doubt You'll be able to achieve Your task using the stack. I would offer to do the UDP reception in hardware. I've successed sending and receiving UDP data only in hardware without any problems.

You can also check if it is possible for your server to wait a bit between each packet, giving time to the Nios system to process them. Or use a TCP connection.

If you have systematic packet loss at high packet rates I'm not sure that using TCP will work as well as you want it to. Yes, it will do retransmittions for lost packets and things like 'slow start', but the overall outcome won't necessarily be what you want. If the sending side doesn't spread the packates out (over time), they will be transmitted at LAN line rate, a 100MHz cpu is unlikely to be able to do 'normal' IP processing for line rate at for a 100MHz ethernet, and Ge speeds will be completely out. It is also very likely that the sending system discards UDP transmit requests when the application exceeds the network bandwidth (rather than blocking the send() call). For maximum throughput you may need to write your own ethernet code that does the minimal required. You might get away with a much faster version of the IP checksum routine - the list achives might be illuminative... Also consider using UDP with a simple ack strategy.

One useful feature of TCP when the receiving CPU is a bit slow is the window size adjustment. It should make the source automatically reduce the transmit rate to give the destination enough time to process the data, without any packet loss. IIRC a checksum on the UDP data contents is optional (at least on IPv4), so if the source doesn't provide UDP data checksum, optimizing the IP checksum routine won't speed things up a lot.

I've seen serious problems due to unwanted interactions between TCP 'slow start', 'delayed acks' and Nagle (disabled) on zero-delay local networks with connections carrying uni-directional non-bulk traffic (ie relaying messages received on another network). To ensure data is actually sent we had to send data in the reverse dircection at least every 4 ethernal packets.

no free buffers for rx | Altera Community

52 Replies

Altera_Forum
Honored Contributor
14 years ago
Hello There,

Please see the Print-Screen of TSE_MAC Option in SOPC builder.

1. I have enable -O3 optimization too but i won't get desire result.
2. i have disabled the unwanted services from ipport.h also

in ipport.h there is statement like
# define BB_ALLOC(size) npalloc(size) /*Big packet buffer alloc*/

is this define statement the "size" is the same thing which i given to MAXBIGPKTS 512, or something else. by seeing this statemnet it look like it is assigning the memory region for the received/transmit packet.

With regards
kaushal
multiple-attachments.zip132 KB
Altera_Forum
Honored Contributor
14 years ago
Yes this is the function that is used to allocate the packet buffers for the interniche stack. You can override it with your own functions if you want to use a different memory for that, such as a high speed on-chip RAM block.
Altera_Forum
Honored Contributor
14 years ago
i am able to receive 460 UDP packets of size 512 out of 512 UDP packet, i have add on-chip memory using sopc builder and then connect it to cpu and tse_mac (please see the attached configuration) and made small changes related to packet memory in ipport.h.
if i add more packet to transmit from server side it start saying again "no free buffer for rx"

but i am still running out of 512-460 = 52 UDP packet to get it done .
i just wanted to know what is the data flow in this case after adding packet memory, is it something like

tse_mac--->packet memory----->TCP/IP_inich----->CPU------>Application

or something else so that i can add sufficient memory on desire place

with regards
kaushal
multiple-attachments.zip286 KB
Altera_Forum
Honored Contributor
14 years ago
I'm not sure I understand how you made your connections to the packet memory. If you are attempting to do as they describe in application note 440 (http://www.altera.com/literature/an/an440.pdf), then the packet memory needs to be connected to the SGDMA's read and write masters (and only them, not the descriptor masters) and to the a CPU data master.
What I would do to get the best performance in to connect the m_read and m_write masters to the packet memory's s1 interface (nothing else from m_read/m_write, and nothing else to s1) and add a tightly coupled data master to the CPU, individually connected to the packet memory's s2 interface.
And of course once you do that, modify the ipport.h file so that the memory allocation functions use the packet memory.
Altera_Forum
Honored Contributor
14 years ago
Hello daixiwen,

I have connected my packet memory according to your previous post

1. S1 of packet memory is connected to m_read & m_write of SGDMA
2. S2 is Connected to the data master of CPU

by doing so data master bus clash with flash (please see the attached print screen of SOPC) if i remove flash connection , there is no reset vector for CPU

as you mentioned in your previous post, please suggest how do i direct the memory allocation function to use packet memory..or what changes do i made in ipport.h..so that the memory allocation functions use the packet memory.?

With Regards

kaushal
Altera_Forum
Honored Contributor
14 years ago
Did you use the 'reassign base address' menu item? It should move the addresses around to avoid clash between peripherals. Just ensure that both s1 and s2 stay at the same address (if they change, you can put them back to a fixed address and click on the lock next to it, to prevent the 'reassign base address' option to change them).
As for the ipport.h modifications, I don't remember the exact procedure, as it was made a long time ago, but it should be explained in the application note. I think there is just a define to add or to uncomment somewhere to tell the driver to use a specific address instead of allocating the packet memory through malloc().
Altera_Forum
Honored Contributor
14 years ago
It is also worth checking that the sending side (or a network switch) isn't discarding some of the packets.
The 'traditional' behaviour of UDP sockets is to discard rather than block the application when the app exceeds the number of messages the sending OS is willing to queue.
Altera_Forum
Honored Contributor
14 years ago
hello Daixiwen,

I have add the tightly coupled data master to the CPU, individually connected to the packet memory's s2 interface.

and connect the m_read and m_write masters to the packet memory's s1 interface,

after that i have assign the base address through menu-->assign base address
i have got the two error saying "descripter_memory.s1:appear at more than one address" and "ddr2_bot.s1: apper at more than one address", though i have reassign base address but nothing happen and these two error remain there.
please see attached print screen of my sopc builder , am i doing wrong connection ..?
multiple-attachments.zip236 KB
Altera_Forum
Honored Contributor
14 years ago
hello dsl,

when i increase the TSE_MAC, FIFO DEPTH i have got more number of UDP packet, (though i have reach maximum tse_mac fifo depth) so it seems that network switch won't discard any UDP packet.
Altera_Forum
Honored Contributor
14 years ago
If you have some pipeline bridges, try to set their base address to 0 and lock it. It should get rid of the message.

Forum Discussion

no free buffers for rx

52 Replies

Recent Discussions

Can't generate F-Tile Ethernet Hard IP Design Example

MAX10 TSE reference design

Accessing registers in the PCIE IP beyond MCDMA using system console

Constraints not being picked for DCFIFO

Cyclone IV GX project failed migration from 20.1 to 23.1std