RE : RE : [lwip-users] managing storage problems.

[Frédéric BERNON]

I'm agree, we should solve that in the stack, and SO_RCVBUF is a good solution 
for me (before/after 1.3.0 ?? To be honest, I'm not sure). I'm also in flavor 
to redesign mailbox model, by adding a "size" parameter to sys_mbox_new (by 
example, the netconn::mbox doesn't really need to be larger than 1, of course, 
a semaphore could be better), and by adding return values to sys_mbox_post (to 
enable to handle the full mbox case). The main "problem" is to share between 
application thread and tcpip_thread a "byte counter". I think it will be better 
to include it directly in the mailbox model (a sys_mbox_getcount, and something 
like a "bytesize" parameter in sys_mbox_post), to avoid execution context 
switch like for tcp (with "do_recv" calls), and an unprotect access to 
netconn::recv_avail for udp and raw (I don't think the current code is very 
thread-safe).

Since it's something which could take time to define, I think that shai could 
test the workaround I propose him in a first time.

 
  
====================================
Frédéric BERNON 
HYMATOM SA 
Chef de projet informatique 
Microsoft Certified Professional 
Tél. : +33 (0)4-67-87-61-10 
Fax. : +33 (0)4-67-70-85-44 
Email : address@hidden 
Web Site : http://www.hymatom.fr 
====================================
P Avant d'imprimer, penser à l'environnement
 


-----Message d'origine-----
De : address@hidden [mailto:address@hidden De la part de address@hidden
Envoyé : mardi 30 octobre 2007 11:49
À : Mailing list for lwIP users
Objet : Re: RE : [lwip-users] managing storage problems.


Frédéric BERNON schrieb:
> This is a lwIP problem: you should never got a full mbox, due to the 
> lwIP design. But, mainly, when a mbox is full, this is the netconn::recvmbox, 
> or the tcpip.c::mbox (other mailboxes are used like "semaphores").
>   
But I think that's a problem we could solve. As I understand it, it's 
not a problem for TCP because the recvmbox of TCP will never hold more 
data than the TCP receive window (it still could be a problem if data is 
coming in many small packets -> many pbufs on the recvmbox, but if data 
is coming in small packets, the application supposedly will have the 
time to process the data).

For UDP, this can be solved much like the TCP send way by having two limits
a) number of bytes in the recvmbox (like tcp_pcb->snd_buf) and
b) number of pbufs in the recvmbox (like tcp_pcb->snd_queuelen)

I think this is a common problem for UDP stacks (other stacks implement 
SO_RCVBUF, for example) and should be implemented in lwIP also.

The tcpip-mbox is a different thing, because it is very special to lwIP. 
I have code to stop filling the tcpip-mbox when it is too full (which 
disables my RX interrupt also). Then I get informed of the tcpip_thread 
when there is enough space again, so I can turn on RX interrupts again. 
This isn't very portable, but maybe just informing the app/driver about 
high-/low-water-mark could be a more general solution (to prevent having 
to modify the core code for this purpose).

Anyone else needing this except me and shai?

> If you know the full mbox is always an UDP one, I think you can 
> directly use netbuf_delete on the pointer you have to post. It's not a clean 
> solution, but should work.
>   
That's really not a clean solution since memp_free() doesn't check 
whether the pointer to be freed is a pool element (memory region is not 
checked), which could lead to bugs that are hard to locate if the tcpip 
mbox really gets full some time.

Simon


_______________________________________________
lwip-users mailing list
address@hidden http://lists.nongnu.org/mailman/listinfo/lwip-users

Frédéric BERNON.vcf
Description: Frédéric BERNON.vcf