If you port your existing OS you may have to fiddle with interrupt priorities to make sure that the FEC RX interrupt can be serviced reasonably promptly if your OS is using a timer ISR for pre-empting tasks. That shouldn't be hard to arrange as there are so many interrupt levels/priorities available.
The 52xxx FEC does a lot of the work for you in terms of dropping unwanted frames and even if you need to allow broadcast frames through (for ARP, etc.) then the frame is flagged as a broadcast to the driver. You can then peek into the frame to see if it is a protocol you want (ICMP say) or a protocol aimed at you (ARP request say). Uninteresting packets can be filtered and dropped with a very few lines of C or even assembler. Interesting packets just need to be queued and signalled to your network stack.
Because the FEC has its own DMA engine packets are transferred from the FEC FIFO into RAM without any CPU intervention so you can have a reasonably big ring of frame buffers if neccessary (memory constraints aside). On the TX side, we have an application where we need to shovel UDP packets out as fast as possible and we have achieved a data rate (payload) of >90Mbps. This is with a 5282, but we are using the 5282's SRAM for this and the FEC is the same as the 522xx. We believe that the CPU usage to service this is <5% leaving us plenty of CPU time for stack and task management (the data bus can get a little crowded at this rate though).
The InterNiche stack that comes with the 522xx is just fine, but you shouldn't find it too hard to port your existing OS because the FEC design makes life simple (easy to say once you've done it I know!).
Paul.