Thank you for your reply. > Sorry for being unclear. I meant, does resuming the system take longer > now? (initcall_debug might give a clue.) I've tested the S3 suspend/resume with the initcall_debug kernel command option, and it shows no clear difference between having or not having the ice_init_rdma in ice_resume: Without ice_init_rdma: ``` [ 104.241129] ice 0000:86:00.0: PM: pci_pm_resume+0x0/0x110 returned 0 after 9415 usecs [ 104.241206] ice 0000:86:00.1: PM: pci_pm_resume+0x0/0x110 returned 0 after 9443 usecs ``` With ice_init_rdma: ``` [ 122.749022] ice 0000:86:00.1: PM: pci_pm_resume+0x0/0x110 returned 0 after 9485 usecs [ 122.749068] ice 0000:86:00.0: PM: pci_pm_resume+0x0/0x110 returned 0 after 9532 usecs ```
> And ice_init_rdma should be moved to ice_rebuild (replace ice_plug_aux_dev) We can defer the ice_init_rdma to the later service task by adopting this. > You should call ice_deinit_rdma in ice_prepare_for_reset (replace > ice_unplug_aux_dev), It seems like we must call ice_deinit_rdma in ice_suspend. If we call it in the later service task, it will: 1. break some existing code setup by ice_resume 2. Since the PCI-X vector table is flushed at the end of ice_suspend, we have no way to release PCI-X vectors for rdma if we had allocated it dynamically The second point is important since we didn't release the PCI-X vectors for rdma (if we allocated it dynamically) in the original ice_suspend, and it's somewhat like a leak in the original code. Best regards, Ricky. On Thu, 30 May 2024 at 04:19, Paul Menzel <pmen...@molgen.mpg.de> wrote: > > Dear En-Wei, > > > Thank you for responding so quickly. > > Am 29.05.24 um 05:17 schrieb En-Wei WU: > > […] > > >> What effect does this have on resume time? > > > > When we call ice_init_rdma() at resume time, it will allocate entries > > at pf->irq_tracker.entries and update pf->msix_entries for later use > > (request_irq) by irdma. > > Sorry for being unclear. I meant, does resuming the system take longer > now? (initcall_debug might give a clue.) > > > Kind regards, > > Paul