On Fri, Jan 7, 2022 at 1:54 PM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: > > Because the data pages are recycled by the page pool, and the test runner > doesn't re-initialise them for each run, subsequent invocations of the XDP > program will see the packet data in the state it was after the last time it > ran on that particular page. This means that an XDP program that modifies > the packet before redirecting it has to be careful about which assumptions > it makes about the packet content, but that is only an issue for the most > naively written programs. This is too vague and partially incorrect. The bpf program can do bpf_xdp_adjust_meta() and otherwise change packet boundaries. These effects will be seen by subsequent XDP_PASS/TX/REDIRECT, but on the next iteration the boundaries will get reset to the original values. So the test runner actually re-initializes some parts of the data, but not the contents of the packet. At least that's my understanding of the patch. The users shouldn't need to dig into implementation to discover this. Please document it. The more I think about it the more I believe that it warrants a little blurb in Documentation/bpf/ that describes what one can do with this "xdp live mode". Another question comes to mind: What happens when a program modifies the packet? Does it mean that the 2nd frame will see the modified data? It will not, right? It's the page pool size of packets that will be inited the same way at the beginning. Which is NAPI_POLL_WEIGHT * 2 == 128 packets. Why this number? Should it be configurable? Then the user can say: init N packets with this one pattern and the program will know that exactly N invocation will be with the same data, but N+1 it will see the 1st packet again that potentially was modified by the program. Is it accurate?
