On Thu, Nov 9, 2017 at 5:53 AM, Daniel P. Berrange <berra...@redhat.com> wrote: > My fear is that this approach of building a new e1000-ng device in > parallel with having the existing e1000 device is going to cause > long term pain, possibly never getting to a state where the e1000-ng > device can replace the e1000 device. Any time there needs to be a > "big bang" to switch from one impl to another completely different > impl always causes trouble IME. With need for migration wire format > & state compatibility, this is even more difficult. From a code review > POV it will be essentially impossible to have confidence that the new > impl can be a viable drop-in replacement for the old impl. > > Is there really no way that you can change the approach to do a more > incremental conversion of the existing code base, but still end up in > the same place at the very end ? > > eg just copy all the e1000.c code into the e1000e.c file to start with. > Then gradually merge functional areas over a longish series of patches > to eliminate the duplication. This would make it far more practical to > identify where any regressions come from, and will give reviewers more > confidence that we're not breaking migration compat.
I agree an incremental conversion is the only realistic way to unearth potential regressions; testing won't be enough. In the past couple of days I've run into several cases where e1000 works but e1000-ng doesn't. Apparently e1000e guest drivers just happen not to tickle these bugs. So e1000-ng isn't ready for prime time anyway. I'll shelve this patch series for the moment. Meanwhile I'll post separate patches for the bugs I've encountered with e1000 UDP checksum offload. --Ed