Discussion:
[nuttx] UDP Write Buffering
spudarnia@yahoo.com [nuttx]
2018-01-23 13:53:35 UTC
Permalink
I have just committed an initial version of (optional) write buffering support for UDP sockets. This should support both better throughput and true non-blocking UDP sendto's.


I have verified the code with the tools and tests that I have available, but it would also be great if anyone out there could test the UDP write buffering in a more abusive environment. I would like to mature and stabilize the feature.


Thanks in advance,
Greg
Sebastien Lorquet sebastien@lorquet.fr [nuttx]
2018-01-23 14:00:24 UTC
Permalink
Hello,

How does this work?

I expected UDP to work with datagrams, not a continuous stream like TCP, so each
write() was a single UDP datagram whatever its size?

Sebastien
Post by ***@yahoo.com [nuttx]
 
I have just committed an initial version of (optional) write buffering support
for UDP sockets.  This should support both better throughput and true
non-blocking UDP sendto's.
I have verified the code with the tools and tests that I have available, but
it would also be great if anyone out there could test the UDP write buffering
in a more abusive environment.  I would like to mature and stabilize the feature.
Thanks in advance,
Greg
Gregory Nutt spudarnia@yahoo.com [nuttx]
2018-01-23 14:10:35 UTC
Permalink
Hi, Sebastion,
Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
How does this work?
I expected UDP to work with datagrams, not a continuous stream like TCP, so each
write() was a single UDP datagram whatever its size?
Yes, of course.  But the data is buffered immediately so that the caller
of sendto() does not have to wait for the send hardware.  I would expect
some performance improvement but with greater memory usage.  The primary
benefit is support for non-blocking sendto() since all waits are eliminated.

This is much simpler that TCP write buffering where there is high
complexity managing ACKs, retransmits, TCP windows, etc.  Basically
packets are just buffered until the hardware is ready to take them.

Greg
Sebastien Lorquet sebastien@lorquet.fr [nuttx]
2018-01-23 14:15:17 UTC
Permalink
Ha, okay, so this is an asynchronous write. Interesting!

Sebastien
Post by Gregory Nutt ***@yahoo.com [nuttx]
 
Hi, Sebastion,
Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
How does this work?
I expected UDP to work with datagrams, not a continuous stream like TCP, so each
write() was a single UDP datagram whatever its size?
Yes, of course.  But the data is buffered immediately so that the caller of
sendto() does not have to wait for the send hardware.  I would expect some
performance improvement but with greater memory usage.  The primary benefit is
support for non-blocking sendto() since all waits are eliminated.
This is much simpler that TCP write buffering where there is high complexity
managing ACKs, retransmits, TCP windows, etc.  Basically packets are just
buffered until the hardware is ready to take them.
Greg
Gregory Nutt spudarnia@yahoo.com [nuttx]
2018-01-23 14:25:12 UTC
Permalink
Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
Ha, okay, so this is an asynchronous write. Interesting!
All writes are asynchronous as some level.  Normally sendto would wait
until the hardware is ready to transmit the next packet before it
returns.  But the transmission from hardware probably also involves
another level of queuing (at least for more advance Ethernet hardware). 
sendto() never blocked until the packet was completely out on the wire
successfully; only until the packet was handed off to the network driver.

So this change just allows sendto to return even sooner without waiting
for hardware.

If you really want asyncrhonous I/O there are always the AIO POSIX
interfaces (aio_write, aio_read, etc.).

Greg

Loading...