From: John Fastabend <john.fastab...@gmail.com> Date: Mon, 5 Mar 2018 22:22:21 -0800
> All I meant by this is if an application uses sendfile() call > there is no good way to know when/if the kernel side will copy or > xmit the data. So a reliable user space application will need to > only modify the data if it "knows" there are no outstanding sends > in-flight. So if we assume applications follow this then it > is OK to avoid the copy. Of course this is not good enough for > security, but for monitoring/statistics (my use case 1 it works). For an application implementing a networking file system, it's pretty legitimate for file contents to change before the page gets DMA's to the networking card. And that's perfectly fine, and we everything such that this will work properly. The card checksums what ends up being DMA'd so nothing from the networking side is broken. So this assumption you mention really does not hold. There needs to be some feedback from the BPF program that parses the packet. This way it can say, "I need at least X more bytes before I can generate a verdict". And you keep copying more and more bytes into a linear buffer and calling the parser over and over until it can generate a full verdict or you run out of networking data.
