Sockets and temporary buffers

[Bruno Barberi Gnecco]

I'm writing an application which relies heavily on data
transmitted by sockets. What is the current state of zero-copy in
linux? Some of the packets the application sends have to be
processed into other data, which is terribly wasteful (receive the
packet, read() it to a temp buffer which has to be malloc()ed,
process it to another buffer or structure which is malloc()ed as
well).
It's also hard to keep track of the allocated memory. The
packets come with a header, so even when the data does not have
to be processed, free()ing it is a pain. I either have to copy it
to another buffer or use my own free().
Any suggestions on how to handle these issues?

--
Bruno Barberi Gnecco <brunobg_at_users.sourceforge.net>
A tautology is a thing which is tautological.

[Jan Panteltje]

On a sunny day (Thu, 29 Sep 2005 15:23:06 -0300) it happened Bruno Barberi
Gnecco <brunobgDELETETHIS@users.sourceforge.net> wrote in
<dhhb4g01432@news4.newsguy.com>:

>I'm writing an application which relies heavily on data
>transmitted by sockets. What is the current state of zero-copy in
>linux? Some of the packets the application sends have to be
>processed into other data, which is terribly wasteful (receive the
>packet, read() it to a temp buffer which has to be malloc()ed,
>process it to another buffer or structure which is malloc()ed as
>well).
>It's also hard to keep track of the allocated memory. The
>packets come with a header, so even when the data does not have
>to be processed, free()ing it is a pain. I either have to copy it
>to another buffer or use my own free().
>Any suggestions on how to handle these issues?
If you have a way to know maximum packet size, allocate the buffer
before you start the reading loop?
Or you could use a big enough array on the stack....

[Bruno Barberi Gnecco]

Jan Panteltje wrote:
> On a sunny day (Thu, 29 Sep 2005 15:23:06 -0300) it happened Bruno Barberi
> Gnecco <brunobgDELETETHIS@users.sourceforge.net> wrote in
> <dhhb4g01432@news4.newsguy.com>:
>
>
>>I'm writing an application which relies heavily on data
>>transmitted by sockets. What is the current state of zero-copy in
>>linux? Some of the packets the application sends have to be
>>processed into other data, which is terribly wasteful (receive the
>>packet, read() it to a temp buffer which has to be malloc()ed,
>>process it to another buffer or structure which is malloc()ed as
>>well).
>>It's also hard to keep track of the allocated memory. The
>>packets come with a header, so even when the data does not have
>>to be processed, free()ing it is a pain. I either have to copy it
>>to another buffer or use my own free().
>>Any suggestions on how to handle these issues?
>
> If you have a way to know maximum packet size, allocate the buffer
> before you start the reading loop?
> Or you could use a big enough array on the stack....

But I may get the next packet before the current one has been
free()d... What I'm doing now is to send in the header the total size
of the packet, so I read() a fixed number of bytes and allocate the
precise number of bytes for the buffer. Even so, the rest of the
header has a variable size.
Is there anyway to get hold of the buffers allocated by the
kernel itself, avoiding the call to read()?

--
Bruno Barberi Gnecco <brunobg_at_users.sourceforge.net>
Going the speed of light is bad for your age.

[Jan Panteltje]

On a sunny day (Fri, 30 Sep 2005 10:46:47 -0300) it happened Bruno Barberi
Gnecco <brunobgDELETETHIS@users.sourceforge.net> wrote in
<dhjfbq027eo@news1.newsguy.com>:

>But I may get the next packet before the current one has been
>free()d... What I'm doing now is to send in the header the total size
>of the packet, so I read() a fixed number of bytes and allocate the
>precise number of bytes for the buffer. Even so, the rest of the
>header has a variable size.
>Is there anyway to get hold of the buffers allocated by the
>kernel itself, avoiding the call to read()?


Well, it is hard to say, what I would do in your case is have a real good
look at libc.info (/usr/share/info/libc.info*)
Here I read for example:
'
Some applications may need to read or write data to multiple buffers,
which are separated in memory. Although this can be done easily enough
with multiple calls to ead' and rite', it is inefficent because
there is overhead associated with each kernel call.

Instead, many platforms provide special high-speed primitives to
perform these "scatter-gather" operations in a single kernel call. The
GNU C library will provide an emulation on any system that lacks these
primitives, so they are not a portability threat. They are defined in
ys/uio.h'.

These functions are controlled with arrays of ovec' structures,
which describe the location and size of each buffer.

- Data Type: struct iovec
The ovec' structure describes a buffer. It contains two fields:

oid *iov_base'
Contains the address of a buffer.

ize_t iov_len'
Contains the length of the buffer.


- Function: ssize_t readv (int FILEDES, const struct iovec *VECTOR,
'

etc etc.
It is the reference you MUST have if you program using libc...
this thne continues talking about mmap.
If GNU is only 'emulation' then perhaps there is not much speed advantage,
I have never used readv() myself..
Have a look, there is probably more thatcan be done, i tis a must read :-)
Could not have written half the programs I did without libc.info.
What I have done is unzip all these info files, cat them together, and
then I have it in my home dir and use joe editor search for a subject on it.