Gabe Black wrote: > Ali Saidi wrote: > >> On Sep 6, 2008, at 4:26 PM, Gabe Black wrote: >> >> >> >>> There are two major problems with using the DmaPort. First, I'd want >>> to >>> send the interrupt -now- not when the DMA queuing latency, etc gets >>> used >>> up. Second, DmaPort will fragment a packet which, while maybe >>> necessary >>> in some cases, will break the atomicity requirements for the interrupt >>> messages and might even make the parts of it get there out of order. >>> While it may not -normally- fragment the message, if it does things >>> will >>> be broken. I would rather not use something where such a large portion >>> of its functionality is either not needed or counterproductive. >>> >>> >> The only time the DMA port will break up the packet is if it's larger >> than a cache block. I can't imagine an interrupt message being that >> large. With MSI, interrupts don't magically get propagated. They >> device still has to arbitrate for the bus. >> Ali >> >> > > I can't either, but I don't just want to hope that doesn't happen. Also, > there will still be arbitration on the bus, but the APIC doesn't have to > queue up a DMA transfer to send an IPI since it's not even transferring > anything. > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev >
Also the DmaPort doesn't send it's packets marked uncachable which we established as being a requirement for the interrupt messages. I don't -want- to have to write a new port type, but what I need is fundamentally not a DMA transfer. Making the DmaPort the solution for things other than DMA is misleading, and not having it work for other things means I need to find a different solution. But like I said, I don't want to have to create a new port type, so I certainly wouldn't mind finding a way to use something that already exists. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
