netdev - Re: [net-next PATCH v2 3/9] netdev-genl: spec: Extend netdev netlink spec in YAML for NAPI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d4957350-bdca-4290-819a-aa00434aa814@intel.com>
Date: Wed, 23 Aug 2023 17:46:20 -0700
From: "Nambiar, Amritha" <amritha.nambiar@...el.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: <netdev@...r.kernel.org>, <davem@...emloft.net>,
	<sridhar.samudrala@...el.com>
Subject: Re: [net-next PATCH v2 3/9] netdev-genl: spec: Extend netdev netlink
 spec in YAML for NAPI

On 8/22/2023 5:39 PM, Jakub Kicinski wrote:
> On Mon, 21 Aug 2023 16:25:25 -0700 Amritha Nambiar wrote:
>> +      -
>> +        name: rx-queues
>> +        doc: list of rx queues associated with a napi
>> +        type: u32
>> +        multi-attr: true
>> +      -
>> +        name: tx-queues
>> +        doc: list of tx queues associated with a napi
>> +        type: u32
>> +        multi-attr: true
> 
> Queues should be separate objects, with NAPI ID as their attr.
> That's much simpler - since the relation is 1:n it's easier
> to store it on the side of the "1".
> 

For the "napi-get" command to generate an output as below:

{'napi-id': 385, 'ifindex': 12, 'irq': 291, 'pid': 3614, 'rx-queues': 
[0,1,2], 'tx-queues': [0,1,2]},

wouldn't the napi attribute-set need an attribute for the list of queue 
IDs for the display ?

Internally, I can change the implementation in patch 1/9 to what we 
discussed previously (remove maintaining the napi_rxq/txq_list within 
napi, make use of the NAPI pointer in queue struct that stores the state 
on the side of "1" for 1:n. This would although change the complexity to 
#napis * (#max_rx + #max_tx). Currently it is #napis * 
(len(napi_rxq_list) + len(napi_txq_list)).

But, to display the list of queue IDs for the NAPI with napi-get, 
wouldn't the YAML still need such an attribute within the NAPI object? 
Or are you suggesting that the "napi-get" command does not need to show 
the queue-list associated with NAPI and a "queue-get" command which 
shows the NAPI_ID associated with the queue would suffice ?

Can we have both: "queue-get" (queue object with with NAPI-ID attr) and 
"napi-get" (NAPI object with "set of queue IDs" as an attribute), 
something like below (rx-queue is the queue object. rx-queues is the 
list attr within the NAPI object):

     name: rx-queue
     attributes:
       -
         name: qid
         doc: queue ID
         type: u32
       -
         name: ifindex
         doc: netdev ifindex
         type: u32
         checks:
           min: 1
       -
         name: napi-id
         doc: napi id
         type: u32

     name: napi
     attributes:
       -
         name: ifindex
         doc: netdev ifindex
         type: u32
         checks:
           min: 1
       -
         name: napi-id
         doc: napi id
         type: u32
       -
         name: rx-queues
         doc: list of rx queue ids associated with a napi
         type: u32
         multi-attr: true
       -
         name: tx-queues
         doc: list of tx queue ids associated with a napi
         type: u32
         multi-attr: true