Re: [PATCH v2 1/5] iommu/vt-d: Separate page request queue from SVM

[Joel Granados]

On Fri, Sep 20, 2024 at 09:54:34AM -0300, Jason Gunthorpe wrote:
> On Wed, Sep 18, 2024 at 07:17:32PM +0800, Baolu Lu wrote:
> > > more than that... for each IOMMU the current code allocates 16 pages
> > > and 1 hwirq. Those are unnecessary burdens in majority deployments
> > > which don't support/require I/O page faults.
> > 
> > Yeah! I only focused on the kernel binary size but ignored these system
> > resources consumed by IOPF. Then, perhaps
> 
> If you care about runtime overhead it should be delt with by
> dynamically allocating the memory and enabling it, not via kconfig
> 
> We can dynmaically add IRQS in some cases now for instance
> 
> Jason

Summary (Please correct if inaccurate):
1. Kevin Tian & Baolu Lu have proposed a kconfig guard
   (INTEL_IOMMU_IOPF) to avoid unnecessary resource allocation (of 16
   pages and 1 hwirq). It can be keep it until it becomes a burden.
2. Jason Gunthorp: runtime overhead should be handled by dynamically
   allocating memory and enabling it. Not via Kconfig.

There was no real consensus reached here. I'll leave IOMMU_IOPF guarded
under INTEL_IOMMU (no changes from V2), two reasons for this IMO:
1. The reasoning being that any system that has the resources for
   INTEL_IOMMU has them for IOMMU_IOPF.
2. If the IOPF resources are a burden, they should be solved by changing
   the way we allocate memory instead of hiding them behind a kconfig.

Quick Note: I am adding my new email to the thread so I get the responses
routed to the correct inbox.

Best

-- 

Joel Granados