Summary plan

Based on the review comments we plan to make the following changes to the paper:

We will shorten the description of the eBPF virtual machine and verifier in sections 3.2 and 3.3, to make space for an annotated example of an XDP program, as suggested by reviewers B and D.
We will add examples of latency numbers, as suggested by reviewer A (time and space will not allow us to add these throughout, though).
We will add a discussion of the design constraints imposed by the integration of XDP into the existing Linux kernel, as suggested by reviewer D.
We will expand the comparison between XDP and other similar solutions, as suggested by reviewer D.
We will add a discussion of offloading XDP programs onto the NIC, as suggested by reviewer A, and on how other higher-level frameworks can build on top of XDP, as suggested by reviewer B.
We will clarify the text to address the smaller nits suggested by the reviewers (primarily by reviewers A and B).

Things that were suggested by the reviewers that we are not planning to address:

We are not going to add a discussion of lessons learned and the evolution of the design, as suggested by reviewer A. We agree that this would be valuable, but we feel that the limited space in the paper would be better spent on other things. However, we will certainly consider publishing such an overview in another context at a later date.
We do not plan to add other competing systems to the performance evaluation, because of time and space constraints. We will, however, clarify that the reason we picked DPDK for the comparison is that others have shown DPDK to be the highest-performing of the existing frameworks, which is why we picked this as the one to compare against (see e.g., Gallenmuller et al, as cited in the paper).

Shepherd

[X] List kinds of errors that are caught by verifier and those that aren’t.
[ ] Performance numbers to qualify assertion that we can close gap.
[X] Say that we don’t want to compare against best-of-breed solutions in section 5.

[X] Discuss offloading of XDP programs to smart-NICs.
[X] Latency numbers
Verifier risk
[X] Overhead
[X] Design journey (ENOSPACE)
Better limitations section?
- [X] Number of programs supported
- [X] Collect limitations on loops etc in one place
- [X] What happens if an XDP program is bad?
[X] Clarify that experimental runs are single-runs + highly repeatable

[X] “Generalising XDP”: Cite examples of other packages (IDS, P4, OVS(?)) implementing parts of their functionality in XDP
Clarify how we think new helpers will be implemented
[X] Simplify sections 3.2 and 3.3
Talk about loading/unloading of programs

[X] Fig 1: Clarify why XDP is shown inside the device driver (that’s where the hook is)
[ ] Explain CPU redirect in a bit more detail
[X] Expand on limitations on C program (same as section above?)
[X] Explain PACKET_END check
[X] Example for pointer copies
[X] Table 2 - clarify arithm column
[X] Clarify that we disable hyper-threading
[X] Explain non-linear growth in fig 4
[X] Explain how device driver optimisations can help close the performance gap (and that DPDK has its own driver)
[X] Clarify routing example: No cache, 4000 IPs picked because above that it didn’t make any difference
[X] Explain DoS packet rules in more detail
[X] No helpers for the load balancer

Nothing we need to address

[X] Rework Section 2 to more explicitly compare the design of other solutions to XDP (can we do that without taking up too much space? - yes we can!)
[X] Be a bit more explicit about the fact that XDP needs to fit into an existing operating system, and which design constraints that imposes.
[X] Cut down on description of eBPF in favour of example(s)
[X] Explain that DPDK has way higher performance than anything else, which is why we compare against that
[X] Mention the other prior work items (“StackMap, Sandstorm, mTCP, Seastar, IX, etc”)(?)