netdev - RE: [Intel-wired-lan] [PATCH iwl-next v6 11/15] idpf: add TX splitq napi poll support

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: <MW4PR11MB5911B771926C5165331EA2FDBA4B9@MW4PR11MB5911.namprd11.prod.outlook.com>
Date: Tue, 30 May 2023 23:01:20 +0000
From: "Singh, Krishneil K" <krishneil.k.singh@...el.com>
To: "Linga, Pavan Kumar" <pavan.kumar.linga@...el.com>,
	"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>
CC: "willemb@...gle.com" <willemb@...gle.com>, "pabeni@...hat.com"
	<pabeni@...hat.com>, "leon@...nel.org" <leon@...nel.org>, "mst@...hat.com"
	<mst@...hat.com>, "simon.horman@...igine.com" <simon.horman@...igine.com>,
	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
	"stephen@...workplumber.org" <stephen@...workplumber.org>,
	"edumazet@...gle.com" <edumazet@...gle.com>, "Nguyen, Anthony L"
	<anthony.l.nguyen@...el.com>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "kuba@...nel.org" <kuba@...nel.org>, "Burra, Phani
 R" <phani.r.burra@...el.com>, "decot@...gle.com" <decot@...gle.com>,
	"davem@...emloft.net" <davem@...emloft.net>, "shannon.nelson@....com"
	<shannon.nelson@....com>
Subject: RE: [Intel-wired-lan] [PATCH iwl-next v6 11/15] idpf: add TX splitq
 napi poll support

> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@...osl.org> On Behalf Of
> Pavan Kumar Linga
> Sent: Monday, May 22, 2023 5:23 PM
> To: intel-wired-lan@...ts.osuosl.org
> Cc: willemb@...gle.com; pabeni@...hat.com; leon@...nel.org;
> mst@...hat.com; simon.horman@...igine.com; Brandeburg, Jesse
> <jesse.brandeburg@...el.com>; stephen@...workplumber.org;
> edumazet@...gle.com; Nguyen, Anthony L
> <anthony.l.nguyen@...el.com>; netdev@...r.kernel.org; kuba@...nel.org;
> Burra, Phani R <phani.r.burra@...el.com>; decot@...gle.com;
> davem@...emloft.net; shannon.nelson@....com
> Subject: [Intel-wired-lan] [PATCH iwl-next v6 11/15] idpf: add TX splitq napi
> poll support
> 
> From: Joshua Hay <joshua.a.hay@...el.com>
> 
> Add support to handle the interrupts for the TX completion queue and
> process the various completion types.
> 
> In the flow scheduling mode, the driver processes primarily buffer
> completions as well as descriptor completions occasionally. This mode
> supports out of order TX completions. To do so, HW generates one buffer
> completion per packet. Each of those completions contains the unique tag
> provided during the TX encoding which is used to locate the packet either
> on the TX buffer ring or in a hash table. The hash table is used to track
> TX buffer information so the descriptor(s) for a given packet can be
> reused while the driver is still waiting on the buffer completion(s).
> 
> Packets end up in the hash table in one of 2 ways: 1) a packet was
> stashed during descriptor completion cleaning, or 2) because an out of
> order buffer completion was processed. A descriptor completion arrives
> only every so often and is primarily used to guarantee the TX descriptor
> ring can be reused without having to wait on the individual buffer
> completions. E.g. a descriptor completion for N+16 guarantees HW read all
> of the descriptors for packets N through N+15, therefore all of the
> buffers for packets N through N+15 are stashed into the hash table and the
> descriptors can be reused for more TX packets. Similarly, a packet can be
> stashed in the hash table because an out an order buffer completion was
> processed. E.g. processing a buffer completion for packet N+3 implies that
> HW read all of the descriptors for packets N through N+3 and they can be
> reused. However, the HW did not do the DMA yet. The buffers for packets N
> through N+2 cannot be freed, so they are stashed in the hash table.
> In either case, the buffer completions will eventually be processed for
> all of the stashed packets, and all of the buffers will be cleaned from
> the hash table.
> 
> In queue based scheduling mode, the driver processes primarily descriptor
> completions and cleans the TX ring the conventional way.
> 
> Finally, the driver triggers a TX queue drain after sending the disable
> queues virtchnl message. When the HW completes the queue draining, it
> sends the driver a queue marker packet completion. The driver determines
> when all TX queues have been drained and proceeds with the disable flow.
> 
> With this, the driver can send TX packets and clean up the resources
> properly.
> 
> Signed-off-by: Joshua Hay <joshua.a.hay@...el.com>
> Co-developed-by: Alan Brady <alan.brady@...el.com>
> Signed-off-by: Alan Brady <alan.brady@...el.com>
> Co-developed-by: Madhu Chittim <madhu.chittim@...el.com>
> Signed-off-by: Madhu Chittim <madhu.chittim@...el.com>
> Co-developed-by: Phani Burra <phani.r.burra@...el.com>
> Signed-off-by: Phani Burra <phani.r.burra@...el.com>
> Co-developed-by: Pavan Kumar Linga <pavan.kumar.linga@...el.com>
> Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@...el.com>
> Reviewed-by: Sridhar Samudrala <sridhar.samudrala@...el.com>
> Reviewed-by: Willem de Bruijn <willemb@...gle.com>
> ---
>  drivers/net/ethernet/intel/idpf/idpf.h        |  11 +
>  .../net/ethernet/intel/idpf/idpf_lan_txrx.h   |  16 +
>  drivers/net/ethernet/intel/idpf/idpf_lib.c    |   2 +
>  drivers/net/ethernet/intel/idpf/idpf_txrx.c   | 795 +++++++++++++++++-
>  drivers/net/ethernet/intel/idpf/idpf_txrx.h   |  40 +-
>  .../net/ethernet/intel/idpf/idpf_virtchnl.c   |  52 +-
>  6 files changed, 911 insertions(+), 5 deletions(-)
> 

Tested-by: Krishneil Singh  <krishneil.k.singh@...el.com>