On 10/28/2015 01:44 PM, Jason Wang wrote: > > On 10/26/2015 01:00 AM, Leonid Bloch wrote: >> Hello qemu-devel, >> >> This patch series is an RFC for the new networking device emulation >> we're developing for QEMU. >> >> This new device emulates the Intel 82574 GbE Controller and works >> with unmodified Intel e1000e drivers from the Linux/Windows kernels. >> >> The status of the current series is "Functional Device Ready, work >> on Extended Features in Progress". >> >> More precisely, these patches represent a functional device, which >> is recognized by the standard Intel drivers, and is able to transfer >> TX/RX packets with CSO/TSO offloads, according to the spec. >> >> Extended features not supported yet (work in progress): >> 1. TX/RX Interrupt moderation mechanisms >> 2. RSS >> 3. Full-featured multi-queue (use of multiqueued network backend) >> >> Also, there will be some code refactoring and performance >> optimization efforts. >> >> This series was tested on Linux (Fedora 22) and Windows (2012R2) >> guests, using Iperf, with TX/RX and TCP/UDP streams, and various >> packet sizes. >> >> More thorough testing, including data streams with different MTU >> sizes, and Microsoft Certification (HLK) tests, are pending missing >> features' development. >> >> See commit messages (esp. "net: Introduce e1000e device emulation") >> for more information about the development approaches and the >> architecture options chosen for this device. >> >> This series is based upon v2.3.0 tag of the upstream QEMU repository, >> and it will be rebased to latest before the final submission. >> >> Please share your thoughts - any feedback is highly welcomed :) >> >> Best Regards, >> Dmitry Fleytman. > Thanks for the series. Will go through this in next few days.
Have a quick glance at the series, got the following questions: - Though e1000e differs from e1000 in many places, I still see lots of code duplications. We need consider to reuse e1000.c (or at least part of). I believe we don't want to fix a bug twice in two places in the future and I expect hundreds of lines could be saved through this way. - For e1000e it self, since it was a new device, so no need to care about compatibility stuffs (e.g auto negotiation and mit). We can just enable them forever. - And for the generic packet abstraction layer, what's the advantages of this? If it has lot, maybe we can use it in other nic model (e.g virtio-net)? Thanks > > Since 2.5 is in soft freeze, this looks a 2.6 material. >
