[lwip-devel] RE : [task #6935] Problems to be solved with the current socket/netconn API

[Frédéric BERNON]

(I do a public answer, if others have the same questions)

>don't you need to unlock the core sometime inside tcpip_thread()? 
>Maybe I'm missing something...

In fact, the "unlock" is done inside sys_mbox_fetch, in sys.c. If tcpip_thread 
run, it's lock the stack. If it fetch a msg, just before, it unlock the stack, 
and lock it just after. Of course, sys_mbox_fetch is only used by tcpip_thread 
in my case, but I'm not sure if it's a problem for PPP part...

>in lwip_sendto(), if conn->type is not TCP, it might be RAW also, not 
>only UDP!

Yes, you're right, but I didn't want to do a full implementation, but just a 
small sample to illustrate the option. How I already tell you, the idea is more 
to add new files (perhaps sockets2.c and api_msg2.c), than patch the existing 
ones...

>Other than that it looks fine to me. What I'd like to change is somehow 
>removing the duplicate call to get_socket() when calling lwip_send() 
>which then calls lwip_sendto()... 
In my code, I have just replace the get_socket by a cast. I have modify 
lwip_socket & lwip_accept to return directly the "struct lwip_socket *". 
Because "(struct lwip_socket *)(-1)" can't be a valid address (in my target, 
but in most I think), it's faster. More, I have remove the "if (!sock) return 
-1;" because, like we have remove the "if (conn==NULL)" in api_lib.c (replaced 
by LWIP_ASSERT), don't give an invalid address is the job of application 
programmer. So, the duplicate call is not a real one...

>I'm guessing this change is for you to gain better UDP multi-client 
>throughput? ;-)

It's most a good study case for test this option (lock feature, and netconn 
independancy), and study a new socket layer...

>Out of interest, what kind of hardware are you using? Do you have the 
>same problems Jonathan has faced (that pbufs are deleted and got invalid 
>before the hardware could really send them - because the DMA is too 
>slow)? I'm not facing this since currently our processor is much slower 
>than the ethernet hardware, but it _is_ a design problem...

It seems I missed this problem. Which bug or task talk about that? My hardware 
got a DMA engine, but in my link_output, I currently do a copy of datas in MAC 
internal buffers.
  
====================================
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 
Envoyé : vendredi 8 juin 2007 22:12
À : Frédéric BERNON
Objet : Re: [task #6935] Problems to be solved with the current socket/netconn 
API


Some questions about your modifications:
- don't you need to unlock the core sometime inside tcpip_thread()? 
Maybe I'm missing something...
- in lwip_sendto(), if conn->type is not TCP, it might be RAW also, not 
only UDP!

Other than that it looks fine to me. What I'd like to change is somehow 
removing the duplicate call to get_socket() when calling lwip_send() 
which then calls lwip_sendto()...

I'm guessing this change is for you to gain better UDP multi-client 
throughput? ;-)

Out of interest, what kind of hardware are you using? Do you have the 
same problems Jonathan has faced (that pbufs are deleted and got invalid 
before the hardware could really send them - because the DMA is too 
slow)? I'm not facing this since currently our processor is much slower 
than the ethernet hardware, but it _is_ a design problem...

Again, fine work which I think is the right direction for lwIP :-)

Simon

Frédéric Bernon schrieb:
> Follow-up Comment #17, task #6935 (project lwip):
>
> Ok, I have check in. I hope this code can help to reach same 
> performance in sequential API than in raw API...
>
>
>     _______________________________________________________
>
> Reply to this item at:
>
>   <http://savannah.nongnu.org/task/?6935>
>
> _______________________________________________
>   Message posté via/par Savannah
>   http://savannah.nongnu.org/
>
>
>

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