From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52559) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zs2Ew-00043Y-0s for qemu-devel@nongnu.org; Fri, 30 Oct 2015 01:28:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zs2Er-0000fI-Uf for qemu-devel@nongnu.org; Fri, 30 Oct 2015 01:28:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38704) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zs2Er-0000fE-PZ for qemu-devel@nongnu.org; Fri, 30 Oct 2015 01:28:33 -0400 References: <1445792408-28571-1-git-send-email-leonid.bloch@ravellosystems.com> <563060C1.7030209@redhat.com> From: Jason Wang Message-ID: <5632FFF6.8000003@redhat.com> Date: Fri, 30 Oct 2015 13:28:22 +0800 MIME-Version: 1.0 In-Reply-To: <563060C1.7030209@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 0/5] Introduce Intel 82574 GbE Controller Emulation (e1000e) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Leonid Bloch , qemu-devel@nongnu.org Cc: Dmitry Fleytman , Leonid Bloch , Shmulik Ladkani 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. >