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
| ||
|
Message-ID: <20220412144906.40d935f2@kernel.org> Date: Tue, 12 Apr 2022 14:49:06 -0700 From: Jakub Kicinski <kuba@...nel.org> To: Ray Jui <ray.jui@...adcom.com> Cc: Michael Chan <michael.chan@...adcom.com>, "David S. Miller" <davem@...emloft.net>, Netdev <netdev@...r.kernel.org> Subject: Re: [RFC] Applicability of using 'txq_trans_update' during ring recovery On Tue, 12 Apr 2022 12:34:23 -0700 Ray Jui wrote: > Sure, that is the general error recovery case which is very different > from this specific recovery case we are discussing here. This specific > recovery is solely performed by driver (without resetting firmware and > chip) on a per NAPI ring set basis. While a specific NAPI ring set is > being recovered, traffic is still going with the rest of the NAPI ring > sets. Average recovery time is in the 1 - 2 ms range in this type of > recovery. > > Also as I already said, 'netif_carrier_off' is not an option given that > the RoCE/infiniband subsystem has a dependency on 'netif_carrier_status' > for many of their operations. > > Basically I'm looking for a solution that allows one to be able to: > 1) quieice traffic and perform recovery on a per NAPI ring set basis > 2) During recovery, it does not cause any drastic effect on RoCE > > 'txq_trans_update' may not be the most optimal solution, but it is a > solution that satisfies the two requirements above. If there are any > other option that is considered more optimal than 'txq_trans_update' and > can satisfy the two requirements, please let me know. The optimal solution would be to not have to reset your rings and pretend like nothing happened :/ If you can't reset the ring in time you'll have to live with the splat. End of story.
Powered by blists - more mailing lists