> -----Original Message-----
> From: Tariq Toukan <[email protected]>
> Sent: Tuesday, February 24, 2026 5:22 AM
> To: Haiyang Zhang <[email protected]>; linux-
> [email protected]; [email protected]; Andrew Lunn
> <[email protected]>; Jakub Kicinski <[email protected]>; Donald Hunter
> <[email protected]>; David S. Miller <[email protected]>; Eric
> Dumazet <[email protected]>; Paolo Abeni <[email protected]>; Simon
> Horman <[email protected]>; Jonathan Corbet <[email protected]>; Shuah Khan
> <[email protected]>; Kory Maincent (Dent Project)
> <[email protected]>; Gal Pressman <[email protected]>; Oleksij Rempel
> <[email protected]>; Vadim Fedorenko <[email protected]>;
> [email protected]; [email protected]
> Cc: Haiyang Zhang <[email protected]>; Paul Rosswurm
> <[email protected]>
> Subject: [EXTERNAL] Re: [PATCH net-next] net: ethtool: add
> COALESCE_RX_CQE_FRAMES/NSECS parameters
>
> [You don't often get email from [email protected]. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > +Rx CQE coalescing allows multiple received packets to be coalesced into
> a single
> > +Completion Queue Entry (CQE). ``ETHTOOL_A_COALESCE_RX_CQE_FRAMES``
> describes the
> > +maximum number of frames that can be coalesced into a CQE.
> > +``ETHTOOL_A_COALESCE_RX_CQE_NSECS`` describes max time in nanoseconds
> after the
> > +first packet arrival in a coalesced CQE to be sent.
> > +
>
> I am trying to understand how generic this feature/API is.
> Can you please elaborate on the feature you want to configure here?
It's the similar feature as MLX's "RX CQE compression", which merges
"multiple near-identical completions that share/match several fields."
I'm adding this kAPI for any drivers that support this feature.
You may find driver details in my previous submission:
[V2,net-next,1/2] net: mana: Add support for coalesced RX packets on CQE
https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/
> A single CQE to describe several packets?
Yes, up to 4 for our MANA driver.
> What is the price?
The price is the latency can increase a bit.
> What per-packet information/hw offloads do you lose
> in the process?
For example, the vlan_id is shared among up to 4 pkts.
But, the pkt len & hash are per-pkt.
struct mana_rxcomp_perpkt_info {
u32 pkt_len : 16;
u32 reserved1 : 16;
u32 reserved2;
u32 pkt_hash;
}; /* HW DATA */
/* Receive completion OOB */
struct mana_rxcomp_oob {
struct mana_cqe_header cqe_hdr;
u32 rx_vlan_id : 12;
u32 rx_vlantag_present : 1;
u32 rx_outer_iphdr_csum_succeed : 1;
u32 rx_outer_iphdr_csum_fail : 1;
u32 reserved1 : 1;
u32 rx_hashtype : 9;
u32 rx_iphdr_csum_succeed : 1;
u32 rx_iphdr_csum_fail : 1;
u32 rx_tcp_csum_succeed : 1;
u32 rx_tcp_csum_fail : 1;
u32 rx_udp_csum_succeed : 1;
u32 rx_udp_csum_fail : 1;
u32 reserved2 : 1;
struct mana_rxcomp_perpkt_info ppi[MANA_RXCOMP_OOB_NUM_PPI]; //
MANA_RXCOMP_OOB_NUM_PPI=4
u32 rx_wqe_offset;
}; /* HW DATA */
> For comparison, in mlx5 we have RX CQE compression, which can be applied
> on multiple near-identical completions that share/match several fields.
> Still, there is a per-packet mini-cqe with distinctive per-packet fields
> like csum.
As said above, we have similar "per-packet mini-cqe":
struct mana_rxcomp_perpkt_info, which has pkt len & hash.
Thanks,
- Haiyang
