Something like the memory trick used in this virtual ring buffer but far more powerful.
well, as others have pointed out, dpdk / netmap are a couple of choices available for bypassing the kernel network stack completely, and get stuff directly into userland. once things are there, you can do all protocol specific parsing etc.
this essentially implies that what you 'see' in memory are mmap'ped ring buffers, not the so called PDU's that you are looking for. the number of protocol-stacks available in userland is, however, to the best of my knowledge, quite limited.
for example, there are couple of folks exploring the option of exporting linux-kernel's networking stack as a library under the N.U.S.E (networking in user space) project. details available here: http://people.netfilter.org/pablo/netdev0.1/papers/Library-O... (https://github.com/libos-nuse/net-next-nuse),
if you have a very specific application in mind that you want to tackle e.g. let's say acting as a transparent proxy, forwarding l2 etc. then things are kind of doable. implementing a generic very high performance stacks (where 2-3 cache-misses will wipe out your timing budgets) is kind of hard, imho...
You can't really do this with TCP though, without changing the hardware. Most modern network adapters support only a scatter/gather list mechanism for receiving/sending packets, but this doesn't work for receiving TCP payloads into contiguous locations, since TCP's data model is a byte stream.
With UDP and SCTP you can do full zero-copy just fine.
A bigger problem is that on the send side you can't reuse the a 0 copy buffer until the remote ack has arrived for that tcp segment which complicates the interface between the application and the tcp stack.
Sometimes you have to do a bit more work to achieve the zero-copy behaviour, but it's available is many cases.
You (necessarily) lose zero-copy when the dataflow isn't one-input-one-output.