On Fri, Jul 15, 2016 at 12:56 AM, Sasha Goldshtein <[email protected]> wrote: > On Fri, Jul 15, 2016 at 3:59 AM Alexei Starovoitov > <[email protected]> wrote: >> >> On Wed, Jul 13, 2016 at 4:17 PM, Kyle Laracey via iovisor-dev >> <[email protected]> wrote: >> > >> > An additional issue brought up on the call (I apologize for forgetting >> > by >> > whom) was that any comparisons on long strings would bloat the program, >> > perhaps beyond the maximum allowed program size. Would the solution to >> > this >> > be to have something like another BPF helper function in the kernel? >> >> the idea we discussed is to introduce string map similar to stackmap >> where different strings are referenced by id. The helper would be able >> to push user or kernel strings into this map. >> That should solve https://github.com/iovisor/bcc/issues/607 >> What is your use case that needs strings? >> To come up with good kernel design we need to >> categorize all use cases that need strings. > > > Both the trace and argdist tools collect strings from tracepoints, > uprobes/kprobes, and USDT tracepoints. These strings are displayed to the > user (trace) [1] or used as keys for histograms and event frequency counters > (argdist) [2]. The length of the string is usually not known in advance, so > something like strcpy would be very useful. > > The proposed string map solution would work as long as the kernel helper > would be able to support two modes of operation: read string until null > terminator, and read N characters.
exactly. was thinking about: u32 id = bpf_get_unsafe_string(map, unsafe_ptr, len_or_zero) that returns negative error or 32-bit string id. either it copies 'len' bytes or the whole string. or a slight variant: u64 id; err = bpf_get_unsafe_string(map, unsafe_ptr, len_or_zero, &id) 64-bit ids will occupy more space when we'd need to store them in other maps and/or pass to user space, but 64bit space allows to encode short strings into it as-is (little endian). Keeping real ids with 63rd bit set. the main problem is that character memory needs to be pre-allocated, since bpf can be called from contexts where kmalloc is not allowed, so have to use gen_pool_alloc api. the hash table to point to strings is probably enough and we don't need a trie. Any data structure suggestions? > We will also need a helper that can > actually retrieve the string based on its id. yes. from user space, right? is there use case to do that from the bpf? > [1] Examples of tracing string values: file names being opened, JVM thread > names starting/finishing. > > [2] Examples of frequency counting string values: web server URLs being hit > (e.g. in Node.js USDT probes), exec() command lines, JVM method names being > executed. yep. all makes sense. Hannes, do you know systemtap's use cases? _______________________________________________ iovisor-dev mailing list [email protected] https://lists.iovisor.org/mailman/listinfo/iovisor-dev
