<div dir="auto">Dpdk doesn't yet support these negative offsets. <div dir="auto">But it is not worth doing until upstream libpcap is fixed.</div><div dir="auto">Right now, libpcap hard codes knowledge about the destination being a live linux capture into pcap_ compile. Filed a bug on that several years ago but no real fix came. Maybe time to send AI into libpcap</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Mar 18, 2026, 5:54 AM Morten Brørup <<a href="mailto:mb@smartsharesystems.com">mb@smartsharesystems.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> > +static void<br>
> > +emit_ld_mbuf(struct a64_jit_ctx *ctx, uint32_t op, uint8_t tmp1,<br>
> uint8_t tmp2,<br>
> > +   uint8_t src, uint32_t imm)<br>
> <br>
> Handling immediate as unsigned is questionable, especially in the<br>
> BPF_IND case<br>
> it may produce incorrect results.<br>
<br>
In Classic BPF (cBPF), when the immediate "k" is negative (when cast to signed integer), it is used for getting packet metadata (e.g. SKF_AD_VLAN_TAG gets the VLAN ID); otherwise it is considered unsigned.<br>
<br>
> <br>
> To make things worse, `__rte_pktmbuf_read` is also buggy when passed<br>
> very large<br>
> lengths (again, technically not ARM eBPF fault).<br>
<br>
Are you referring to the potential integer wraparound in the off+len > rte_pktmbuf_pkt_len(m) comparison?<br>
[BZ1724]<br>
Or some other bug in __rte_pktmbuf_read()?<br>
<br>
[BZ1724]: <a href="https://bugs.dpdk.org/show_bug.cgi?id=1724" rel="noreferrer noreferrer" target="_blank">https://bugs.dpdk.org/show_bug.cgi?id=1724</a><br>
<br>
> <br>
> > +{<br>
> > +   uint8_t r0 = ebpf_to_a64_reg(ctx, EBPF_REG_0);<br>
> > +   uint8_t r6 = ebpf_to_a64_reg(ctx, EBPF_REG_6);<br>
> > +   uint32_t mode = BPF_MODE(op);<br>
> > +   uint32_t opsz = BPF_SIZE(op);<br>
> > +   uint32_t sz = bpf_size(opsz);<br>
> > +   int16_t jump_to_epilogue;<br>
> > +<br>
> > +   /* r0 = mbuf (R6) */<br>
> > +   emit_mov_64(ctx, A64_R(0), r6);<br>
> > +<br>
> > +   /* r1 = off: for ABS use imm, for IND use src + imm */<br>
> > +   if (mode == BPF_ABS) {<br>
> > +           emit_mov_imm(ctx, 1, A64_R(1), imm);<br>
> > +   } else {<br>
> > +           emit_mov_imm(ctx, 1, tmp2, imm);<br>
> > +           emit_add(ctx, 1, tmp2, src);<br>
> > +           emit_mov_64(ctx, A64_R(1), tmp2);<br>
> > +   }<br>
> > +<br>
> > +   /* r2 = len */<br>
> > +   emit_mov_imm(ctx, 1, A64_R(2), sz);<br>
> > +<br>
> > +   /* r3 = buf (SP) */<br>
> > +   emit_mov_64(ctx, A64_R(3), A64_SP);<br>
> > +<br>
> > +   /* call __rte_pktmbuf_read */<br>
> > +   emit_call(ctx, tmp1, __rte_pktmbuf_read);<br>
> > +   /* check return value of __rte_pktmbuf_read */<br>
> > +   emit_cbnz(ctx, 1, A64_R(0), 3);<br>
> > +   emit_mov_imm(ctx, 1, r0, 0);<br>
> > +   jump_to_epilogue = (ctx->program_start + ctx->program_sz) - ctx-<br>
> >idx;<br>
> > +   emit_b(ctx, jump_to_epilogue);<br>
> <br>
> Could we call emit_return_zero_if_src_zero here instead?<br>
> <br>
> > +<br>
> > +   /* r0 points to the data, load 1/2/4 bytes */<br>
> > +   emit_ldr(ctx, opsz, A64_R(0), A64_R(0), A64_ZR);<br>
> > +   if (sz != sizeof(uint8_t))<br>
> > +           emit_be(ctx, A64_R(0), sz * CHAR_BIT);<br>
> > +   emit_mov_64(ctx, r0, A64_R(0));<br>
> > +}<br>
> > +<br>
> <br>
> I would also pass final verdict on ARM code to ARM folks. To my<br>
> untrained eye<br>
> it looks correct apart from the signed immediate issue. Optimizations<br>
> are<br>
> possible, but since we're only implementing slow path for now maybe not<br>
> worth<br>
> the effort.<br>
</blockquote></div>