All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] [PATCH 0/2] e1000e: Reimplement e1000 as a variant of e1000e
@ 2017-10-27  2:49 Ed Swierk
  2017-10-27  2:49 ` [Qemu-devel] [PATCH 1/2] e1000e: Infrastructure for e1000-ng Ed Swierk
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Ed Swierk @ 2017-10-27  2:49 UTC (permalink / raw)
  To: Ed Swierk, qemu-devel
  Cc: Jason Wang, Dmitry Fleytman, Leonid Bloch, Peter Maydell,
	Stefan Hajnoczi

>From a hardware functionality and register perspective, the Intel
8254x Gigabit Ethernet Controller[1] is roughly a subset of the Intel
82574[2], making it practical to implement e1000 device emulation as
an extension of e1000e.

That would be a step towards eliminating the existing e1000
implementation--a bunch of semi-redundant code with its own bugs (like
the faulty tx checksum offload I reported recently[3]).

[1] https://www.intel.com/content/dam/doc/manual/pci-pci-x-family-gbe-controllers-software-dev-manual.pdf
[2] https://www.intel.com/content/dam/doc/datasheet/82574l-gbe-controller-datasheet.pdf
[3] https://lists.nongnu.org/archive/html/qemu-devel/2017-10/msg03008.html

This patch series adds a new e1000-ng device but leaves the existing
e1000 device alone. Linux 4.1 and Windows 10 e1000 guest drivers
recognize the e1000-ng device and successfully pass traffic on a
Linux host.

Preliminary performance measurements are encouraging: with e1000-ng,
single-threaded TCP iperf shows about a 2x speedup in tx and rx
throughput vs e1000, and CPU usage is slighly lower.

A ton of work is needed before e1000-ng will be ready to supplant
e1000: testing with every random guest OS, fixing bugs, figuring out
migration and other missing functionality. There's no way I can do
this myself.

I'd like to propose a more modest and achievable short-term goal: find
and fix any regressions that might affect users of e1000e and e1000,
so that the patches can be applied and folks can easily start trying
out e1000-ng with their favorite guest OS. That means accepting (for
now) known deficiencies in the new e1000-ng devices, which can be
addressed by myself and (hopefully) others in follow-up patches. Does
that sound reasonable?

Ed Swierk (2):
  e1000e: Infrastructure for e1000 devices
  e1000e: Add e1000 devices

 hw/net/e1000e.c      | 236 +++++++++++++++++++++++++++++++++++++-----------
 hw/net/e1000e_core.c | 249 +++++++++++++++++++++++++++++++++++++--------------
 hw/net/e1000e_core.h |  25 +++++-
 3 files changed, 387 insertions(+), 123 deletions(-)

-- 
1.9.1

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2017-11-14 23:50 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-10-27  2:49 [Qemu-devel] [PATCH 0/2] e1000e: Reimplement e1000 as a variant of e1000e Ed Swierk
2017-10-27  2:49 ` [Qemu-devel] [PATCH 1/2] e1000e: Infrastructure for e1000-ng Ed Swierk
2017-10-27  2:49 ` [Qemu-devel] [PATCH 2/2] e1000e: Add e1000-ng devices Ed Swierk
2017-11-09  4:39 ` [Qemu-devel] [PATCH v2 0/2] e1000e: Reimplement e1000 as a variant of e1000e Ed Swierk
2017-11-09  4:39   ` [Qemu-devel] [PATCH v2 1/2] e1000e: Infrastructure for e1000-ng Ed Swierk
2017-11-09  4:39   ` [Qemu-devel] [PATCH v2 2/2] e1000e: Add e1000-ng devices Ed Swierk
2017-11-09 13:53   ` [Qemu-devel] [PATCH v2 0/2] e1000e: Reimplement e1000 as a variant of e1000e Daniel P. Berrange
2017-11-14 23:50     ` Ed Swierk

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.