eBPF (bpf2go) - ARRAY / HASH map 기본 사용법
지난 글에서 streaming 형식의 2가지 MAP을 알아봤습니다.
Linux: 109. eBPF / bpf2go - BPF_PERF_OUTPUT / BPF_MAP_TYPE_PERF_EVENT_ARRAY 사용법
; https://www.sysnet.pe.kr/2/0/13824
Linux: 110. eBPF / bpf2go - BPF_RINGBUF_OUTPUT / BPF_MAP_TYPE_RINGBUF 사용법
; https://www.sysnet.pe.kr/2/0/13825
이번에는 일반적인 MAP 사용법에 대해 알아볼 텐데요, 이미 max_entries == 1인 경우로 제한해 전역 변수처럼 사용하는 BPF_MAP_TYPE_HASH 유형의 MAP을 다뤄보긴 했습니다.
eBPF / bpf2go - (BPF_MAP_TYPE_HASH) Map을 이용한 전역 변수 구현
; https://www.sysnet.pe.kr/2/0/13817
따라서, max_entries 값만 늘린다면 얼마든지 전역 컬렉션 저장소로 사용할 수 있는데요,
struct {
__uint(type, BPF_MAP_TYPE_HASH);
__type(key, __u32);
__type(value, __u32);
__uint(max_entries, 10000);
/* __uint(map_flags, BPF_F_NO_PREALLOC); */ // 지정해야 할 flags가 있는 경우
} my_hash_map SEC(".maps");
// key, value의 크기는 2개 합쳐서 KMALLOC_MAX_SIZE보다 크면 안 됨
// https://stackoverflow.com/questions/12568379/kmalloc-size-allocation
// #define KMALLOC_SHIFT_MAX 30
// #define KMALLOC_MAX_SIZE (1UL << KMALLOC_SHIFT_MAX)
// 1073741824 (1024 * 1024 * 1024 == 1GB)
// $ cat /usr/src/kernel/linux-6.11.5/include/linux/slab.h
// #define KMALLOC_SHIFT_MAX (MAX_PAGE_ORDER + PAGE_SHIFT)
// #define KMALLOC_MAX_SIZE (1UL << KMALLOC_SHIFT_MAX)
// https://github.com/torvalds/linux/blob/master/tools/include/linux/mm.h
// #define PAGE_SHIFT 12
// https://github.com/torvalds/linux/blob/master/include/linux/mmzone.h
// #ifndef CONFIG_ARCH_FORCE_MAX_ORDER
// #define MAX_PAGE_ORDER 10 // 1 << (10 + 12) == 4MB
// #else
// #define MAX_PAGE_ORDER CONFIG_ARCH_FORCE_MAX_ORDER
// #endif
[Syscall commands]
BPF_MAP_LOOKUP_ELEM
BPF_MAP_LOOKUP_AND_DELETE_ELEM
BPF_MAP_UPDATE_ELEM
BPF_MAP_GET_NEXT_KEY
BPF_MAP_LOOKUP_BATCH
BPF_MAP_LOOKUP_AND_DELETE_BATCH
[Helper functions]
bpf_for_each_map_elem
bpf_map_delete_elem
bpf_map_lookup_elem
bpf_map_update_elem
지원하는 helper 함수를 이용해 eBPF 측에서 자유롭게 MAP에 추가/삭제/조회할 수 있습니다.
SEC("tracepoint/syscalls/sys_enter_execve")
int sys_enter_execve(struct trace_event_raw_sys_enter* ctx)
{
__u32 key = 500;
__u32 value = 1000;
bpf_map_update_elem(&my_hash_map, &key, &value, BPF_ANY);
return 0;
}
물론 go 언어 측에서도 해당 맵의 데이터를 조회할 수 있는데요, 가령 아래와 같이 작성하면 map에 추가된 모든 요소를 출력하게 됩니다.
func IterMyHashMap(bpfObj ebpf_basicObjects) {
iter := bpfObj.MyHashMap.Iterate()
var (
key uint32
value uint32
)
idx := 0
for iter.Next(&key, &value) {
log.Printf("[%v], key: %v, value: %v\n", idx, key, value)
idx++
}
}
어렵지 않죠? ^^
HASH 유형의 맵 외에 ARRAY 유형의 맵도 있습니다.
struct {
__uint(type, BPF_MAP_TYPE_ARRAY);
__type(key, __u32); // ARRAY MAP의 경우 key 크기는 반드시 4바이트여야 함
__type(value, __u32);
__uint(max_entries, 10000);
} my_array_map SEC(".maps");
[Syscall commands]
BPF_MAP_LOOKUP_ELEM
BPF_MAP_UPDATE_ELEM
BPF_MAP_GET_NEXT_KEY
BPF_MAP_LOOKUP_BATCH
[Helper functions]
bpf_for_each_map_elem
bpf_map_delete_elem
bpf_map_lookup_elem
bpf_map_update_elem
ARRAY의 특성상 인덱스를 통해 접근하기 때문에 key 크기는 반드시 4바이트여야 합니다. 만약 4바이트가 넘게 되면,
struct {
__uint(type, BPF_MAP_TYPE_ARRAY);
__type(key, __u64);
__type(value, __u32);
__uint(max_entries, 10000);
} my_array_map SEC(".maps");
컴파일 타임에는 오류가 없지만 런타임에 eBPF 코드를 적재 시 "map my_array_map: map create: invalid argument"와 같은 오류가 발생합니다. 반면, HASH MAP의 경우에는 지정한 key 값을 hashing하므로 key 크기의 (현실적인) 제약은 없습니다.
어렵게 생각하지 마시고, 대체로 전통적인 자료구조에서의 HASH/ARRAY에 기반한 차이점을 그대로 반영해 이해하시면 됩니다. ^^
이런 식으로, 기본은 BPF_MAP_TYPE_HASH, BPF_MAP_TYPE_ARRAY이고, 이에 대해 각각 PER CPU로 관리하는 BPF_MAP_TYPE_PERCPU_HASH, BPF_MAP_TYPE_PERCPU_ARRAY 유형도 있습니다.
BPF_MAP_TYPE_ARRAY and BPF_MAP_TYPE_PERCPU_ARRAY
; https://docs.kernel.org/bpf/map_array.html#bpf-map-type-array-and-bpf-map-type-percpu-array
또한 맵의 용량이 부족할 때 최근에 가장 적게 사용된 요소를 삭제하는 BPF_MAP_TYPE_LRU_HASH 유형과 그것의 PER CPU 버전인 BPF_MAP_TYPE_LRU_PERCPU_HASH 유형도 있고, key가 아예 없는 BPF_MAP_TYPE_QUEUE, BPF_MAP_TYPE_STACK 유형이 있다는 정도만 알아두면 되겠습니다.
여기서 잠깐 LRU map에 대한 설명을 해볼까요? ^^
eBPF map의 경우 max_entries 값이 동적으로 늘어날 수 없고, 항상 상수로 최댓값을 지정해야 합니다. 이런 제약 때문에 크기를 처음부터 크게 잡게 되면 메모리 낭비가 발생할 수 있고, 적게 잡으면 정확도가 떨어질 수 있습니다.
따라서 LRU hash를 적용하면 그나마 최근 데이터에 한해서는 정확성을 유지하면서 메모리 사용량을 줄일 수 있어 적절한 선택이 될 수 있는 상황이 있을 텐데요, 그런데 LRU가 생각보다 정확도를 상당히 떨어뜨릴 수 있다는 점에 유의해야 합니다.
테스트를 위해 다음과 같이 2개의 map을 정의하고,
#define MAX_ELEM_ENTRIES (1003)
struct {
__uint(type, BPF_MAP_TYPE_HASH);
__type(key, __u32);
__type(value, __u32);
__uint(max_entries, MAX_ELEM_ENTRIES);
} my_u32_elem_map SEC(".maps");
struct {
__uint(type, BPF_MAP_TYPE_LRU_HASH);
__type(key, __u32);
__type(value, __u32);
__uint(max_entries, MAX_ELEM_ENTRIES);
} my_u32_lru_elem_map SEC(".maps");
eBPF에서 해당 map에 각각 MAX_ELEM_ENTRIES + 1개의 요소를 밀어 넣으면,
// ... eBPF 함수 ...
{
for (int i = 1; i <= MAX_ELEM_ENTRIES + 1; i ++)
{
__u32 key = i;
__u32 value = i * 10 + i;
bpf_map_update_elem(&my_u32_elem_map, &key, &value, BPF_ANY);
bpf_map_update_elem(&my_u32_lru_elem_map, &key, &value, BPF_ANY);
}
}
BPF_MAP_TYPE_HASH map의 경우에는 1003번째 요소를 추가한 이후 max에 도달했기 때문에 이후 1004번째 요소부터는 추가되지 않습니다. 즉, my_u32_elem_map에는 key == 1004인 요소가 없는 것입니다.
반면 BPF_MAP_TYPE_LRU_HASH map은 key == 1004인 요소가 추가되고 기존에 있는 요소 중에서 알고리즘에 의해 LRU로 판단된 요소가 삭제됩니다. 그런데 또 다른 차이점이 있다면, lru map의 경우 추가된 요소들이 max 만큼 채워지는 경우가 거의 없다는 점입니다. 즉, 위와 같이 꽉 차게 추가를 해도 어떤 경우에는 343개, 어떤 경우에는 400개와 같은 식으로 (max가 1003개로 지정된) map에 데이터가 부분적으로만 보관돼 있습니다. 단적으로, max_entries == 10 정도로 낮게 설정하면 항목이 언제나/거의 1개만 있는 정도로 유지됩니다. 대충 어떤 느낌인지 아시겠죠? ^^
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]