Avoid copy of data for UDP parsers #1657
Assignees
Comments
|
My takeaway from #1644 was that introducing a non-owning Since here the |
rsmmr
added a commit
that referenced
this issue
Apr 19, 2024
…erformance. This does two things: - When adding data to a stream, we now do that without copying anything initially. For block input (e.g., UDP) that's always fine because the parser will never suspend before it's fully done parsing; hence we can safely delete it once the parser returns. For stream input (e.g., TCP), we make the stream own its data later if (and only if) the parser suspends. - For block input (e.g., UDP) we now keep reusing the same stream for subsequent blocks, instead of creating a new one each time. This allows the stream to reuse an allocated chunk that it may have still cached internally. The result of this, plus the new chunk caching introduced earlier, is that for a UDP flow, we never need to allocate more than one chunk, and never need to copy any data; and for TCP it's the same as long as parsing consumes all data before suspending (which should be a common case), plus, when we allocate new storage we only copy data that didn't get trimmed immediately anyways. Closes #1657.
rsmmr
added a commit
that referenced
this issue
Apr 22, 2024
…erformance. This does two things: - When adding data to a stream, we now do that without copying anything initially. For block input (e.g., UDP) that's always fine because the parser will never suspend before it's fully done parsing; hence we can safely delete it once the parser returns. For stream input (e.g., TCP), we make the stream own its data later if (and only if) the parser suspends. - For block input (e.g., UDP) we now keep reusing the same stream for subsequent blocks, instead of creating a new one each time. This allows the stream to reuse an allocated chunk that it may have still cached internally. The result of this, plus the new chunk caching introduced earlier, is that for a UDP flow, we never need to allocate more than one chunk, and never need to copy any data; and for TCP it's the same as long as parsing consumes all data before suspending (which should be a common case), plus, when we allocate new storage we only copy data that didn't get trimmed immediately anyways. Closes #1657.
rsmmr
added a commit
that referenced
this issue
Apr 24, 2024
…erformance. This does two things: - When adding data to a stream, we now do that without copying anything initially. For block input (e.g., UDP) that's always fine because the parser will never suspend before it's fully done parsing; hence we can safely delete it once the parser returns. For stream input (e.g., TCP), we make the stream own its data later if (and only if) the parser suspends. - For block input (e.g., UDP) we now keep reusing the same stream for subsequent blocks, instead of creating a new one each time. This allows the stream to reuse an allocated chunk that it may have still cached internally. The result of this, plus the new chunk caching introduced earlier, is that for a UDP flow, we never need to allocate more than one chunk, and never need to copy any data; and for TCP it's the same as long as parsing consumes all data before suspending (which should be a common case), plus, when we allocate new storage we only copy data that didn't get trimmed immediately anyways. Closes #1657.
rsmmr
added a commit
that referenced
this issue
May 7, 2024
…erformance. This does two things: - When adding data to a stream, we now do that without copying anything initially. For block input (e.g., UDP) that's always fine because the parser will never suspend before it's fully done parsing; hence we can safely delete it once the parser returns. For stream input (e.g., TCP), we make the stream own its data later if (and only if) the parser suspends. - For block input (e.g., UDP) we now keep reusing the same stream for subsequent blocks, instead of creating a new one each time. This allows the stream to reuse an allocated chunk that it may have still cached internally. The result of this, plus the new chunk caching introduced earlier, is that for a UDP flow, we never need to allocate more than one chunk, and never need to copy any data; and for TCP it's the same as long as parsing consumes all data before suspending (which should be a common case), plus, when we allocate new storage we only copy data that didn't get trimmed immediately anyways. Closes #1657.
rsmmr
added a commit
that referenced
this issue
May 13, 2024
* origin/topic/robin/gh-1657-udp: Address review feedback. Update Spicy runtime driver to use new stream features for improved performance. Give stream a method to reset it into freshly initialized state. Cache previously trimmed chunks inside stream for reuse. Extend stream API to allow for chunks that don't own their data.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Chatting with @rsmmr , one idea came up to prevent copying data for UDP/block analyzers:
spicy/spicy/runtime/src/driver.cc
Lines 259 to 281 in 26b3b79
If any iterators into the stream are invalidated after
parse1, seems the stream would not necessarily need to own the data.This might improve performance for the spicy-quic analyzer when crunching through large transfers.
Relates to #1644
The text was updated successfully, but these errors were encountered: