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] [thread-next>] [day] [month] [year] [list]
Message-ID: <ce36ce0e-ad16-4950-b601-ae1a555f2cfb@redhat.com>
Date: Tue, 6 May 2025 11:53:06 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Parvathi Pudi <parvathi@...thit.com>, danishanwar@...com,
 rogerq@...nel.org, andrew+netdev@...n.ch, davem@...emloft.net,
 edumazet@...gle.com, kuba@...nel.org, robh@...nel.org, krzk+dt@...nel.org,
 conor+dt@...nel.org, nm@...com, ssantosh@...nel.org, tony@...mide.com,
 richardcochran@...il.com, glaroque@...libre.com, schnelle@...ux.ibm.com,
 m-karicheri2@...com, s.hauer@...gutronix.de, rdunlap@...radead.org,
 diogo.ivo@...mens.com, basharath@...thit.com, horms@...nel.org,
 jacob.e.keller@...el.com, m-malladi@...com, javier.carrasco.cruz@...il.com,
 afd@...com, s-anna@...com
Cc: linux-arm-kernel@...ts.infradead.org, netdev@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, pratheesh@...com,
 prajith@...com, vigneshr@...com, praneeth@...com, srk@...com, rogerq@...com,
 krishna@...thit.com, pmohan@...thit.com, mohan@...thit.com
Subject: Re: [PATCH net-next v7 04/11] net: ti: prueth: Adds link detection,
 RX and TX support.

On 5/3/25 3:11 PM, Parvathi Pudi wrote:
> +/**
> + * icssm_emac_rx_thread - EMAC Rx interrupt thread handler
> + * @irq: interrupt number
> + * @dev_id: pointer to net_device
> + *
> + * EMAC Rx Interrupt thread handler - function to process the rx frames in a
> + * irq thread function. There is only limited buffer at the ingress to
> + * queue the frames. As the frames are to be emptied as quickly as
> + * possible to avoid overflow, irq thread is necessary. Current implementation
> + * based on NAPI poll results in packet loss due to overflow at
> + * the ingress queues. Industrial use case requires loss free packet
> + * processing. Tests shows that with threaded irq based processing,
> + * no overflow happens when receiving at ~92Mbps for MTU sized frames and thus
> + * meet the requirement for industrial use case.

The above statement is highly suspicious. On an non idle system the
threaded irq can be delayed for an unbound amount of time. On an idle
system napi_poll should be invoked with a latency comparable - if not
less - to the threaded irq. Possibly you tripped on some H/W induced
latency to re-program the ISR?

In any case I think we need a better argumented statement to
intentionally avoid NAPI.

Cheers,

Paolo


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ