>Not true.  You just need to keep more state in the pcb to track this.

Huh? I supppose we *could* invent a new, PF_KEY specific, way of
encoding small messages with record boundaries, such that we can fill
an mbuf cluster (or chain of densely-packed mbuf clusters) with tiny
messages, while still tracking reconrd boundaries and whatever else
sbappendaddr() keeps now.

Or we could return the data in one monster socket-layer message, and
(as I think you're suggest here) have the pcb-specific code pares
those into individual records (recv*() units), keep an internal
cursor, and return them one at a time.

Either one is quite different from the original suggestion of doing a
big uiomove() directly into the requesting user app.  (Unless you want
to replace recv*() with a userspace routine[dlibrary which does a
syscall with a big uiomove() upfront, and fakes subsequent recv()*
calls by returning data from the big userspace buffer?)

Matt, are we just differing over terms? No aggro here: I would prefer
a fix that doesn't involve reworking the socket layer, and if I'm
missing something, please do tell me what it is.