qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: "Stefan Hajnoczi" <stefanha@gmail.com>,
	638955@bugs.launchpad.net,
	"Hervé Poussineau" <hpoussin@reactos.org>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] e1000: Pad short frames to minimum size (60 bytes)
Date: Mon, 20 Sep 2010 10:13:50 +0100	[thread overview]
Message-ID: <20100920091350.GB2376@stefan-thinkpad.transitives.com> (raw)
In-Reply-To: <4C971E77.1000708@redhat.com>

On Mon, Sep 20, 2010 at 10:42:31AM +0200, Kevin Wolf wrote:
> Am 18.09.2010 23:12, schrieb Stefan Hajnoczi:
> > On Sat, Sep 18, 2010 at 9:57 PM, Hervé Poussineau <hpoussin@reactos.org> wrote:
> >> Another patch creating ARP replies at least 64 bytes long has been
> >> committed:
> >> http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=dbf3c4b4baceb91eb64d09f787cbe92d65188813
> >>
> >> Does it fix your issue?
> > 
> > No I don't think so.  This is an e1000 issue, it will happen if you
> > use tap networking too.  The commit you linked to only affects slirp
> > and pads its ARP code.
> > 
> > I think there are two places where the minimum frame length can be enforced:
> > 1. The NIC emulation code.  This is currently how rtl8139, pcnet, and
> > ne2000 do it.  My patch adds the same for e1000.
> > 2. The net layer.  If we're emulating Ethernet then it would be
> > possible to pad to minimum frame length in common networking code
> > (net.c).
> 
> 3. The sender. I think it should be the sender's decision which packet
> he sends and there's no reason to manipulate it on its way to the guest.
> If the sender sends too short packets, this is where the bug is.
> 
> Actually, instead of padding the packet we should already drop it in the
> device model if RCTL.SBP = 0. Does a real Solaris work when it receives
> the same packet?
> 
> On the other hand, it seems that we're missing the padding where it
> actually belongs: when sending packets with TCTL.PSP = 1. Did you send
> the ARP packet from another qemu instance? If so, this might be the real
> reason.

No, I brought up the tap interface on the host and tried to ping the
guest directly.  This caused the host to send an ARP request over the
tap interface.  It was not padded.

Perhaps Linux expects the NIC to deal with padding transmit frames but
tap does not do this.  That's just my theory though from the experience
that real NICs often do pad to minimum size.  Does anyone know the
definitive answer?

Stefan

  parent reply	other threads:[~2010-09-20  9:14 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-18 20:43 [Qemu-devel] [PATCH] e1000: Pad short frames to minimum size (60 bytes) Stefan Hajnoczi
2010-09-18 20:57 ` Hervé Poussineau
2010-09-18 21:12   ` Stefan Hajnoczi
2010-09-20  8:42     ` Kevin Wolf
2010-09-20  8:51       ` Edgar E. Iglesias
2010-09-20  9:13       ` Stefan Hajnoczi [this message]
2010-09-18 21:27 ` Edgar E. Iglesias
2010-09-19  6:36   ` Stefan Hajnoczi
2010-09-19 11:18     ` Michael S. Tsirkin
2010-09-19 12:04       ` Edgar E. Iglesias
2010-09-19 12:03         ` Michael S. Tsirkin
2010-09-20  8:50     ` Kevin Wolf
2010-09-20  9:03       ` Edgar E. Iglesias
2010-09-20  9:34         ` Stefan Hajnoczi
2010-09-20 10:42     ` Michael S. Tsirkin
2010-09-20 20:31       ` Anthony Liguori
2010-09-20 20:35         ` Michael S. Tsirkin
2010-09-20 20:40         ` Edgar E. Iglesias
2010-09-20 20:44           ` Michael S. Tsirkin
2010-09-20 20:51         ` [Bug 638955] " Edgar E. Iglesias
2010-09-21  9:17           ` Michael S. Tsirkin
2010-09-21  9:21             ` Edgar E. Iglesias
2010-09-21  9:16         ` [Bug 638955] " Stefan Hajnoczi
2011-02-21 21:13           ` [Qemu-devel] " Stefan Weil
2010-09-20 17:52 ` [Qemu-devel] Re: [PATCH] e1000: " Michael S. Tsirkin
  -- strict thread matches above, loose matches on Subject: below --
2010-09-15 13:29 [Qemu-devel] [Bug 638955] [NEW] emulated netcards don't work with recent sunos kernel daniel pecka
2010-09-17  8:47 ` [Qemu-devel] [Bug 638955] " daniel pecka
2010-09-17 15:52 ` daniel pecka
2010-09-20  8:02 ` daniel pecka
2010-09-20  9:47 ` Stefan Hajnoczi
2010-09-20 20:57 ` [Bug 638955] Re: [Qemu-devel] [PATCH] e1000: Pad short frames to minimum size (60 bytes) Anthony Liguori
2010-09-20 21:02 ` Edgar E. Iglesias
2010-09-21  8:49 ` [Qemu-devel] [Bug 638955] Re: emulated netcards don't work with recent sunos kernel daniel pecka
2010-10-02 19:23 ` daniel pecka
2010-10-12 14:40   ` [Qemu-devel] " Stefan Hajnoczi
2011-01-03 13:40 ` [Qemu-devel] " daniel pecka
2011-01-04  9:36   ` [Qemu-devel] " Stefan Hajnoczi
2011-01-04 10:04 ` [Qemu-devel] " daniel pecka
2011-01-04 17:51 ` Stefan Weil
2011-01-29 17:41 ` Daniel Kvasnicka
2011-02-28 19:06 ` geppz
2011-03-01  9:50   ` [Qemu-devel] " Stefan Hajnoczi
2011-03-01 15:14 ` [Qemu-devel] " geppz
2011-03-05 20:14 ` Stefan Hajnoczi
2011-03-06 12:32 ` Stefan Hajnoczi
2011-03-07 18:43 ` geppz
2014-10-05 20:57 ` dblade
2014-10-06  8:53   ` Stefan Hajnoczi
2014-10-07  1:46 ` dblade
2015-09-08 22:14 ` Jan Vlug
2015-09-10 19:44 ` Jan Vlug
2016-08-12  4:58 ` T. Huth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100920091350.GB2376@stefan-thinkpad.transitives.com \
    --to=stefanha@linux.vnet.ibm.com \
    --cc=638955@bugs.launchpad.net \
    --cc=hpoussin@reactos.org \
    --cc=kwolf@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).