On Mon, 24 Feb 2025 at 17:00, Stanislav Fomichev <stfomichev@xxxxxxxxx> wrote: > > On 02/24, Magnus Karlsson wrote: > > On Sat, 22 Feb 2025 at 10:18, Wang Liang <wangliang74@xxxxxxxxxx> wrote: > > > > > > When the cq reservation is failed, the error code is not set which is > > > initialized to zero in __xsk_generic_xmit(). That means the packet is not > > > send successfully but sendto() return ok. > > > > > > Set the error code and make xskq_prod_reserve_addr()/xskq_prod_reserve() > > > return values more meaningful when the queue is full. > > > > Hi Wang, > > > > I agree that this would have been a really good idea if it was > > implemented from day one, but now I do not dare to change this since > > it would be changing the uapi. Let us say you have the following quite > > common code snippet for sending a packet with AF_XDP in skb mode: > > > > err = sendmsg(); > > if (err && err != -EAGAIN && err != -EBUSY) > > goto die_due_to_error; > > continue with code > > > > This code would with your change go and die suddenly when the > > completion ring is full instead of working. Maybe there is a piece of > > code that cleans the completion ring after these lines of code and > > next time sendmsg() is called, the packet will get sent, so the > > application used to work. > > > > So I say: let us not do this. But if anyone has another opinion, please share. > > Can we return -EBUSY from this 'if (xsk_cq_reserve_addr_locked())' case as > well? That is a good idea! Though I would return -EAGAIN. When -EBUSY is returned, the buffer was consumed but not sent. But -EAGAIN means that the user just has to perform then sendmsg() again and that is exactly what the user has to do here too.