netdev - Re: [PATCH net-next v3 2/2] net/mlx5: Avoid copying payload to the skb's linear part

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CANn89iJnUDCfjeDg91jomVmiFSTDSoSc-mPiSS+opTEB-7+A_g@mail.gmail.com>
Date: Wed, 27 Aug 2025 00:50:29 -0700
From: Eric Dumazet <edumazet@...gle.com>
To: Dragos Tatulea <dtatulea@...dia.com>
Cc: Christoph Paasch <cpaasch@...nai.com>, Saeed Mahameed <saeedm@...dia.com>, 
	Leon Romanovsky <leon@...nel.org>, Tariq Toukan <tariqt@...dia.com>, Mark Bloch <mbloch@...dia.com>, 
	Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Alexander Lobakin <aleksander.lobakin@...el.com>, Gal Pressman <gal@...dia.com>, 
	linux-rdma@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v3 2/2] net/mlx5: Avoid copying payload to the
 skb's linear part

On Wed, Aug 27, 2025 at 12:08 AM Dragos Tatulea <dtatulea@...dia.com> wrote:

> What are the advantages of using eth_get_headlen() besides the fact that
> it is more exhaustive? It seems quite expensive compared to reading some
> bits in the CQE and doing a few comparisons. Even if this cost is amortized
> by the benefits in the good cases, in the non-aggregation cases it seems
> more costly. What am I missing here?

Let's not reinvent the wheel, and add more potential bugs. Please ?

Why spending hours and ending with some ugly/wrong things like 'TCP
headers have at least 12 bytes of options'

  } else if (l4_type & (CQE_L4_HDR_TYPE_TCP_NO_ACK |
+                             CQE_L4_HDR_TYPE_TCP_ACK_NO_DATA |
+                             CQE_L4_HDR_TYPE_TCP_ACK_AND_DATA)) {
+               /* ACK_NO_ACK | ACK_NO_DATA | ACK_AND_DATA == 0x7, but
+                * the previous condition checks for _UDP which is 0x2.
+                *
+                * As we know that l4_type != 0x2, we can simply check
+                * if any of the bits of 0x7 is set.
+                */
+               hdr_len += sizeof(struct tcphdr) + TCPOLEN_TSTAMP_ALIGNED;

Either do not pull anything and let upper stacks pull one header at a time,
or call the generic helper to make a single memcpy()

Real costs are the cache line misses, analyzing the 'CQE' will not help at all.

Really vendors need to stop adding useless stuff in their receive descriptors,
there is no way they can cover all encapsulations in modern networking.

I find it very annoying that Mellanox in 2025 still doed the overpull
thing in mlx5, considering
I fixed mlx4 driver in 2014.

This is the major and well known issue.