lwip-devel
[Top][All Lists]
Advanced

[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:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

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
feature.

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
LWIP_LOOPIF_MULTITHREADING could be defined like ((LWIP_SOCKETS>0) ||
(LWIP_NETCONN>0)).

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:

  <http://savannah.nongnu.org/patch/?5914>

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





reply via email to

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