> I'll see if I wrote up some of it. I think there were manual pages for the
>> Messages replacing Blocks.
>
>
Here are the three manual pages https://goo.gl/Qykprf
It's not obvious from them, but internally a Fragment can represent a slice
of a Segment*
> 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
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
> 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
> 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"
thanks, this will allow us to know where to look more closely.
On 10/14/18, Francisco J Ballesteros wrote:
> Pure "producer/cosumer" stuff, like sending things through a pipe as long as
> the source didn't need to touch the data ever more.
> Regarding bugs, I meant "producing bugs" not "fixing
Pure "producer/cosumer" stuff, like sending things through a pipe as long as
the source didn't need to touch the data ever more.
Regarding bugs, I meant "producing bugs" not "fixing bugs", btw.
> On 14 Oct 2018, at 09:34, hiro <23h...@gmail.com> wrote:
>
> well, finding bugs is always good :)
>
well, finding bugs is always good :)
but since i got curious could you also tell which things exactly got
much faster, so that we know what might be possible?
On 10/14/18, FJ Ballesteros wrote:
> yes. bugs, on my side at least.
> The copy isolates from others.
> But some experiments in nix and
yes. bugs, on my side at least.
The copy isolates from others.
But some experiments in nix and in a thing I wrote for leanxcale show that some
things can be much faster.
It’s fun either way.
> El 13 oct 2018, a las 23:11, hiro <23h...@gmail.com> escribió:
>
> and, did it improve anything
and, did it improve anything noticeably?
On 10/13/18, Charles Forsyth wrote:
> I did several versions of one part of zero copy, inspired by several things
> in x-kernel, replacing Blocks by another structure throughout the network
> stacks and kernel, then made messages visible to user level.
I did several versions of one part of zero copy, inspired by several things
in x-kernel, replacing Blocks by another structure throughout the network
stacks and kernel, then made messages visible to user level. Nemo did
another part, on his way to Clive
On Fri, 12 Oct 2018, 07:05 Ori Bernstein,
On Thu, 11 Oct 2018 13:43:00 -0700, Lyndon Nerenberg wrote:
> Another case to ponder ... We're handling the incoming I/Q data
> stream, but need to fan that out to many downstream consumers. If
> we already read the data into a page, then flip it to the first
> consumer, is there a benefit to
i'm not saying you should measure a lot even. just trying to make you
verify my point that this is not your bottleneck, just check if you
hit a cpu limit already with that single processing stage (my guess
was FFT).
the reason why i think my guess is right is bec. of experience with
the low
Another case to ponder ... We're handling the incoming I/Q data
stream, but need to fan that out to many downstream consumers. If
we already read the data into a page, then flip it to the first
consumer, is there a benefit to adding a reference counter to that
read-only page and leaving the
On Wed, Oct 10, 2018 at 9:32 PM Bakul Shah wrote:
> Steve wrote "1:1 mapping of the virtual kernel address space such
> that something like zero-copy could be possible"
>
> Not sure what he meant. For zero copy you need to *directly*
> write to the memory allocated to a process. 1:1 mapping is
>
On Wed, 10 Oct 2018 20:56:20 -0400 Dan Cross wrote:
>
> On Wed, Oct 10, 2018 at 7:58 PM wrote:
>
> > > Fundamentally zero-copy requires that the kernel and user process
> > > share the same virtual address space mapped for the given operation.
> >
> > and it is. this doesnt make your point
On Wed, Oct 10, 2018 at 8:20 PM Dan Cross wrote:
>> don't forget the code complexity with dealing with these scattered
>> pages in the *DRIVERS*.
>
> It's really not that hard. The way Linux does it is pretty bad, but it's not
> like that's the only way to do it.
SunOS and Win32 (believe it or
On Wed, Oct 10, 2018 at 7:58 PM wrote:
> > Fundamentally zero-copy requires that the kernel and user process
> > share the same virtual address space mapped for the given operation.
>
> and it is. this doesnt make your point clear. the kernel is always mapped.
>
Meltdown has shown this to be a
> Fundamentally zero-copy requires that the kernel and user process
> share the same virtual address space mapped for the given operation.
and it is. this doesnt make your point clear. the kernel is always mapped.
(you ment 1:1 identity mapping *PHYSICAL* pages to make the lookup cheap?)
the
> On Oct 10, 2018, at 2:54 PM, Steven Stallion wrote:
>
> You seem to be saying zero-copy wouldn't buy anything until these
> other problems are solved, right?
Fundamentally zero-copy requires that the kernel and user process
share the same virtual address space mapped for the given operation.
21 matches
Mail list logo
