The BPF map is named map_of_kmesh_socket, but the Go test code in test/bpf_ut/bpftest/workload_test.go:806 attempts to access it using the name km_socket. This mismatch will cause the test to fail with a nil map object when trying to get its file descriptor.

To ensure consistency with other BPF maps accessed from Go tests in this file (e.g., km_manage) and to fix the test, it's recommended to rename this map to km_socket.

struct {
    __uint(type, BPF_MAP_TYPE_SOCKHASH);
    __type(key, struct bpf_sock_tuple);
    __type(value, __u32);
    __uint(max_entries, MAP_SIZE_OF_MANAGER);
    __uint(map_flags, 0);
} km_socket SEC(".maps");

Yes, why define a map here, we already have one in bpf/kmesh/workload/sockops.c

We need to redefine the map in sendmsg.c because each eBPF object file (.o) only contains its own maps. The Go test loads workload_sendmsg_test.o, so it can only access maps defined in that file. Even though the same map exists in sockops.c, it’s in a different ELF file, so the test can’t see it.

By redefining it as km_socket in sendmsg.c, the map exists in the test’s ELF file and the Go test can access it.

I think this solution works for the unit test. Do you think it’s reasonable, or do you have a better approach?

The test starts a server in a goroutine but doesn't wait for it to finish. This can lead to flaky tests where the main test function exits before the goroutine has completed its checks, potentially missing errors reported by t.Error or t.Errorf.

To fix this, you should use a sync.WaitGroup:

1. Add var wg sync.WaitGroup and wg.Add(1) before starting the goroutine.
2. Add defer wg.Done() at the beginning of the goroutine.
3. Add wg.Wait() at the end of the workFunc, after the client has sent data, to wait for the server goroutine to finish.

The WORKLOAD_SENDMSG_FLAGS variable is a duplicate of XDP_FLAGS. To improve maintainability and avoid redundancy, you can reuse XDP_FLAGS for the workload_sendmsg_test.o target.

workload_sendmsg_test.o: workload_sendmsg_test.c
	$(QUIET) $(CLANG) $(CLANG_FLAGS) $(XDP_FLAGS) -c $< -o $@

These port numbers are magic numbers. For better readability and maintainability, please define them as named constants, for example testClientPort and testServerPort.

The TLV validation logic uses several magic numbers (e.g., 16, 0x01, 6, 0xFE). These correspond to values defined in bpf/kmesh/workload/sendmsg.c. To improve readability and consistency, please define these values as constants in the Go test as well. For example:

const (
    tlvOrgDstAddrType   = 0x01
    tlvPayloadType      = 0xfe
    tlvIPv4DataLen      = 6
    expectedMinRecvSize = 16
)

The map name "km_socket" doesn't match the map defined in sendmsg.c which is "map_of_kmesh_socket". This will cause the test to fail as sockMap will be nil.

The map reference "map_of_sock_storage" is not defined or included in this test file, which will cause a compilation error.

The defer statement should be placed after the error check for the Dial operation. If Dial fails, conn will be nil and calling Close() on it will panic.

The magic number 16 should be defined as a constant or calculated based on the TLV structure (1 byte type + 4 bytes length + 4 bytes IP + 2 bytes port + 1 byte end tag = 12 bytes minimum, not 16).

Yes, why define a map here, we already have one in bpf/kmesh/workload/sockops.c

I would suggest we moving these test building to a script and keep makefile simple

I would suggest we moving these test building to a script and keep makefile simple我建议我们将这些测试构建移动到脚本中并使 makefile 保持简单

Should all the previous include directives be combined into a single bash script?

instead of using a fixed port, we can let os randomly choose which free port by calling net.Listen(:0) ?

can you abstract a utility function to parse tlv protocol? So we can resue it in other tests as well

I need to verify the IP, port, and the correctness of the format specifically, so I feel it’s not really reusable. Do you think it’s necessary to abstract it?If abstracted, the message, IP, and port need to be passed as parameters. IPv4 and IPv6 should share the logic first when needed, right?

can you abstract a utility function to parse tlv protocol? So we can resue it in other tests as well你能抽象出一个实用函数来解析 TLV 协议吗？这样我们就可以在其他测试中重复使用它了。

can you abstract a utility function to parse tlv protocol? So we can resue it in other tests as well你能抽象出一个实用函数来解析 TLV 协议吗？这样我们就可以在其他测试中重复使用它了。

Yes, I’ve abstracted the TLV parsing logic into ParseTLVMessage and ValidateTLVMessage in a new file tlv_utils.go, so it can be reused in other tests.

can you elaborate a little bit how this function can be used

Okay, I will add some comments.

add a comment before this struct to indicate this is used for test only

@wxnzb is there a way to move this out from this file, i donot want to make it load and attached to kernel when we run kmesh.