From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:43475)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <dmitry.fleytman@ravellosystems.com>)
	id 1S5KEW-00008V-7h
	for qemu-devel@nongnu.org; Wed, 07 Mar 2012 12:01:01 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <dmitry.fleytman@ravellosystems.com>)
	id 1S5KE6-0006bl-Os
	for qemu-devel@nongnu.org; Wed, 07 Mar 2012 12:00:59 -0500
Received: from na3sys010aog113.obsmtp.com ([74.125.245.94]:41654)
	by eggs.gnu.org with smtp (Exim 4.71)
	(envelope-from <dmitry.fleytman@ravellosystems.com>)
	id 1S5KE6-0006bB-F7
	for qemu-devel@nongnu.org; Wed, 07 Mar 2012 12:00:34 -0500
Received: by mail-pw0-f45.google.com with SMTP id uo5so781726pbc.32
	for <qemu-devel@nongnu.org>; Wed, 07 Mar 2012 09:00:30 -0800 (PST)
MIME-Version: 1.0
Date: Wed, 7 Mar 2012 18:32:43 +0200
Message-ID: <CAOMtban3iL3XOF8zO2Uphi7w9trD2iC5=a6fX4pxnnyS7mpk0A@mail.gmail.com>
From: Dmitry Fleytman <dmitry.fleytman@ravellosystems.com>
Content-Type: text/plain; charset=ISO-8859-1
Subject: [Qemu-devel] QEMU RX offload issues with net device frontend that
 does not support virtio extensions
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Hello,

It looks like there is a problem in QEMU related to usage of frontends
without virtio extensions.

Normally on RX path QEMU receives packet metadata with offloads
information in virtio header.
In particular there is an information about checksumming state. For
example, when
packet is being transferred from guest to guest with offloads enabled
on transmitter side,
checksums won't be calculated, special flag will be set instead in
virtio header indicating that the checksum is ok.
Based on this flag device may notify guest that checksum verification
for this packet is not required.

Now, when virtio header is not supported on receiver side, there is no
way device may be notified about the checksum state.
Packet will be indicated to the guest as is and will be dropped by
guest's network stack.

I've tested this scenario with virtio devices and observed the issue described.

Do I miss something? Is there any configuration option or something
I'm not aware about?

Thanks in advance,
Dmitry Fleytman.