From: Zoltan Kiss <zoltan.kiss@citrix.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Wei Liu <wei.liu2@citrix.com>, <netdev@vger.kernel.org>,
<xen-devel@lists.xen.org>, David Vrabel <david.vrabel@citrix.com>,
Konrad Wilk <konrad.wilk@oracle.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Stefan Bader <stefan.bader@canonical.com>
Subject: Re: [PATCH net-next] xen-netfront: try linearizing SKB if it occupies too many slots
Date: Fri, 16 May 2014 17:51:46 +0100 [thread overview]
Message-ID: <53764222.6070705@citrix.com> (raw)
In-Reply-To: <1400258829.7973.209.camel@edumazet-glaptop2.roam.corp.google.com>
On 16/05/14 17:47, Eric Dumazet wrote:
> On Fri, 2014-05-16 at 17:29 +0100, Zoltan Kiss wrote:
>> On 16/05/14 16:34, Wei Liu wrote:
>>>
>>> It works, at least in this Redis testcase. Could you explain a bit where
>>> this 56000 magic number comes from? :-)
>>>
>>> Presumably I can derive it from some constant in core network code?
>>
>> I guess it just makes more unlikely to have packets with problematic layout. But the following packet would still fail:
>> linear buffer : 80 bytes, on 2 pages
>> 17 frags, 80 bytes each, each spanning over page boundary.
>
> How would you build such skbs ? Its _very_ difficult, you have to be
> very very smart to hit this.
I wouldn't build such skbs, I would expect the network stack to create
such weird things sometimes :)
The goal here is to prepare and handle the worst case scenarios as well.
>
> Also reducing gso_max_size made sure order-5 allocations would not be
> attempted in this unlikely case.
But reducing the gso_max_size would have a bad impact on the general
network throughput, right?
next prev parent reply other threads:[~2014-05-16 16:51 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-16 11:08 [PATCH net-next] xen-netfront: try linearizing SKB if it occupies too many slots Wei Liu
2014-05-16 13:04 ` Eric Dumazet
2014-05-16 13:04 ` Eric Dumazet
2014-05-16 13:11 ` Wei Liu
2014-05-16 13:11 ` Wei Liu
2014-05-16 14:21 ` Eric Dumazet
2014-05-16 14:36 ` Wei Liu
2014-05-16 15:22 ` Eric Dumazet
2014-05-16 15:34 ` Wei Liu
2014-05-16 16:29 ` Zoltan Kiss
2014-05-16 16:29 ` Zoltan Kiss
2014-05-16 16:47 ` Eric Dumazet
2014-05-16 16:47 ` Eric Dumazet
2014-05-16 16:51 ` Zoltan Kiss
2014-05-16 16:51 ` Zoltan Kiss [this message]
2014-05-16 17:00 ` Eric Dumazet
2014-05-16 17:00 ` Eric Dumazet
2014-05-16 16:54 ` Wei Liu
2014-05-19 16:47 ` Zoltan Kiss
2014-05-19 16:47 ` Zoltan Kiss
2014-05-16 16:54 ` Wei Liu
2014-05-30 8:06 ` Stefan Bader
2014-05-30 8:06 ` Stefan Bader
2014-05-30 12:07 ` Zoltan Kiss
2014-05-30 12:07 ` Zoltan Kiss
2014-05-30 12:37 ` Stefan Bader
2014-05-30 12:37 ` Stefan Bader
2014-07-02 12:23 ` Stefan Bader
2014-07-02 12:23 ` Stefan Bader
2014-07-02 13:12 ` Zoltan Kiss
2014-07-02 13:12 ` Zoltan Kiss
2014-05-30 12:11 ` Wei Liu
2014-05-30 12:28 ` Stefan Bader
2014-05-30 12:38 ` Wei Liu
2014-05-30 12:38 ` Wei Liu
2014-05-30 12:28 ` Stefan Bader
2014-05-30 12:28 ` David Laight
2014-05-30 12:35 ` Wei Liu
2014-05-30 12:35 ` Wei Liu
2014-05-30 12:28 ` David Laight
2014-05-30 12:11 ` Wei Liu
2014-05-16 15:34 ` Wei Liu
2014-05-16 15:22 ` Eric Dumazet
2014-05-16 14:36 ` Wei Liu
2014-05-16 14:21 ` Eric Dumazet
-- strict thread matches above, loose matches on Subject: below --
2014-05-16 11:08 Wei Liu
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=53764222.6070705@citrix.com \
--to=zoltan.kiss@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=eric.dumazet@gmail.com \
--cc=konrad.wilk@oracle.com \
--cc=netdev@vger.kernel.org \
--cc=stefan.bader@canonical.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.