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

[Gal Pressman <gal@nvidia.com>]

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 :\.