Re: BPF unrolled loop doesn't work and its workaround


Yonghong Song
 

Hi, William,

Your analysis is correct. In this case, the error message could be improved.
In general, a message like this "back-edge from insn 240 to 219" indicates a loop (back-edge ...).

Compiler probably should give a warning if it is BPF backend to indicate there
are loops in the byte code. I will look into this.

Yonghong


On Tue, Apr 18, 2017 at 9:00 PM, William Tu via iovisor-dev <iovisor-dev@...> wrote:
Hi Mauricio,

Thanks! Yes, I think like you said the compiler couldn't unroll in
this case. Because we are passing memory address of i (&i) to a
function, the function might change the value of 'i', which might
change the number of loops. So compiler should disable unrolling.

Regards,
William

On Tue, Apr 18, 2017 at 6:22 PM, Mauricio Vasquez
<mauricio.vasquez@...> wrote:
> Hi William,
>
> On 04/18/2017 06:54 PM, William Tu via iovisor-dev wrote:
>>
>> Hi,
>>
>> I found that if the loop variable "int i" is used in the map lookup as
>> below:
>> #pragma clang loop unroll(full)
>>     for (i = 0; i < 8; ++i) {
>>         struct bpf_flow_keys *mask;
>>         mask = bpf_map_lookup_elem(&flow_mask, &i);
>>         if (!mask)
>>             break;
>>     }
>> Then the compiled BPF code does not unrolled the loop, causing errors:
>> "back-edge from insn 240 to 219"
>>
>> A workaround for that is to declare another variable "int j", then I
>> can pass the verifier.
>>
>> #pragma clang loop unroll(full)
>>     for (i = 0; i < 8; ++i) {
>>         int j = i;
>>         struct bpf_flow_keys *mask;
>>         mask = bpf_map_lookup_elem(&flow_mask, &j); // ---> use "j"
>>         if (!mask)
>>             break;
>>     }
>>
>> Does anyone hit similar issue?
>
>
> Yes, we hit exactly the same problem [1], at that time we thought it was
> because of the missing "const" qualifier in the bpf_map_* helpers [2],
> however we added it and the result was the same.
>
> Until now we don't know what is the cause of the problem, we continue to use
> that workaround.
>
> Mauricio V,
>
> [1]
> https://lists.iovisor.org/pipermail/iovisor-dev/2016-December/000560.html
> [2]
> https://lists.iovisor.org/pipermail/iovisor-dev/2016-December/000559.html
>>
>> Regards,
>> William
>> _______________________________________________
>> iovisor-dev mailing list
>> iovisor-dev@...
>> https://lists.iovisor.org/mailman/listinfo/iovisor-dev
>>
>
_______________________________________________
iovisor-dev mailing list
iovisor-dev@...
https://lists.iovisor.org/mailman/listinfo/iovisor-dev

Join {iovisor-dev@lists.iovisor.org to automatically receive all group messages.