On 2025-08-12 16:25:58, Chris Arges wrote: > On 2025-08-12 20:19:30, Dragos Tatulea wrote: > > On Tue, Aug 12, 2025 at 11:55:39AM -0700, Jesse Brandeburg wrote: > > > On 8/12/25 8:44 AM, 'Dragos Tatulea' via kernel-team wrote: > > > > > > > diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c > > > > index 482d284a1553..484216c7454d 100644 > > > > --- a/kernel/bpf/devmap.c > > > > +++ b/kernel/bpf/devmap.c > > > > @@ -408,8 +408,10 @@ static void bq_xmit_all(struct xdp_dev_bulk_queue *bq, u32 flags) > > > > /* If not all frames have been transmitted, it is our > > > > * responsibility to free them > > > > */ > > > > + xdp_set_return_frame_no_direct(); > > > > for (i = sent; unlikely(i < to_send); i++) > > > > xdp_return_frame_rx_napi(bq->q[i]); > > > > + xdp_clear_return_frame_no_direct(); > > > > > > Why can't this instead just be xdp_return_frame(bq->q[i]); with no > > > "no_direct" fussing? > > > > > > Wouldn't this be the safest way for this function to call frame completion? > > > It seems like presuming the calling context is napi is wrong? > > > > > It would be better indeed. Thanks for removing my horse glasses! > > > > Once Chris verifies that this works for him I can prepare a fix patch. > > > Working on that now, I'm testing a kernel with the following change: > > --- > > diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c > index 3aa002a47..ef86d9e06 100644 > --- a/kernel/bpf/devmap.c > +++ b/kernel/bpf/devmap.c > @@ -409,7 +409,7 @@ static void bq_xmit_all(struct xdp_dev_bulk_queue *bq, u32 flags) > * responsibility to free them > */ > for (i = sent; unlikely(i < to_send); i++) > - xdp_return_frame_rx_napi(bq->q[i]); > + xdp_return_frame(bq->q[i]); > > out: > bq->count = 0; This patch resolves the issue I was seeing and I am no longer able to reproduce the issue. I tested for about 2 hours, when the reproducer usually takes about 1-2 minutes. --chris
