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

[A. Lester Buck]

In article <4996 at freja.diku.dk>, thorinn at skinfaxe.diku.dk (Lars Henrik Mathiesen) writes:
> 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).
[same answer from Chris Torek.  Thanks for the information.]

I still think this is quite small.  Why does it need to be on the kernel
stack?  Why not use a kernel buffer?  A 1K buffer would have a limit of
128.  This doesn't sound like rocket science...

> >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.

Reasons, please?  Works just fine for me.  The original requirements for
the driver included the ability to bundle packets.  My driver background
is from System V, so I was thinking of adding ioctl's so as not to
mangle the clean semantics of read(2) and write(2).  When readv(2) and
writev(2) were pointed out, they were exactly what was needed.
For the AIX PS/2 driver, it doesn't really make that much difference,
but I am told that the bundled interface is very important for decent
performance on AIX 370, which is part of the project I am working on.

Why not use readv/writev if they are there?


-- 
A. Lester Buck		...!texbell!moray!siswat!buck