netdev - [RFC] Applicability of using 'txq_trans

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-next>] [day] [month] [year] [list]

Date:   Tue, 12 Apr 2022 10:01:02 -0700
From:   Ray Jui <ray.jui@...adcom.com>
To:     "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org
Subject: [RFC] Applicability of using 'txq_trans_update' during ring recovery

Hi David/Jakub,

I'd like to run through you on the idea of invoking 'txq_trans_update'
to update the last TX timestamp in the scenario where we temporarily
stop the TX queue to do some recovery work. Is it considered an
acceptable approach to prevent false positive triggering of TX timeout
during the recovery process?

I know in general people use 'netif_carrier_off' during the process when
they reset/change the entire TX/RX ring set and/or other resources on
the Ethernet card. But in our particular case, we have another driver
running (i.e., RoCE) on top and setting 'netif_carrier_off' will cause a
significant side effect on the other driver (e.g., all RoCE QPs will be
terminated). In addition, for this special recovery work on our driver,
we are doing it on a per NAPI ring set basis while keeping the traffic
on other queues running. Using 'netif_carrier_off' will prevent traffic
running from all other queues that are not going through recovery.

Thanks,

Ray

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4194 bytes)