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

Message

Subbaraya Sundeep Feb. 22, 2022, 6:39 p.m. UTC

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.

Patch 1 adds support setting/getting cqe-size via
ethtool -G and ethtool -g.

Patch 2 includes octeontx2 driver changes to use
completion queue event size set from ethtool -G.

v2 changes:
	As per Jakub suggestions renamed ce size to cqe size
	Added documentation for cqe size

Thanks,
Sundeep

Subbaraya Sundeep (2):
  ethtool: add support to set/get completion queue event size
  octeontx2-pf: Vary completion queue event size

 Documentation/networking/ethtool-netlink.rst          | 11 +++++++++++
 .../net/ethernet/marvell/octeontx2/nic/otx2_common.c  |  4 ++--
 .../net/ethernet/marvell/octeontx2/nic/otx2_common.h  |  1 +
 .../net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c | 17 ++++++++++++++---
 drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c  |  2 ++
 drivers/net/ethernet/marvell/octeontx2/nic/otx2_vf.c  |  2 ++
 include/linux/ethtool.h                               |  4 ++++
 include/uapi/linux/ethtool_netlink.h                  |  1 +
 net/ethtool/netlink.h                                 |  2 +-
 net/ethtool/rings.c                                   | 19 +++++++++++++++++--
 10 files changed, 55 insertions(+), 8 deletions(-)

Comments

[e-mail] Feb. 24, 2022, 5:20 a.m. UTC | #1

Hello:

This series was applied to netdev/net-next.git (master)
by Jakub Kicinski <[e-mail]>:

On Wed, 23 Feb 2022 00:09:11 +0530 you 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.
> 
> [...]

Here is the summary with links:
  - [v2,net-next,1/2] ethtool: add support to set/get completion queue event size
    https://git.kernel.org/netdev/net-next/c/1241e329ce2e
  - [v2,net-next,2/2] octeontx2-pf: Vary completion queue event size
    https://git.kernel.org/netdev/net-next/c/68258596cbc9

You are awesome, thank you!

Gal Pressman Oct. 24, 2022, 1:39 p.m. UTC | #2

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