Zynq Runtime Socket Buffer Allocation Memory Reporting Question

Misra, Avinash Avinash.Misra at jhuapl.edu
Wed Jan 30 01:08:01 UTC 2019


I have a question in regards to changing the size of the socket buffers on the Zynq. It would appear that I can't use the method described in Ch 4.3 of the Networking pdf since I don't have the Ethernet driver and attach functions defined in the BSP. I believe this is largely due to the fact that I had to build RTEMS without networking and then separately build and link BSD to my kernel. As such the only way that I have found to change the buffer size is by a series of ifconfig sysctl calls that I have to make use at run time. My call hierarchy is as such:


Then a call to ifconifg to set up the Eth device, IP Address, NetMask, etc.

sysctl -w kern.ipc.maxsockbuf

systcl -w net.inet.udp.recvspace

sysctl -w kern.ipc.nmbclusters

I believe these allow me to effectively override the run time defaults for UDP receive buffers. A call to getsockopt() confirms this for me.

What I have noticed however, is that I don't seem to see the increased buffer allocation reported by either top, wkspace, or malloc info (keeping in mind that my heap and workspace are configured to be unified). Am I looking at the wrong place to find the allocation of the socket buffers or does RTEMS simply not know about the increased buffer size since this was done at run time? Please also let me know if this is also the wrong way to achieve what I'm trying to do (allocate more memory to my socket buffers). One of my big concerns right now with not seeing the updated memory utilization is RTEMS accidentally allocating other run time, statically allocated, variables and arrays into the same memory that the updated socket buffers are trying to occupy.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190130/b7b49421/attachment.html>

More information about the devel mailing list