The ethernet controller will exchange packets through a 10Mbit/s or a 100Mbit/s link. Those packets are sent from or stored into internal memory in the controller, at full speed. The rest is up to you, speed-wise.
If your only job is reflecting the packets, unchanged, back to the sender: this controller can do it at full wire speeds, most likely.
If you need to actually transfer the whole packet from the controller's memory to your system over SPI, or vice-versa, it'll work at up to 1/3 wire speed at 100MBit/s, assuming you run SPI at full speed, and your microcontroller is keeping the SPI link busy at all times, without pauses - i.e. you're using DMA or a dedicated realtime peripheral to deal with SPI.
In many cases you will not need to transfer the whole packet between the controller and your system. For example, if you're having a TCP/IP connection open, then the outgoing packet's headers and destination can be preset in the controller's RAM. Only small changes will be necessary, e.g. the sequence number, and the packet's payload.
When receiving a packet, you may start processing its contents before the whole packet has been transferred over SPI. For example, if you're parsing the packets byte-by-byte, you would be running the parser in parallel with SPI transfer, at least as long as the parser throughput is lower than the SPI data rate. Such overlap can help lower latency and improve throughput in spite of the SPI's limitations.
SPI bus time is the limiting factor, so for maximum throughput there should be as little idle time on that bus as possible.
Those are micro-optimizations but they may be helpful.