[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [lwip-users] tcp_write with zero-copy
From: |
Goldschmidt Simon |
Subject: |
RE: [lwip-users] tcp_write with zero-copy |
Date: |
Fri, 15 Feb 2008 01:42:20 +0100 |
Hi,
I think there is no problem that would prevent you from implementing
this. In fact, I already thought that was a nice feature, too. But when
talking about low mem systems you have to keep in mind something: there
is a good reason lwIP is using different pools for rx and tx: in your
application, the rx buf used for tx would stay allocated until the TCP
packet is acked. In the current case, it is directly freed after the
application has processed the packet. So while you might save _some_
memory, you still have to design your current rx pool much bigger than
today.
On the other hand, if implementing this, you should try to reuse as much
of the existing code (tcp_enqueue() mainly) as you can in order to keep
the overall code size small, and I don't know if the two versions fit
together easily...
Anyway, I think it's a step to making the tcp raw api more usable!
Simon
________________________________
Von:
address@hidden
[mailto:address@hidden
Im Auftrag von Timmy Brolin
Gesendet: Freitag, 15. Februar 2008 00:16
An: Mailing list for lwIP users
Betreff: Re: [lwip-users] tcp_write with zero-copy
Ok, I am bringing up an really old discussion now, but has
anything happened since back then?
A tcp_write capable of zero-copy (by using pbuf chains for
example) would be a very useful feature.
Where I work we mainly work with request-response protocols such
as modbus and CIP "Ethernet/IP" (where IP stands for Industrial
Protocol). Whenever we get a TCP request packet we are to immediately
produce a response, and the response TCP packet is usually almost
identical to the request packet.
With a tcp_write function capable of accepting pbuf chains, all
I would have to do when I get a request is change a few bytes in the
packet to turn it into a response packet, perhaps append a few bytes at
then end and then feed it back into lwip using tcp_write.
This way I would not have to call any alloc function (which
takes both time and memory, and always runs the risk of failing on a low
mem embedded system), and I would save one or in some cases two memcopy.
I am aware that the tcp_write function has some limited
zero-copy functionality if the data to send is constant. While this is a
very nice feature, the only application I can think of where it is
useful is simple web servers with html and images stored in flash. And
even then you cannot use it if your webserver supports writing to the
flash memory.
I think a pbuf capable tcp_write could a very useful for
applications such as webservers with dynamic content as well. The
webserver can build the dynamic html in a pbuf chain and then send the
chain to tcp_write.
Today lwip effectively use two separate memory pools for rx and
tx. Using pbufs for both rx and tx would probably be more memory
efficient in many cases.
So, do you think it can be done? Has anyone tried?
Regards,
Timmy Brolin
Sathya Thammanur wrote:
Sorry Christian for the email. Has anyone tried true
zero-copy for the RAW API mode? Are there changes needed in lwIP to get
this working?
Thanks,
Sathya
On 11/1/05, Christiaan Simons
<address@hidden> wrote:
Sathya Thammanur <address@hidden> wrote on
31-10-2005 18:40:32:
> Does this mean that true zero-copy is not
supported by lwIP? I have
> seen issues with zero-copy and I was wondering
if this is the case.
This isn't advertised anywhere as far as I know.
I cannot tell for sure,
but I believe it was not one of Adam's design
goals. Some users
may have tried to implement zero-copy.
Please post these questions to the lwip-users
list.
Christiaan Simons
Hardware / Software Engineer
Axon Digital Design
+31 (0)13 511 66 66
+31 (0)13 511 41 51
http://www.axon.tv
>
>
This email and any files transmitted with it are
confidential and intended
solely for the use of the individual or entity
to whom they are addressed.
If you have received this email in error please
notify the system manager.
This message contains confidential information
and is intended only for the
individual named. If you are not the named
addressee you should not
disseminate, distribute or copy this e-mail.
________________________________
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users