Send lwip-users mailing list submissions to
address@hidden
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.nongnu.org/mailman/listinfo/lwip-users
or, via email, send a message with subject or body 'help' to
address@hidden
You can reach the person managing the list at
address@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of lwip-users digest..."
Today's Topics:
1. Re: Why does sys_sem_wait_timeout exist? (Atte Kojo)
2. Re: Why does sys_sem_wait_timeout exist? (Kieran Mansley)
3. Re: Why does sys_sem_wait_timeout exist? (Atte Kojo)
4. Re: Why does sys_sem_wait_timeout exist? (Kieran Mansley)
5. Re: [lwip-devel] I only can create 16 concurrent connections,
What should I do? (geckook Xu)
----------------------------------------------------------------------
Message: 1
Date: Wed, 28 Feb 2007 08:26:19 +0200
From: Atte Kojo <address@hidden>
Subject: Re: [lwip-users] Why does sys_sem_wait_timeout exist?
To: Mailing list for lwIP users <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Jonathan Larmour wrote:
> Packet-oriented netbufs can be used more efficiently than streams, and
> you can't do things like netbuf_ref() etc. with streams.
I'm afraid that I don't quite understand this. Could you elaborate a bit
more?
As far as I understand, when running in flat memory "zero-copy" is more
of an illusion than anything else. Right now writes/sends on UDP sockets
with socket API are already blocking and don't copy any data between
pbufs (uses netbuf_ref i.e. PBUF_REF). TCP writes could very easily be
made "zero-copy" also with a non-standard option for send (like
MSG_DONTCOPY, which would then use netbuf_ref/PBUF_REF under the covers).
In any case not copying data for performance reasons is kind of a moot
point as the data must be gone through at least once when calculating
checksums. Doing a copy-on-checksum takes almost negligible performance
hit (depending on memory allocator implementation) so only real case for
not copying data at all is for very memory-constrained systems where the
user wants to avoid copying data from external ROM to RAM. And, as I
said earlier, this can be handled very easily.
PS. The main reason I'm so strongly advocating this is that I don't like
having a nonstandard API where a standard one would do. Using a socket
API that behaves just like its real counterpart is a lot easier for new
users (and us old ones also). Plus the netconn-API lacks select() which
makes single-thread servers a gazillion times easier to implement.
------------------------------
Message: 2
Date: Wed, 28 Feb 2007 09:19:47 +0000
From: Kieran Mansley <address@hidden>
Subject: Re: [lwip-users] Why does sys_sem_wait_timeout exist?
To: Mailing list for lwIP users <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain
On Wed, 2007-02-28 at 08:26 +0200, Atte Kojo wrote:
> As far as I understand, when running in flat memory "zero-copy" is more
> of an illusion than anything else. Right now writes/sends on UDP sockets
> with socket API are already blocking and don't copy any data between
> pbufs (uses netbuf_ref i.e. PBUF_REF). TCP writes could very easily be
> made "zero-copy" also with a non-standard option for send (like
> MSG_DONTCOPY, which would then use netbuf_ref/PBUF_REF under the covers).
This is perhaps a bit of a tangent to your point but implementing zero-
copy writes for TCP through the sockets API is very difficult unless the
application can guarantee that the data are static and it will never
modify the buffers it passes in. The sockets API can't make this sort
of guarantee (and so it would have to be a modified API as you suggest)
and the number of applications that *can* make that sort of guarantee
without using vast quantities of memory is very small. As such I don't
think this specific change would be the best use of our time.
Particularly, as you point out, that for a stack such as lwIP doing the
copy during the checksum is not a big deal, and we're not looking for
stella performance as our main goal.
> PS. The main reason I'm so strongly advocating this is that I don't like
> having a nonstandard API where a standard one would do. Using a socket
> API that behaves just like its real counterpart is a lot easier for new
> users (and us old ones also). Plus the netconn-API lacks select() which
> makes single-thread servers a gazillion times easier to implement.
I agree with you that the sockets API as it standards is incomplete and
non-standard, but in many cases has proved to be "good enough" for many
people. It's pretty stable, but I'm pretty sure it's not bug-free. It
would be nice to be able to throw it away and start again with something
built directly on the raw API (I did this for my own project when first
working with lwIP, but it was so specialised as to be of no use to
anyone else) as we could undoubtedly do better, but we'd lose some of
the current stability and we'd need more active developers than we
currently have.
I see lwIP as pretty much stable and mature, and so I'm fairly
conservative about major code changes or rewrites. The sort of thing
you're proposing would be great for a version 2, but I don't anticipate
there being a version 2 any time soon.
Kieran
------------------------------
Message: 3
Date: Wed, 28 Feb 2007 11:59:04 +0200
From: Atte Kojo <address@hidden>
Subject: Re: [lwip-users] Why does sys_sem_wait_timeout exist?
To: Mailing list for lwIP users <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Kieran Mansley wrote:
> On Wed, 2007-02-28 at 08:26 +0200, Atte Kojo wrote:
>
>> As far as I understand, when running in flat memory "zero-copy" is more
>> of an illusion than anything else. Right now writes/sends on UDP sockets
>> with socket API are already blocking and don't copy any data between
>> pbufs (uses netbuf_ref i.e. PBUF_REF). TCP writes could very easily be
>> made "zero-copy" also with a non-standard option for send (like
>> MSG_DONTCOPY, which would then use netbuf_ref/PBUF_REF under the covers).
>>
>
> This is perhaps a bit of a tangent to your point but implementing zero-
> copy writes for TCP through the sockets API is very difficult unless the
> application can guarantee that the data are static and it will never
> modify the buffers it passes in. The sockets API can't make this sort
> of guarantee (and so it would have to be a modified API as you suggest)
> and the number of applications that *can* make that sort of guarantee
> without using vast quantities of memory is very small. As such I don't
> think this specific change would be the best use of our time.
> Particularly, as you point out, that for a stack such as lwIP doing the
> copy during the checksum is not a big deal, and we're not looking for
> stella performance as our main goal.
>
Yes, I seem to be drifting more and more off-topic in this thread ;-). I
didn't mean to say that using zero-copy and TCP would be a very good
idea. I was just pointing out that everything that can be done using
netbufs and netconn API can easily be done using socket API, with minor
nonstandard changes (i.e. some new flags) to the API.
>> PS. The main reason I'm so strongly advocating this is that I don't like
>> having a nonstandard API where a standard one would do. Using a socket
>> API that behaves just like its real counterpart is a lot easier for new
>> users (and us old ones also). Plus the netconn-API lacks select() which
>> makes single-thread servers a gazillion times easier to implement.
>>
>
> I agree with you that the sockets API as it standards is incomplete and
> non-standard, but in many cases has proved to be "good enough" for many
> people. It's pretty stable, but I'm pretty sure it's not bug-free. It
> would be nice to be able to throw it away and start again with something
> built directly on the raw API (I did this for my own project when first
> working with lwIP, but it was so specialised as to be of no use to
> anyone else) as we could undoubtedly do better, but we'd lose some of
> the current stability and we'd need more active developers than we
> currently have.
>
Sorry, I didn't probably express myself as clearly as I wanted. I didn't
mean to berate the socket API in any. We're using it in a production
system and it works very well. My main point was that I don't really see
the reason why netconn API and sockets API should continue to be
developed in parallel since both implement essentially the same
functionality. My opinion is that the two could be merged so that
sockets API would replace the netconn API. And raw API would continue to
be developed as before.
> I see lwIP as pretty much stable and mature, and so I'm fairly
> conservative about major code changes or rewrites. The sort of thing
> you're proposing would be great for a version 2, but I don't anticipate
> there being a version 2 any time soon.
>
Our version of lwIP has been completed for quite some time now and is in
a maintenance/bugfix phase for the current product line where it is used
so I wouldn't want any major changes either :-). And unfortunately due
to our nonstandard hardware, our version differs quite a lot from the
vanilla version.
But, (a BIG) if we're starting development of a new product utilizing
lwIP and a decent microcontroller, I'd be more than happy to help in
developing a new version of lwIP. I think that overall it is a very nice
system, but could use a bit of cleanup here and there.
- Atte
------------------------------
Message: 4
Date: Wed, 28 Feb 2007 10:09:41 +0000
From: Kieran Mansley <address@hidden>
Subject: Re: [lwip-users] Why does sys_sem_wait_timeout exist?
To: Mailing list for lwIP users <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain
On Wed, 2007-02-28 at 11:59 +0200, Atte Kojo wrote:
> I think that overall it is a very nice
> system, but could use a bit of cleanup here and there.
That should be our project motto. :)
Kieran
------------------------------
Message: 5
Date: Wed, 28 Feb 2007 23:23:45 +0800
From: "geckook Xu" <address@hidden>
Subject: [lwip-users] Re: [lwip-devel] I only can create 16 concurrent
connections, What should I do?
To: address@hidden
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
I use sockets.c api.
When I create the 17th concurrent connection,The server program block
at function lwip_read();
Yes,I enable the debug and print out the states of memory.
But no err found.
> > I increase the pcb num,but it does not work.
>
> [NB. I've replied to lwip-users rather than lwip-devel - it is more
> appropriate for this to be discussed there]
>
> Can you find where it is blocking in lwIP? This might give you a clue
> about which resource there is insufficient of to satisfy the 17th
> connection.
>
> I'm surprised that there are no errors output in this case.
>Also, which lwIP API are you using?
>Kieran
-------------- next part --------------
/*
* Copyright (c) 2001, 2002 Swedish Institute of Computer Science.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
modification,
* are permitted provided that the following conditions are met:
*
* 1. Redistributions of source code must retain the above copyright notice,
* this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.
* 3. The name of the author may not be used to endorse or promote products
* derived from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
EVENT
* SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT
* OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING
* IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY
* OF SUCH DAMAGE.
*
* This file is part of the lwIP TCP/IP stack.
*
* Author: Adam Dunkels <address@hidden>
*
*/
#ifndef __LWIPOPTS_H__
#define __LWIPOPTS_H__
#if 1
#define LWIP_DEBUG
#define DBG_MIN_LEVEL 0
#define DBG_TYPES_ON (DBG_ON | DBG_TRACE | DBG_STATE | DBG_FRESH | DBG_HALT)
#if 0
#define TCP_DEBUG DBG_OFF
#define TCP_QLEN_DEBUG DBG_OFF
#define TCP_OUTPUT_DEBUG DBG_ON
#define TCP_RTO_DEBUG DBG_ON
#define TCP_FR_DEBUG DBG_ON
#define TCP_CWND_DEBUG DBG_ON
#define TCP_WND_DEBUG DBG_ON
#define TCP_RST_DEBUG DBG_ON
#endif
#if 1
#define LINK_STATS 1
#define IP_STATS 1
#define IPFRAG_STATS 1
#define ICMP_STATS 1
#define UDP_STATS 1
#define TCP_STATS 1
#define MEM_STATS 1
#define MEMP_STATS 1
#define PBUF_STATS 1
#define SYS_STATS 1
#define RAW_STATS 1
#define LWIP_STATS_DISPLAY 1
#endif
#define MEM_DEBUG DBG_ON
#define MEMP_DEBUG DBG_ON
#if 0
#define TCP_INPUT_DEBUG DBG_ON
#define RAW_DEBUG DBG_OFF
#define PBUF_DEBUG DBG_OFF
#endif
#endif
//efine SO_REUSE 1
#define NO_SYS 0
#define LWIP_CALLBACK_API 1
#define LWIP_DHCP 0
#define SYS_LIGHTWEIGHT_PROT 1
/* #define TCP_TMR_INTERVAL 250 */
#define TCP_TMR_INTERVAL 250
/* ---------- Memory options ---------- */
/* MEM_ALIGNMENT: should be set to the alignment of the CPU for which
lwIP is compiled. 4 byte alignment -> define MEM_ALIGNMENT to 4, 2
byte alignment -> define MEM_ALIGNMENT to 2. */
/* tried 4 byte alignment, but that seems to cause problems with pbuf
* routines */
#define MEM_ALIGNMENT 4
/* MEM_SIZE: the size of the heap memory. If the application will send
a lot of data that needs to be copied, this should be set high. */
#define MEM_SIZE 1024*110
/* The following four are used only with the sequential API and can be
set to 0 if the application only will use the raw API. */
/* MEMP_NUM_NETBUF: the number of struct netbufs. */
#define MEMP_NUM_NETBUF 2*10
/* MEMP_NUM_NETCONN: the number of struct netconns. */
#define MEMP_NUM_NETCONN 4+14//??????15??????????
#define MEMP_NUM_TCP_PCB 5*10
/* MEMP_NUM_APIMSG: the number of struct api_msg, used for
communication between the TCP/IP stack and the sequential
programs. */
#define MEMP_NUM_API_MSG 16
/* MEMP_NUM_TCPIPMSG: the number of struct tcpip_msg, which is used
for sequential API communication and incoming packets. Used in
src/api/tcpip.c. */
#define MEMP_NUM_TCPIP_MSG 16*10
#define MEMP_NUM_SYS_TIMEOUT 3+2
#define PBUF_POOL_SIZE 16*32
#define PBUF_POOL_BUFSIZE 128
#define PBUF_LINK_HLEN 14
#define TCP_MSS 1460
/* TCP_SND_BUF should be less than or equal to MEMP_NUM_TCP_SEG *
* TCP_MSS otherwise the system will not be able to allocate enough
* tcp_segs to transmit all the data and will return ERR_MEM when
* attempting to transmit large amounts of data. You want to guarantee
* that there are more tcp_segs than there is memory. Each segment
* is equal to TCP_MSS.
*/
#define MEMP_NUM_TCP_SEG 255
#define TCP_WND 2048
#define TCP_SND_BUF (MEMP_NUM_TCP_SEG-1) * TCP_MSS
#define LWIP_MAX_QS 20*10 /* Max. LwIP queues */
#endif /* __LWIPOPTS_H__ */
------------------------------
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users
End of lwip-users Digest, Vol 42, Issue 36
******************************************