dhcp function is a slow path and has quite a bit of complexity that
is not appropriate for datapath. Normal dhcp is handled by user space dhclient.
So I think it would be better to do the same in your case.
As an orthogonal discussion it would be useful indeed
to have push()/pop() like logic in bpf maps, so it can be used
as a queue/stack.


On Fri, Jan 20, 2017 at 6:04 AM, Mauricio Vasquez via iovisor-dev
<iovisor-dev@lists.iovisor.org> wrote:
> Hello,
>
> We are having some issues for handling the address pool of a DHCP server
> implemented with eBPF.
>
> We tried to implement it using a map containing all the available addresses,
> this map is filled at the beginning and then addresses are taken (and also
> released), however we cannot find a way to get an arbitrary element from a
> map in eBPF. (something like a pop() function)
>
> By suggestion of Brenden Blanco, we had a look at the LRU [1] map, we
> expected to find some function like "get_oldest_element()" but we cannot
> find anything similar.
>
> We decided to implement it in a different way,  the pool is handled by a map
> of type array where all the addresses are saved, each of them has a flag
> that indicates whether it is available or not. Then, in order to get an
> available address it is necessary to perform a loop through the map (values
> are saved using integer keys) until an available entry is found.
>
> With this approach a lot of instructions are wasted just to perform the
> lookup of an available address, this limits the size of the pool. Hence, we
> think having a kind of "pop()" function is necessary to handle "maps" of
> free elements.
>
>
> 1. Would it make sense to have a map of kind "set" that only implements the
> push() and pop() methods?
>
> 2. Does it make sense to have a get_oldest_element() in the LRU map?
>
>
> Thanks in advance,
>
> Mauricio V.
>
> [1]
> https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=29ba732acbeece1e34c68483d1ec1f3720fa1bb3
>
> _______________________________________________
> iovisor-dev mailing list
> iovisor-dev@lists.iovisor.org
> https://lists.iovisor.org/mailman/listinfo/iovisor-dev
_______________________________________________
iovisor-dev mailing list
iovisor-dev@lists.iovisor.org
https://lists.iovisor.org/mailman/listinfo/iovisor-dev

Reply via email to