Il giorno dom 14 ott 2018 alle ore 19:39 Ole-Hjalmar Kristensen
ha scritto:
>
> OK, that makes sense. So it would not stop a client from for example first
> read an index block in a B-tree, wait for the result, and then issue read
> operations for all the data blocks in parallel.
If the client
It's useful internally in protocol implementation, specifically to avoid
copying in transport protocols (for later retransmission), and the
modifications aren't vast.
A few changes were trickier, often because of small bugs in the original
code. icmp does some odd things i think.
Btw, "zero copy"
> Btw, "zero copy" isn't the right term and I preferred another term that I've
> now forgotten. Minimal copying, perhaps.
I like that, "zero-copy" makes me imply other linux-specifics, and
those are hard to not get emotional about.
> Also, NUMA effects are more important in practice on big multicores. Some
> of the off-chip delays are brutal.
yeah, we've been talking about this on #cat-v. even inside one CPU
package amd puts multiple dies nowadays, and the cross-die cpu cache
access delays are approaching the same dimensions
They are machines designed to run programs most people do not write!
On Mon, 15 Oct 2018 at 19:20, hiro <23h...@gmail.com> wrote:
> > Also, NUMA effects are more important in practice on big multicores. Some
> > of the off-chip delays are brutal.
>
> yeah, we've been talking about this on #cat-v.
> It's useful internally in protocol implementation, specifically to avoid
> copying in transport protocols (for later retransmission), and the
> modifications aren't vast.
> A few changes were trickier, often because of small bugs in the original
> code. icmp does some odd things i think.
that ma