linux-kernel - Re: i40e: How the packets will be processed when status_error

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <bf9a3230-26b9-40f7-aff0-99c802fb7764@shopee.com>
Date: Tue, 13 May 2025 14:23:50 +0800
From: Haifeng Xu <haifeng.xu@...pee.com>
To: Jason Xing <kerneljasonxing@...il.com>
Cc: Tony Nguyen <anthony.l.nguyen@...el.com>,
 Jesse Brandeburg <jesse.brandeburg@...el.com>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 intel-wired-lan@...ts.osuosl.org, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: i40e: How the packets will be processed when status_error_len is
 0

On 2025/5/13 14:13, Jason Xing wrote:
> On Tue, May 13, 2025 at 12:08 PM Haifeng Xu <haifeng.xu@...pee.com> wrote:
>>
>> Hi all,
>>
>>         If the packets arrive at the rx and then raise soft irq to handle it, but in i40e_clean_rx_irq, status_error_len is 0 and return.
> 
> Directly "return"? What version of I40E are you looking at?

stable kenrel 5.15.162,

i40e_clean_rx_irq
...
	qword = le64_to_cpu(rx_desc->wb.qword1.status_error_len);
	...
	size = (qword & I40E_RXD_QW1_LENGTH_PBUF_MASK) >>
		       I40E_RXD_QW1_LENGTH_PBUF_SHIFT;
	if (!size)
		break;
...

if status_error_len is 0, the i40e_clean_rx_irq returns 0.
> 
>>         The data isn't fetchted from the rx buffer, so the how the packets arrive at the rx will be processed?
> 
> In i40e_clean_rx_irq(), packets are one by one constructed into the
> sk_buff and then passed to the stack by napi_gro_receive().
> 
> AFAIK, common drivers implement nearly the same scenario.
> 
> 
> Thanks,
> Jason
> 
> 
>>
>>         FYI, the every rx/tx queue has been bounded to one cpu(64 queues, 64 cpus).
>>
>> Thanks!
>>