Re: [PATCH net-next v9 05/12] virtio_net: Query and set flow filter caps

[Dan Jurgens <danielj@nvidia.com>]

On 11/11/25 10:18 PM, Jason Wang wrote:
> On Wed, Nov 12, 2025 at 11:02 AM Dan Jurgens <danielj@nvidia.com> wrote:
>>
>> On 11/11/25 7:00 PM, Jason Wang wrote:
>>> On Tue, Nov 11, 2025 at 6:42 PM Paolo Abeni <pabeni@redhat.com> wrote:
>>>>
>>>> On 11/7/25 5:15 AM, Daniel Jurgens wrote:
>>>>> @@ -7121,6 +7301,15 @@ static int virtnet_probe(struct virtio_device *vdev)
>>>>>       }
>>>>>       vi->guest_offloads_capable = vi->guest_offloads;
>>>>>
>>>>> +     /* Initialize flow filters. Not supported is an acceptable and common
>>>>> +      * return code
>>>>> +      */
>>>>> +     err = virtnet_ff_init(&vi->ff, vi->vdev);
>>>>> +     if (err && err != -EOPNOTSUPP) {
>>>>> +             rtnl_unlock();
>>>>> +             goto free_unregister_netdev;
>>>>
>>>> I'm sorry for not noticing the following earlier, but it looks like that
>>>> the code could error out on ENOMEM even if the feature is not really
>>>> supported,  when `cap_id_list` allocation fails, which in turn looks a
>>>> bit bad, as the allocated chunk is not that small (32K if I read
>>>> correctly).
>>>>
>>>> @Jason, @Micheal: WDYT?
>>>
>>> I agree. I think virtnet_ff_init() should be only called when the
>>> feature is negotiated.
>>>
>>> Thanks
>>>
>>
>> Are you suggesting we wait to call init until get/set_rxnfc is called? I
>> don't like that idea. Probe is the right time to do feature discovery.
> 
> Nope I meant it might be better:
> 
> 1) embed virtio_admin_cmd_query_cap_id_result in virtnet_info to avoid
> dynamic allocation
> 
> Or
> 
> 2) at least check if there's an adminq before trying to call virtnet_ff_init()?

I could do a check like this:

        if (!vdev->config->admin_cmd_exec)
                return -EOPNOTSUPP;

Or would you prefer it added to the virtio_admin_command api?

bool virtio_admin_supported(struct virtio_device *vdev);

> 
> Thanks
> 
>>
>>
>>>>
>>>> /P
>>>>
>>>
>>
>