Optimize syscalls in GTP receiver/sender, GTP UL callback optimization#280
Open
rorsc wants to merge 4 commits into
Open
Optimize syscalls in GTP receiver/sender, GTP UL callback optimization#280rorsc wants to merge 4 commits into
rorsc wants to merge 4 commits into
Conversation
This commit makes a simple optimization to avoid unnecessary memcpy() when sending GTP packets. Instead, it uses struct iovec to indicate both header and the actual packet to be s end, and uses sendmsg() to pass both to the kernel, which handles the rest. Signed-off-by: Robert Schmidt <robert.schmidt@openairinterface.org>
Collaborator
|
CI Build: #726 | Failed on the following stages: |
rorsc
changed the title
This commit tries to reduces the amount of syscalls for receiving GTP packets. Instead of making a recvfrom() call for each packet, it uses recvmmsg() to receive multiple (currently, 8) packets at once, which should reduce overhead, and employs the normal processing chain. Since this requires a larger number of buffers which still all might receive up to 64kB of (UDP) data, the actual buffer is moved to gtpv1uReceiver() to not re-allocate on the stack each time (maybe the compiler would optimize it, but I think it makes the code a bit clearer). Signed-off-by: Robert Schmidt <robert.schmidt@openairinterface.org>
Signed-off-by: Robert Schmidt <robert.schmidt@openairinterface.org>
In monolithic, at the interface between PDCP and RLC, there is a pdcp_data_ind_queue to avoid calling into PDCP while holding a lock in RLC, which could lead to deadlocks if PDCP tries to call into RLC at the same time. For reasons I don't understand, we did the same when using F1-U. However, that seems completely unnecessary: - there is no RLC (we call from GTP), so deadlocks can't happen - in DL, GTP calls directly into the stack, so for simplicity, do the same in UL. Signed-off-by: Robert Schmidt <robert.schmidt@openairinterface.org>
Collaborator
|
CI Build: #728 | Failed on the following stages: |
Collaborator
|
CI Build: #729 | Failed on the following stages: |
Collaborator
|
change the title, it is UL in F1, but DL in N3 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Use different syscalls to send data in GTP paths:
Further, for the UL transmission in F1-U, remove a useless malloc() that was done for each packet.
on my laptop, this can reduce losses in high throughput scenarios, tested with the CU-UP load tester:
the real numbers are platform specific, i.e., one would need to find a maximum value (before/after) to show a change in losses of packets.