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