I am pressing reset button on nucleo board to reset both MCU and ETH PHY. Reset line connected both MCU and ETH PHY in nucleo board.
[...]
Also I realised that If I flash the code it runs fine. However, If I issue a reset or plug out/in the power after flashing code it won't run. That is the main problem I think.
That makes sense if your toolchain and programming interface are configured to soft reset the MCU after programming, since it won't cause a hardware reset to the PHY. So the PHY will still be up and running from the last reset unless/until you issue a soft reset.
Speaking which, it's hard to offer advice when you aren't clear and consistent in your description of the problem. You started off asking about hard reset, but then the code you posted shows the MCU issuing a soft reset, which confuses what's going on and makes it harder to help you. If you're making changes to the code as you troubleshoot that's fine, but please be clear about which changes to the code or your programming/reset process have what effects on the system behavior.
The screen shot I sent shows MDC so after reset I am constantly checking Link status. I didn't checked other RMII lines. I am waiting for DMA to release the descriptor ((" while(TxDescriptorTable.Status & ETH_DMATXDESC_OWN); //wait until DMA release Descriptor" )).
Sure, your code is waiting for the descriptor to be released, but is that actually happening? Without information like this it's harder to tell where the problem is.
All that aside, if the link comes up faster when you reduce the polling rate, then my guess is that servicing an SMI transaction is keeping the PHY's internal logic from getting the link worked out or performing whatever other reset housekeeping it needs to do. I don't know how PHYs are designed internally but given how much work they do I could believe there's something like a little general purpose processor core in there that handles a lot of the configuration and housekeeping necessary to manage the link hardware, and it probably wasn't designed to service SMI continuously at the rate that something like an STM32F4 can poll it during otherwise normal operation.