On 2024-10-21 07:40, Paolo Abeni wrote:
> On 10/16/24 20:52, David Wei wrote:
>> @@ -540,6 +562,34 @@ static const struct memory_provider_ops io_uring_pp_zc_ops = {
>> .scrub = io_pp_zc_scrub,
>> };
>>
>> +static void io_napi_refill(void *data)
>> +{
>> + struct io_zc_refill_data *rd = data;
>> + struct io_zcrx_ifq *ifq = rd->ifq;
>> + netmem_ref netmem;
>> +
>> + if (WARN_ON_ONCE(!ifq->pp))
>> + return;
>> +
>> + netmem = page_pool_alloc_netmem(ifq->pp, GFP_ATOMIC | __GFP_NOWARN);
>> + if (!netmem)
>> + return;
>> + if (WARN_ON_ONCE(!netmem_is_net_iov(netmem)))
>> + return;
>> +
>> + rd->niov = netmem_to_net_iov(netmem);
>> +}
>> +
>> +static struct net_iov *io_zc_get_buf_task_safe(struct io_zcrx_ifq *ifq)
>> +{
>> + struct io_zc_refill_data rd = {
>> + .ifq = ifq,
>> + };
>> +
>> + napi_execute(ifq->napi_id, io_napi_refill, &rd);
>
> Under UDP flood the above has unbounded/unlimited execution time, unless
> you set NAPI_STATE_PREFER_BUSY_POLL. Is the allocation schema here
> somehow preventing such unlimited wait?
Hi Paolo. Do you mean that under UDP flood, napi_execute() will have
unbounded execution time because napi_state_start_busy_polling() and
need_resched() will always return false? My understanding is that
need_resched() will eventually kick the caller task out of
napi_execute().
>
> Thanks,
>
> Paolo
>
