> > > Not sure. I do not have a good suggestion here :-) Like to hear from > > > David when he comes back, as he spent most time on this issue.. > > > > Sure. He is on vacation. > > Any reason for thinking, rte_intr_ack() may not be semantically correct? > > I think, it is very much correct if there are no better suggestions. > > Anyway it the name, From VFIO perspective, we know what is expected so > > I think it is fine. > > > > > > > > Why not return -1 and let the caller deal with it? > > > > If we make it as rte_intr_ack() no need to return -1 for > > MSIX-VFIO+Linux as it is semantically correct. > > > > Ack can be ambiguous. For INTx, ack usually means PIO to a NIC register, > saying "I got your interrupt, please de-assert irq".
I think, it vary from the perspective of IRQ Chip(or controller) vs NIC register(Source) PoV. Since the API starts from rte_intr_* it is more of controller so _ack_ make sense Other reason for ack: 1) It will enforce that it needs to be called form ISR 2) It would be have been really correct to unmask if VFIO+MSIx+Linux supports it 3) if it is ack, no need to add unmask counterpart, the _mask_ API > > Besides the name, are we agreeing that we want these? > - Unmask if INTx Yes > - Nothing if MSI/MSI-X Yes for MSI over VFIO No for MSI over UIO/igb_uio I don't have very strong opinion unmask vs ack. I prefer to have ack due the reasons stated above. If you really have strong opinion on using unmask, we will stick with that to make forward progress. Let us know. > > So, really just "unmask if INTx". I am ok with rte_intr_unmask() if we make > this intention clear. rte_unmask_if_intx() looks messy. > > Thanks.. > -Hyong
