[ongy]

that's what GP said.

They are semantically simple string operations whose computational complexity scales with string length. Near unbound string lengths would exhaust the time (somewhat aproximated by instruction) budget of eBPF applications doing even a single one.

[tptacek]

That's all that's there. String-integer conversion and comparison.

[bandrami]

I think the point was not to show "there are a lot of helper functions" but rather to point out "the (undocumented) helper functions that exist are problematic"

[tptacek]

That's not "quite a few" string helpers.

[monocasa]

There are others too, for instance string formatting: https://elixir.bootlin.com/linux/latest/source/kernel/bpf/he...

[tptacek]

Write an eBPF program that actually needs to do any kind of meaningful string manipulation, and you'll quickly get a sense of just how rich the BPF helper inventory is in string processing functions. It'll be sharply obvious, because bounded loop enforcement will keep you from writing even the simplest string functions yourself.

[monocasa]

I never said that it's anywhere near a complete set. My point is that they exist as something that must be a helper because they represent a type of raw computation expected of bpf programs, but incompatible with it's verifier model.

The original parent was talking about removing all helpers,

> They show that various escape hatches can be eliminated or simplified. However they don't have a plan to eliminate all escape hatches

which simply doesn't make sense. The string helpers are a good example one might not have thought of beyond helpers that expose linux specific functionality.

The specific quantity of "quite a few" was left intentionally vague as it's orthogonal to my core point.

And yes, string ops are difficult if not impossible to write in verified bpf; that's almost a restatement of what I've been saying this whole thread.