Hi, On 12/5/2024 5:47 PM, Toke Høiland-Jørgensen wrote: > 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! Sorry for the long delay. After apply patch set v3, the avg and max time for prefixlen = 32 and prefix =128 is about 2.3/4, 7.7/11 us respectively. > > -Toke > > > .
