On Mon, Jan 30, 2023 at 07:53:55PM +0800, Yongji Xie wrote: > On Fri, Jan 27, 2023 at 4:22 PM Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > > > On Mon, Dec 19, 2022 at 05:36:02PM +0800, Yongji Xie wrote: > > > On Mon, Dec 19, 2022 at 3:33 PM Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > > > > > > > On Mon, Dec 05, 2022 at 04:41:17PM +0800, Xie Yongji wrote: > > > > > Export irq_create_affinity_masks() so that some modules > > > > > can make use of it to implement interrupt affinity > > > > > spreading mechanism. > > > > > > > > > > Signed-off-by: Xie Yongji <xieyongji@xxxxxxxxxxxxx> > > > > > > > > So this got nacked, what's the plan now? > > > > > > > > > > I‘d like to check with Christoph again first. > > > > > > Hi Christoph, > > > > > > Jason will post some patches to get rid of the DMA API for vDPA > > > simulators. And the irq affinity algorithm is independent of the IRQ > > > subsystem IIUC. So could you allow this patch so that we can reuse the > > > algorithm to select the best CPU (per-cpu affinity if possible, or at > > > least per-node) to run the virtqueue's irq callback. > > > > > > Thanks, > > > Yongji > > > > I think you need to explain why you are building low level > > affinity masks. > > In VDUSE case, we use workqueue to run the virtqueue's irq callback. > Now I want to queue the irq callback kwork to one specific CPU to get > per-cpu affinity if possible, or at least per-node. So I need to use > this function to build the low level affinity masks for each > virtqueue. > > > what's the plan now? > > > > If there is no objection, I'll post a new version. > > Thanks, > Yongji I doubt you made a convicing case here - I think Christoph was saying if it is not an irq it should not use an irq affinity API. So a new API possibly sharing implementation with irq affinity is called for then? Maybe. -- MST _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
