why limit of 16 iovec's in readv/writev?

[Lars Henrik Mathiesen]

buck at siswat.UUCP (A. Lester Buck) writes:
>I ran across the limit on 16 iovec's in each readv(2) or writev(2) call.

The limit is there because the iovecs are copied into an array on the
kernel stack; the further processing uses a pointer to this array and
a count (contained in a structure which also has total and residual
byte counts and some flags).

>This limits the maximum transfer per system call to about 24KB.

In my opinion you should not use the readv/writev mechanism to provide
packet delimiters, even for debugging. Unless you are on a machine
where memory is tight, I would suggest that your driver treat the user
buffer as an array of (e.g.) 2K subbuffers, one for each packet. The
last word in each subbuffer could then be a bytecount.

--
Lars Mathiesen, DIKU, U of Copenhagen, Denmark      [uunet!]mcvax!diku!thorinn
Institute of Datalogy -- we're scientists, not engineers.      thorinn at diku.dk