Problem with SGDMA in ISR

If I am going to make some extensive changes (such as switching to a different SGDMA implementation), can I check that this is the preferred solution for what I am trying to achieve.

My aim is to move packets of 512 bytes around my system with the minimum possible latency (so I can take data samples at the highest possible frequency). The packets go in two directions:

1) From an external USB fifo avalon MM-slave interface to M9K buffers in other avalon MM-slave data sampling components (these packets hold information about how the sampling should be performed)

2) From M9K buffers in avalon MM-slave data sampling components back to the USB fifo MM-slave interface (these packets hold sampled data)

In my current solution, the slave components signal that they have packets by interrupting a Nios processor.

In the USB component ISR I setup an SGDMA transfer from the component into Nios RAM. In the Nios software main loop, the packet is analysed and sent on to the appropriate data sampling component using another SGDMA transfer.

In the data sampling component ISR I setup an SGDMA transfer either directly to the USB component (if it's buffer isn't full) or to RAM (if the USB component buffer is full).

Given what I am trying to achieve, does a direct swap of the standard Altera SGDMA IP block for the modular SGDMA IP block sound like a sensible route to solving the problem?

If so, will it be a problem that I am using Quartus v7.2sp2? (I see that the mSGDMA examples require Quartus v9.1).

I have seen some other posts that recommend building custom avalon MM-masters to perform functionality similar to the SGDMA. Would this be a sensible course of action?