netdev - Re: [v2 net-next PATCH 0/2] Add ethtool support for completion queue event size

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] [day] [month] [year] [list]

Message-ID: <f89ea424-1dd5-f097-a79d-e69ff61f73ab@nvidia.com>
Date:   Mon, 24 Oct 2022 16:39:53 +0300
From:   Gal Pressman <gal@...dia.com>
To:     Subbaraya Sundeep <sbhatta@...vell.com>, davem@...emloft.net,
        kuba@...nel.org, netdev@...r.kernel.org, sundeep.lkml@...il.com
Cc:     hkelam@...vell.com, gakula@...vell.com, sgoutham@...vell.com
Subject: Re: [v2 net-next PATCH 0/2] Add ethtool support for completion queue
 event size

On 22/02/2022 20:39, Subbaraya Sundeep wrote:
> After a packet is sent or received by NIC then NIC posts
> a completion queue event which consists of transmission status
> (like send success or error) and received status(like
> pointers to packet fragments). These completion events may
> also use a ring similar to rx and tx rings. This patchset
> introduces cqe-size ethtool parameter to modify the size
> of the completion queue event if NIC hardware has that capability.
> A bigger completion queue event can have more receive buffer pointers
> inturn NIC can transfer a bigger frame from wire as long as
> hardware(MAC) receive frame size limit is not exceeded.

Hello,
I just came across this feature and found myself very confused.

The driver's CQE size is strictly tied to its CQE format, and is very
internal to the driver/device implementation.
Why do we expose this to the user? How do we expect him to make sense
out of these values?
What guidelines should be provided to customers who wish to set their
CQE size?

The reasoning here (controlling the number of buffer pointers) is
hardware specific, and is just one thing that might be affected by CQE size.
I feel like this api was designed backwards, instead of exposing the
number of scatter-gather elements per WQE, we exposed cryptic completion
size values which don't really mean anything :\.