Socket buffer
Leon Pollak
leonp at plris.com
Tue Oct 13 12:46:14 UTC 2009
On Sunday October 11 2009, Joel Sherrill wrote:
> Leon,
>
> This may not help since my head is foggy this morning. But
> The factors that go into the default socket buffering are
> tunable in RTEMS. Look in rtems_bsdnet.h and the documentation.
The point is, that I changed the default value. When I arrive in debugger to
the sbreserve function call, I see in debugger, that sb_max is set to 1.1MB.
> When you do this though, you have to tell the stack
> to reserve enough memory for the mbufs. You probably
> haven't increased the reserved buffers.
As I said above - I did.
The issue is a bit different: the code, as it is written today, DOES NOT ALLOW
to set the value greater! Let's say 2MB is impossible to set.
My question is: why? Nobody has set this to be 2MB? So, there is no need? This
means I need to re-buffer it in the application, wasting CPU for copying?
Not clear at all...
> Leon Pollak wrote:
> > Hello, all.
> >
> > I searched WEB and Wiki - was not able to find an answer...:-(
> > --
> > I see the message "not delivered. Socket buffer full" in
> > rtems_bsdnet_show_udp_stats report.
> >
> > Ok, I now tried to increase the socket buffer (from 1MB to 2MB) by the
> > command setsockopt(so,SOL_SOCKET,SO_RCVBUF,&Size,sizeof(Size)).
> >
> > - failed.
> >
> > Debugging shows that function sbreserve fails in the first check:
> > /*
> > * Allot mbufs to a sockbuf.
> > * Attempt to scale mbmax so that mbcnt doesn't become limiting
> > * if buffering efficiency is near the normal case.
> > */
> > int
> > sbreserve(sb, cc)
> > struct sockbuf *sb;
> > u_long cc;
> > {
> >
> > if (cc > sb_max * MCLBYTES / (MSIZE + MCLBYTES))
> > return (0);
> > ......
> >
> > Now, when I set sb_max to be 1MB, the max socket buffer size may be also
> > not more then 1MB.
> > And I cannot set it higher to 2MB, as the calculation of sb_max *
> > MCLBYTES (which is 2048) exits the 32bit limit.
> >
> > This makes me think that increasing the socket buffer to such extend is
> > incorrect. If so, what can I do to avoid this error?
> >
> > I thought that the cause may be in the lack of CPU time, but
> > rtems_cpu_usage_report shows that about 35% CPU spends in IDLE task...
> >
> > Thanks a lot for any hint.
>
--
Leon
More information about the users
mailing list