From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Gunthorpe Subject: Re: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs Date: Tue, 4 May 2021 20:15:30 -0300 Message-ID: <20210504231530.GE1370958@nvidia.com> References: <20210422121020.GT1370958@nvidia.com> <20210423114944.GF1370958@nvidia.com> <20210426123817.GQ1370958@nvidia.com> <20210504084148.4f61d0b5@jacob-builder> <20210504180050.GB1370958@nvidia.com> <20210504151154.02908c63@jacob-builder> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cLArOltAOURLFEyuzKk6PJmJ0pfXnOd1SuIahF/sRjY=; b=GxRbyVPgdwFtFgyoa4wQA4EGmiWBYPbCwRFPeyYyDyHnYYs/0SoQNe05NHcqaTQdCwt0MNwkNwSz+3DA00sgo2LL0XQRYLm/IMfzyp47L8kdCzbr9GOr5uncuADU3gd8QRy8ms1qHi0OWFPw9L/QyLZL1FGNJykfnzUnHjgjHQR5Crsi/G2a1pH7Qm+I3XhlTdJHHbwuqNQyDSlxmlqSzVk4h7gSXu+1gADhLaXgcFLtO74je+YNnHdnvsZGARjWvCxdxwJFW4gVkIAg36d6rqPXkokwhyZJdKHWkerXxPDDPsDszRX8hkW3qJeR5JvnOa3L1vc0r4xk/RL4YNAmCw== Content-Disposition: inline In-Reply-To: <20210504151154.02908c63@jacob-builder> List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Jacob Pan Cc: "Tian, Kevin" , Alex Williamson , "Liu, Yi L" , Auger Eric , Jean-Philippe Brucker , LKML , Joerg Roedel , Lu Baolu , David Woodhouse , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , "cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Tejun Heo , Li Zefan , Johannes Weiner , Jean-Philippe Brucker , Jonathan Corbet , "Raj, Ashok" , "Wu, Hao" , "Jiang, Dave" On Tue, May 04, 2021 at 03:11:54PM -0700, Jacob Pan wrote: > > It is a weird way to use xarray to have a structure which > > itself is just a wrapper around another RCU protected structure. > > > > Make the caller supply the ioasid_data memory, embedded in its own > > element, get rid of the void * and rely on XA_ZERO_ENTRY to hold > > allocated but not active entries. > > > Let me try to paraphrase to make sure I understand. Currently > struct ioasid_data is private to the iasid core, its memory is allocated by > the ioasid core. > > You are suggesting the following: > 1. make struct ioasid_data public > 2. caller allocates memory for ioasid_data, initialize it then pass it to > ioasid_alloc to store in the xarray > 3. caller will be responsible for setting private data inside ioasid_data > and do call_rcu after update if needed. Basically, but you probably won't need a "private data" once the caller has this struct as it can just embed it in whatever larger struct makes sense for it and use container_of/etc I didn't look too closely at the whole thing though. Honestly I'm a bit puzzled why we need a pluggable global allocator framework.. The whole framework went to some trouble to isolate everything into iommu drivers then that whole design is disturbed by this global thing. Jason