The underlying chunks returned from PullUp should not be shared,
since the underlying slice can sometimes be directly modified. This change
also reworks some of the network parsing code so that ownership of
views is more explicit to the reader.
PiperOrigin-RevId: 538230394
Merge clears the other buffer, so rather than cloning and dealing with
refcounts, we can just steal other's view list and adjust sizes.
This increases the speed of Merge 10x, and this was with a benchmark that
didn't do any TrimFront/Truncate (which will induce copying in the old
implementation).
BenchmarkMerge
BenchmarkMerge-33 99412884 12.74 ns/op 0 B/op 0 allocs/op
BenchmarkOldMerge
BenchmarkOldMerge-33 6075222 217.4 ns/op 0 B/op 0 allocs/op
This change uncovered that PacketBuffer.DeepCopyForForwarding wasn't doing a
true deep copy. It seems that, in the ICMP error path, a call to Merge was
forcing a deep copy (maybe because Append was copying bytes), obfuscating the
issue. This change also addresses that issue by having DeepCopyForForwarding
produce a copy that shares no data with other packets.
PiperOrigin-RevId: 537143838
The extra pointer indirection is not necessary and allows for a nil buffer.
This change bumps the PacketBuffer struct size from 296 to 792 bytes.
PiperOrigin-RevId: 422669812
PacketData should not be modified and should be treated readonly because it
represents packet payload. The old DeleteFront method allowed callers to modify
the underlying buffer which should not be allowed.
Added a way to consume from the PacketData instead of deleting from it.
Updated call points to use that instead.
Reported-by: [email protected]
PiperOrigin-RevId: 399268473
Earlier PacketBuffer.Clone() would do a shallow top level copy of the packet
buffer - which involved sharing the *buffer.Buffer between packets. Reading
or writing to the buffer in one packet would impact the other.
This caused modifications in one packet to affect the other's pkt.Views() which
is not desired. Change the clone to do a deeper copy of the underlying buffer
list and buffer pointers. The payload buffers (which are immutable) are still
shared. This change makes the Clone() operation more expensive as we now need to
allocate the entire buffer list.
Added unit test to test integrity of packet data after cloning.
Reported-by: [email protected]
Reported-by: [email protected]
Reported-by: [email protected]
PiperOrigin-RevId: 390277713
Benchmark iperf3:
Before After
native->runsc 5.14 5.01 (Gbps)
runsc->native 4.15 4.07 (Gbps)
It did introduce overhead, mainly at the bridge between pkg/buffer and
VectorisedView, the ExtractVV method. Once endpoints start migrating away from
VV, this overhead will be gone.
Updates #2404
PiperOrigin-RevId: 373651666
This change changes `buffer.data` into a `[]byte`, from `[bufferSize]byte`.
In exchange, each `buffer` is now grouped together to reduce the number of
allocation. Plus, `View` now holds an embeded list of `buffer` (via `pool`) to
support the happy path which the number of buffer is small. Expect no extra
allocation for the happy path.
It is to enable the use case for PacketBuffer, which
* each `View` is small (way less than `defaultBufferSize`), and
* needs to dynamically transfer ownership of `[]byte` to `View`.
(to allow gradual migration)
PiperOrigin-RevId: 333197252
Fixes *.sh Java runtime tests, where splice()-ing from a pipe to /dev/zero
would not actually empty the pipe.
There was no guarantee that the data would actually be consumed on a splice
operation unless the output file's implementation of Write/PWrite actually
called VFSPipeFD.CopyIn. Now, whatever bytes are "written" are consumed
regardless of whether CopyIn is called or not.
Furthermore, the number of bytes in the IOSequence for reads is now capped at
the amount of data actually available. Before, splicing to /dev/zero would
always return the requested splice size without taking the actual available
data into account.
This change also refactors the case where an input file is spliced into an
output pipe so that it follows a similar pattern, which is arguably cleaner
anyway.
Updates #3576.
PiperOrigin-RevId: 328843954
