Subject: Re: [PATCH v4 net-next 1/5] ethtool: Add support for configuring tx_push_buf_len

From: Gal Pressman <[email-masked]>
Date: Thu, 9 Mar 2023 19:15:43 +0200

On 09/03/2023 15:13, Shay Agroskin wrote:
> +``ETHTOOL_A_RINGS_TX_PUSH_BUF_LEN`` specifies the maximum number of bytes of a
> +transmitted packet a driver can push directly to the underlying device
> +('push' mode). Pushing some of the payload bytes to the device has the
> +advantages of reducing latency for small packets by avoiding DMA mapping (same
> +as ``ETHTOOL_A_RINGS_TX_PUSH`` parameter) as well as allowing the underlying
> +device to process packet headers ahead of fetching its payload.
> +This can help the device to make fast actions based on the packet's headers.

I know Jakub prefers the new parameter, but the description of this
still sounds extremely similar to TX copybreak to me..
TX copybreak was traditionally used to copy packets to preallocated DMA
buffers, but this could be implemented as copying the packet to the
(preallocated) WQE's inline part. That usually means DMA memory, but
could also be device memory in this ENA LLQ case.

Are we drawing a line that TX copybreak is the threshold for DMA memory
and tx_push_buf_len is the threshold for device memory?
Are they mutually exclusive?

BTW, as I mentioned in v1, ENA doesn't advertise tx_push, which is a bit
strange given the fact that it now adds tx_push_buf_len support.