Zbr's days.

About :: TODO :: Blog :: RSS :: Old blog :: Projects :: GIT :: Gallery :: Notes

Mon, 24 Jul 2006

Network tree allocator.


Here is brief description of my efforts directed to full sending and receiving zero-copy support for netchannels.

Main idea is to replace slab allocator with netchannel's own, so that all allocator's pool could be mapped from userspace. In that case all skbs allocated from that pool automagically become visible to userspace applications without any single memory copy.
If that allocator will be created in a right way, it will also solve problem with memory fragmentation and more generic problem with power of 2 allocators - big alignment overhead.

I read some papers about memory allocation in MMU-less systems (like uClinux kernels), and found that it is quite common problem, and there are several non-power-of-2 allocators, which might be used with my approach.
But it is not interesting way, I think, so I started to draw some initial design notes about how netchannel allocator will look like.

It will have several pools of contiguous memory chunks, at least pool of page sized chunks (which will be used for usual alocations) and one contiguos region (probably allocated at a boot time) for jumbo frames (and actually management of that pool can be used for MMU-less allocators).
Each contiguous region will have some control block attached which will store pointers to free and used sub-blocks inside the region (I plan to use chunks aligned to predefined constant value, for example 32 bytes). When some block is freed inside the contiguous region, it will be concatenated with neighbour free blocks thus reducing memory fragmentation. Pointers to the free regions will be placed into the AVL-tree as the fastest search/insert/delete tree among existing binary trees (all even worst times never exceed O(log2(N)), where N is number of nodes).
If size of the free area inside contiguous region differs after allocation/freeing, pointer will be moved inside the tree, thus rebalancing it.

Each AVL node is designed to be very memory efficient, so it only uses 12 bytes on any arch. This limits maximum number of nodes to 64k-1, if each node corresponds to value multiple of 32 bytes, this allows maximum 2mb contiguous block allocation, which is more than enough right now. If that limit is going to be changed, one just need to change definition of one type (avl_t). Current proof-of-concept userspace model implementation of the tree works with 16bit type to store each node's value parameter.

/devel/networking/nta :: Link / Comments ()