On Mon, 09 Mar 2020 12:41:14 +0100 Toke Høiland-Jørgensen wrote: > > You said that like the library doesn't arbitrate access and manage > > resources.. It does exactly the same work the daemon would do. > > Sure, the logic is in the library, but the state (which programs are > loaded) and synchronisation primitives (atomic replace of attached > program) are provided by the kernel. I see your point of view. The state in the kernel which the library has to read out every time is what I was thinking of as deserialization. The library has to take some lock, and then read the state from the kernel, and then construct its internal state based on that. I think you have some cleverness there to stuff everything in BTF so far, but I'd expect if the library grows that may become cumbersome and wasteful (it's pinned memory after all). Parsing the packet once could be an example of something that could be managed by the library to avoid wasted cycles. Then programs would have to describe their requirements, and library may need to do rewrites of the bytecode. I guess everything can be stuffed into BTF, but I'm not 100% sure kernel is supposed to be a database either. Note that the atomic replace may not sufficient for safe operation, as reading the state from the kernel is also not atomic. > > Daemon just trades off the complexity of making calls for the > > complexity of the system and serializing/de-serializing the state. > > What state are we serialising? I'm not sure I would consider just > pinning things in bpffs as "state serialisation"? At a quick glance at your code, e.g. what xdp_parse_run_order() does ;)
