Hou Tao <houtao@xxxxxxxxxxxxxxx> writes: > Hi, > > On 12/3/2024 9:42 AM, Alexei Starovoitov wrote: >> On Fri, Nov 29, 2024 at 4:18 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: >>> Hou Tao <houtao@xxxxxxxxxxxxxxx> writes: >>> >>>> From: Hou Tao <houtao1@xxxxxxxxxx> >>>> >>>> After switching from kmalloc() to the bpf memory allocator, there will be >>>> no blocking operation during the update of LPM trie. Therefore, change >>>> trie->lock from spinlock_t to raw_spinlock_t to make LPM trie usable in >>>> atomic context, even on RT kernels. >>>> >>>> The max value of prefixlen is 2048. Therefore, update or deletion >>>> operations will find the target after at most 2048 comparisons. >>>> Constructing a test case which updates an element after 2048 comparisons >>>> under a 8 CPU VM, and the average time and the maximal time for such >>>> update operation is about 210us and 900us. >>> That is... quite a long time? I'm not sure we have any guidance on what >>> the maximum acceptable time is (perhaps the RT folks can weigh in >>> here?), but stalling for almost a millisecond seems long. >>> >>> Especially doing this unconditionally seems a bit risky; this means that >>> even a networking program using the lpm map in the data path can stall >>> the system for that long, even if it would have been perfectly happy to >>> be preempted. >> I don't share this concern. >> 2048 comparisons is an extreme case. >> I'm sure there are a million other ways to stall bpf prog for that long. > > 2048 is indeed an extreme case. I would do some test to check how much > time is used for the normal cases with prefixlen=32 or prefixlen=128. That would be awesome, thanks! -Toke
