[POC] bpf2go/struct_ops: implement StructOps support by shun159 · Pull Request #1973 · cilium/ebpf

shun159 · 2026-03-29T09:25:08Z

Implement code generation and library support for declarative initialization of struct_ops maps. This allows users to initialize struct_ops member, using standard Go structs during the LoadAndAssign process.

bpf2go changes:

Scans for ebpf.StructOpsMap in the CollectionSpec and generates corresponding Go struct types.
Automatically maps kernel function pointers to *ebpf.Program and scalar members to appropriate Go types.

Library changes:

Modify assignValues and LoadAndAssign to pass the reflect.Value of target fields, enabling the library to read pre-instantiated data from the user-provided objects struct.
Introduce loadStructOps to synchronize Go struct fields with the MapSpec before the map is created in the kernel.
Implement a "partial override" strategy in structOpsPatchValue: only non-zero fields in the Go struct are patched into the ELF section data, preserving ELF-defined defaults for uninitialized fields.
Support early relocation of struct_ops function pointers by injecting ebpf.Program FDs into the section data buffer during the patch process.

Ref: #1957

Implement code generation and library support for declarative initialization of struct_ops maps. This allows users to initialize struct_ops member, using standard Go structs during the LoadAndAssign process. bpf2go changes: - Scans for ebpf.StructOpsMap in the CollectionSpec and generates corresponding Go struct types. - Automatically maps kernel function pointers to *ebpf.Program and scalar members to appropriate Go types. Library changes: - Modify assignValues and LoadAndAssign to pass the reflect.Value of target fields, enabling the library to read pre-instantiated data from the user-provided objects struct. - Introduce loadStructOps to synchronize Go struct fields with the MapSpec before the map is created in the kernel. - Implement a "partial override" strategy in structOpsPatchValue: only non-zero fields in the Go struct are patched into the ELF section data, preserving ELF-defined defaults for uninitialized fields. - Support early relocation of struct_ops function pointers by injecting ebpf.Program FDs into the section data buffer during the patch process. Ref: cilium#1957 Signed-off-by: shun159 <dreamdiagnosis@gmail.com>

Signed-off-by: shun159 <dreamdiagnosis@gmail.com>

dylandreimerink

Thanks again for working on this. I flagged a few things for you to look at.

dylandreimerink · 2026-03-30T14:11:30Z

collection.go

+		ms := cs.Maps[name]
+		if ms != nil && ms.Type == StructOpsMap {
+			vType := typ
+			if vType.Kind() == reflect.Ptr {
+				vType = vType.Elem()
+			}
+
+			if vType.Kind() == reflect.Struct && typ != reflect.TypeOf((*Map)(nil)) {
+				return loader.loadStructOps(name, val)
+			}
+		}


This code should go into loadMap, as its a special case of loading a map.

dylandreimerink · 2026-03-30T14:14:07Z

struct_ops.go

 	dstOff := int(km.Offset.Bytes())

 	if srcOff < 0 || srcOff+mSize > len(data) {
+		fmt.Println(srcOff, srcOff+mSize, len(data))


I think you forgot to remove this after debugging.

dylandreimerink · 2026-03-30T14:17:24Z

struct_ops.go

+// the operation is skipped to preserve the original default value defined in the ELF.
+// Currently, nested structs or unions are not supported for non-zero updates to
+// avoid complex recursive patching.
+func structOpsCopyMemberFromStructValue(fieldVal reflect.Value, m btf.Member, dstOff int, secData []byte) error {


That is a very verbose function name. Perhaps just structOpsCopyMember? That is about as long as I would go.

dylandreimerink · 2026-03-30T14:27:25Z

struct_ops.go

+	srcPtr := unsafe.Pointer(fieldVal.UnsafeAddr())
+	srcData := unsafe.Slice((*byte)(srcPtr), kSize)


We shouldn't be unsafe casting like this. Use the sysenc.Marshal utility instead. It internally has optimizations to do an unsafe cast as well, but only when it determines it is safe to do so, and will fallback to slower but safe logic otherwise.

dylandreimerink · 2026-03-30T14:39:55Z

struct_ops.go

+	return nil
+}
+
+func structOpsFindMemberByName(st *btf.Struct, name string) (*btf.Member, error) {


Also very verbose name for what it does.

I would just inline this. This function is not reused outside of its parent. You are creating an error just to then continue in its parent function.

It can be something like:

var m btf.Member if idx := slices.IndexFunc(st.Members, func(m btf.Member) bool { return m.Name == name } { m = st.Members[idx] } else { continue }

dylandreimerink · 2026-03-30T14:50:51Z

cmd/bpf2go/gen/output.tpl

+// {{ .Name.StructOps }} contains all struct_ops types.
+type {{ .Name.StructOps }} struct {
+{{- range $name, $id := .StructOps }}
+	{{ $id }} {{ $.Name }}{{ $id }} `ebpf:"{{ $name }}"`
+{{- end }}


I would consider surrounding this with an {{ if .StructOps }}. Programs, maps, and variables are expected to be in every generated file. But is odd to have empty struct ops related types, even when no struct ops are in use, which will be the majority of cases.

dylandreimerink · 2026-03-30T14:59:46Z

cmd/bpf2go/gen/output.go

+		var fieldType string
+		if ptr, ok := btf.As[*btf.Pointer](btf.UnderlyingType(m.Type)); ok {
+			if _, ok := btf.As[*btf.FuncProto](btf.UnderlyingType(ptr.Target)); ok {
+				fieldType = "*ebpf.Program"
+			}
+		}


This logic of emitting a *ebpf.Program for pointers to functions seems to be the only reason for having this logic here. I think it would be better to adjust the GoFormatter in btf/format.go to do this instead, so you can reuse the rest of the existing logic for writing go types.

dylandreimerink · 2026-03-30T15:00:35Z

cmd/bpf2go/gen/output.go


 	sb.WriteString(fmt.Sprintf("// %s is a struct type for the struct_ops map.\n", goTypeName))
 	sb.WriteString(fmt.Sprintf("type %s struct {\n", goTypeName))
-	sb.WriteString(fmt.Sprintf("\t_ structs.HostLayout\n"))


This commit can be squashed into the previous one.

dylandreimerink · 2026-03-30T15:01:44Z

cmd/bpf2go/test/test_bpfeb.go

+	testStructOps
+}
+
+// testStructOps contains all struct_ops types.
+type testStructOps struct {


All of this churn in these files can be avoided if we only emit these when there is at least one struct_ops type.

dylandreimerink · 2026-03-30T15:12:40Z

cmd/bpf2go/gen/output.go

+			if _, ok := btf.As[*btf.Struct](underlying); ok {
+				size, _ := btf.Sizeof(m.Type)
+				fieldType = fmt.Sprintf("[%d]byte", size)
+			} else if _, ok := btf.As[*btf.Union](underlying); ok {
+				size, _ := btf.Sizeof(m.Type)
+				fieldType = fmt.Sprintf("[%d]byte", size)
+			}


This also deviates from the GoFormatter behavior, which would make nested structs here.

So question, did we do this because recursive emitting is difficult or is there a technical reason? If its just difficult, usage of the GoFormatter should solve it. Otherwise, I would suggest modifying the BTF before its passed to the formatter to get a similar end result.

shun159 requested a review from a team as a code owner March 29, 2026 09:25

bpf2go: remove unnecessary fmt.Sprint call

067c0da

Signed-off-by: shun159 <dreamdiagnosis@gmail.com>

shun159 force-pushed the bpf2go_struct_ops_support branch from dae125c to 067c0da Compare March 29, 2026 09:31

run make to format code

60b3842

Signed-off-by: shun159 <dreamdiagnosis@gmail.com>

shun159 force-pushed the bpf2go_struct_ops_support branch from 7a81514 to 60b3842 Compare March 29, 2026 09:46

shun159 requested a review from ti-mo as a code owner March 29, 2026 09:46

shun159 marked this pull request as draft March 29, 2026 09:46

cmd/bpf2go: represent nested structs in struct_ops as bytes

a128119

Signed-off-by: shun159 <dreamdiagnosis@gmail.com>

dylandreimerink requested changes Mar 30, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[POC] bpf2go/struct_ops: implement StructOps support#1973

[POC] bpf2go/struct_ops: implement StructOps support#1973
shun159 wants to merge 4 commits intocilium:mainfrom
shun159:bpf2go_struct_ops_support

shun159 commented Mar 29, 2026

Uh oh!

dylandreimerink left a comment

Uh oh!

dylandreimerink Mar 30, 2026

Uh oh!

dylandreimerink Mar 30, 2026

Uh oh!

dylandreimerink Mar 30, 2026

Uh oh!

dylandreimerink Mar 30, 2026

Uh oh!

dylandreimerink Mar 30, 2026

Uh oh!

dylandreimerink Mar 30, 2026

Uh oh!

dylandreimerink Mar 30, 2026

Uh oh!

dylandreimerink Mar 30, 2026

Uh oh!

dylandreimerink Mar 30, 2026

Uh oh!

dylandreimerink Mar 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

		srcPtr := unsafe.Pointer(fieldVal.UnsafeAddr())
		srcData := unsafe.Slice((*byte)(srcPtr), kSize)

Conversation

shun159 commented Mar 29, 2026

Uh oh!

dylandreimerink left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants