[lwip-devel] [task #6994] Redesign Socket Layer with LWIP_TCPIP_CORE_LOCKING

[Frédéric Bernon]

Follow-up Comment #7, task #6994 (project lwip):

>This way, select is slower, but normal operations are faster. I think by
now, I favour the windows way, because select is 'rarely'
used and the rest of the operations are faster. We have to have a look on
sizeof(int) versus sizeof(void*), though!

I'm agree, the windows way is good for me. About sizeof problem, since these
two types are based on processor word size, I think there is no problem.

>Then, of course, your idea to replace socket_malloc by memp_malloc is a good
one! BTW: sys_sem_wait(socksem) can be replaced by SYS_ARCH_PROTECT as long as
you don't call any OS-functions in between that could lead to scheduling.

I could replace it by call to SYS_ARCH_DECL_PROTECT / SYS_ARCH_PROTECT /
SYS_ARCH_UNPROTECT since if socksem only used to protect the "sockets" table.
But since I think to use memp, I think keep socket_malloc & socket_free for
internal initializes/allocations/desallocations, but remove the "sockets"
table. To do that, the "struct lwip_sockets" should be in a header file. I
thought to a sockets2.h with only this struct inside. But to add it in memp,
I have to define an option to avoid conflit with current sockets.c file. I
thought to LWIP_SOCKETS2. We could also use it for the next subject...

>I think that's a loss that some can't afford.

The waste could even be 8 bytes for each pbuf is we suppose a 32bit
alignement. The problem is the packet got the information inside, but "parse"
it to get it has a cost. But there is also a waste if you take you example,
since each pbuf header has a cost of 16 bytes (with 32bits pointers). So, if
you need 12 PBUF_POOL to receive, you "wasted" 16*11 = 176 bytes. That why,
since I transfer big video streams, use PBUF_POOL_BUFSIZE set to
LWIP_MEM_ALIGN_SIZE(1518) (+4 bytes for 802.1q VLAN tags). Of course, if you
receive small packets, it's not a so good idea... But I still prefer the idea
to add these fields if LWIP_SOCKETS2=1.

>I don't think it deadlocks. tcp_recved() calls tcp_output() 

I don't think it could cause problem, but it's something to check. The
implementation of SO_RCVBUF option could help to process this problem...

>That's a hack, isn't it? (The sleep(0), I mean.) 

Yes, it's just to progress, and not a thing to keep.

>we get an error from tcp_write, we should block ...
In a general way, I think we should use something like your changes for
remove conn->sem (but I don't find time to study your change).

>We would have to lock other writes until the first has finished to prevent
from having both writes mixed their data.

In multithread cases to process, multiples "send" (and not "sendto") on the
same socket is not something we have to process. If we want to do that, a
semaphore in lwip_socket have to be add.

>about lwip_shutdown...

I don't know, but I'm not sure that - with both sockets implementation - it's
very good to do something in lwip_shutdown (since lwip_close could be call
twice, and in the second one, the "socket handle" is invalid). I think we
should replace it by a define which do nothing, or an empty function.

>set/getsockopt...

Since the first switch is only "parameter checking", and having it help to
reduce the "locked time" of the core. More, if also help to synchronize
sockets2.c with sockets.c. About code space, I'm not sure it change a lot,
so...

>nonblocking I/O...

I don't know, but timeout on accept exists - even on lwIP now ;) Since it
could help to reduce a little bit the code, don't you think that SO_RCVTIMEO
should be mandatory for sockets2.c? One "int" more in lwip_socket, but it's
not a big cost. In current file, I have let "int domain", but I will remove
it...

>Nonblocking close should be handled by SO_LINGER.

Agree with you.

>...I would implement fastsock functions...

Agree, extend socket API is a good solution (perhaps there is some studies on
the same problem on the Net), but I'm more in flavour to not show lwIP
internal structs like pbuf at the application level. About callbacks, It
could be a solution, but since they are in "locked core" mode, it's more
dangerous to let an application developer play with that (of course, this
feature could be "reserved" to advanced users, but in this case, RAW API is
already available). But I think we should postpone that.

>The goal for that would be to remove netconn api in the future to have only
one simple & fast API above the raw API.

Agree with you, but if both API could exist in the same repository, it's not
a problem for me (of course, it give more job to maintain it, but I think
that now, the main job is done for current sequential layer).  I think that
Jonathan will be not very happy if we decide to remove netconn API. So, to my
point of view, the important thing is to have an independant socket API, to be
able to add features without having to "negociate" how to do it with netconn
users...

>OK, this list is somewhat disordered and might not be complete. But I think
the file is a fine start! Thanks for working on that!

And thanks to work with me on that.



    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?6994>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.nongnu.org/