[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [patch #5914] Move sockopt processing into tcpip_thread

From: Frédéric Bernon
Subject: [lwip-devel] [patch #5914] Move sockopt processing into tcpip_thread
Date: Fri, 04 May 2007 20:34:57 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv: Gecko/20070309 Firefox/

Follow-up Comment #17, patch #5914 (project lwip):

Ok, Simon, talk about that (even if we could open a separate task to this
subject)  :)

If one day, we have lot of time to redesign lwIP API, to my point of view, I
will never think to add something like the netconn layer, but I will just
prefer to add some "non-BSD" functions to sockets API to add the zero-copy

But I don't think to get time, and current "socket on netconn" architecture
work, and not so bad, and not so slow: communication with tcpip_thread is
stable, and except for some multithreading case, it's good.

Why, most of time, we talk to have an independant socket layer? I think it's
because netconn users don't want to have extra code or a "longer" run time if
they don't need it, and each socket feature add code they don't need. And I
can understand that...

Socket "problems" are mainly "lot" of parameters checking (not useful if you
are sure about your parameters), and impossible to get a zero-copy for
receive (adding a memcpy)... What else?

To come back on this item: I don't think that starting now to add redundant
code for "joingroup" and a different feature to communicate with tcpip_thread
is the good thing to do, and it's not coherent with all others sockets
functions (and, I like lwIP because it is simple and have a nice design).
Your solution, to my point of view, is just a new and redundant
"tcpip_apimsg" (synchrone call to tcpip_thread). Even, note that in current
CVS, tcpip_callback is only used by PPP, and should have to be disable if no
PPP interfaces is used... I would like to propose you a patch based on
tcpip_apimsg, I think it would the same thing, except one or two details, but
more coherent (always, to my point of view, of course). Ok for you ?

If you really prefer your solution, so, add LWIP_NETCONN options, and disable
do_join_leave_group(), because "I don't want to increase my footprint for a
function only used by netconn users !!!" :) It's a "joke", of course, but
it's right. 

That why I think that adding LWIP_SOCKETS & LWIP_NETCONN are really
necessary. It's a good solution to let an "API common part" (for both
layers), and to only add code necessary for the layer used. More, things like

Last, about "who of us would use lwIP if there was another stack which is
faster and dosn't cost much", you're right, but fast is not the only aim with
lwIP: it can be small, and stable. In a previous item, we have talk about
option to define if the user prefer to reduce his footprint, or to increase
the speed of the stack. I also think we should add options for that. And I
would like to get an option for tune the parameters checking: most of time,
these checkings, like "if (conn == NULL) {" or "if (!sock)" are not "useful"
(application level already check them). 

Thank you Simon to spend time to read that :) 


Reply to this item at:


  Message posté via/par Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]