brbzull0 opened a new pull request, #9904:
URL: https://github.com/apache/trafficserver/pull/9904
**WIP**
**WIP**
### Descrition
This PR adds support for UDP GRO when reading the socket using
`recvm(m)gsg`. This PR also includes support for `recvmmsg` when is available
by the OS.
There is now a new configuration variable:
```yaml
# records.yaml
ts:
udp:
enable_gro: 1 # Enabled by default.
```
----
### Notes
All the tests were done using GET only and setting the h2load parameter to
`--max-udp-payload-size=2k`.
|Feature |Total # Req | # Clients | # recvmmsg | # recvmsg |
|--------------|------------|-----------|------------|-----------|
| recvmmsg+gro | 100k | 100 | 22834 | 0 |
| recvmmsg | 100k | 100 | 23501 | 0 |
| recvmsg+gro | 100k | 100 | | 247970 |
| recvmmsg | 100k | 100 | | 249097 |
As I didn't see much of a difference between having GRO enabled or disabled
I did run a test with debug
enabled and I was able to count how many packets came with the GRO set in
the ancillary data.
Then I realised why I wasn't actually seeing much difference, not too many
packets were spliced by the kernel.
Packets with (No GRO/GRO) = Number of times that ATS detected a packet with
spliced with GRO.
|Feature |Total # Req | # Clients | # recvmmsg | # recvmsg | # Packets
with (No GRO/GRO) | GRO % |
|--------------|------------|-----------|------------|-----------|---------------|-------|
| recvmmsg+gro | 100k | 100 | 13929 | 0 | 223080
/ **180** | 0.8% |
| recvmsg+gro | 100k | 100 | 0| 278718 | 231760
/ **34484** | 14% |
**Using recvmmsg reduced the number of syscall significantly**
This is what I used for this tests:
**bpftrace**
```bash
bpftrace -e 'tracepoint:syscalls:sys_enter_recvm* { @[comm, probe] =
count(); }'
```
**h2load**
```bash
/opt/bin/h2load -n 100000 -c 100 --npn-list=h3 URL --max-udp-payload-size=2k
```
I was using only **GET** requests with around 15 header with about 80 bytes
each.
I have not tried POST yet which I believe will give us better insights.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
