From: Nick Pegg <npegg@linode.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: "ij@2013.bluespice.org" <ij@2013.bluespice.org>,
Ian Campbell <ian.campbell@citrix.com>,
konrad.wilk@oracle.com,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
"annie.li@oracle.com" <annie.li@oracle.com>,
Jan Beulich <JBeulich@suse.com>
Subject: Re: [PATCH] xen-netfront: drop skb when skb->len > 65535
Date: Wed, 06 Mar 2013 12:20:25 -0500 [thread overview]
Message-ID: <51377AD9.80304@linode.com> (raw)
In-Reply-To: <20130302133243.GA6846@zion.uk.xensource.com>
On 3/2/13 8:32 AM, Wei Liu wrote:
>
> As Nick (npegg@linode.com) pointed out in his email, he saw size 65538.
> I can reproduce this as well by setting vif's mtu to 100 then run iperf.
> 100 was just a random number I came up with when I played with
> fragmentation.
>
Wei: How exactly did you set the MTU on the vif and what were your
arguments to iperf? I tried this on a test host and was unable to
trigger the XSA-39 protection.
As for a more graceful punishment, I noticed that xenvif_carrier_off()
uses netif_carrier_off() to discard queued packets. Would doing a
netif_carrier_off() and then a netif_carrier_on() be sufficient to drop
the bad packets and keep netback from spinning? Would blinking the vif's
carrier in this way allow the DomU to gracefully resume network traffic?
-Nick
next prev parent reply other threads:[~2013-03-06 17:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-01 16:31 [PATCH] xen-netfront: drop skb when skb->len > 65535 Wei Liu
2013-03-01 16:34 ` Wei Liu
2013-03-01 16:48 ` Jan Beulich
2013-03-01 17:00 ` Wei Liu
2013-03-02 2:54 ` Ian Campbell
2013-03-02 13:32 ` Wei Liu
2013-03-03 5:02 ` annie li
2013-03-06 17:20 ` Nick Pegg [this message]
2013-03-06 17:31 ` Wei Liu
2013-03-06 17:57 ` Jacek Milewicz
2013-03-06 18:04 ` Wei Liu
2013-03-03 4:13 ` annie li
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=51377AD9.80304@linode.com \
--to=npegg@linode.com \
--cc=JBeulich@suse.com \
--cc=annie.li@oracle.com \
--cc=ian.campbell@citrix.com \
--cc=ij@2013.bluespice.org \
--cc=konrad.wilk@oracle.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
/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 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.