From: ANNIE LI <annie.li@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
xen-devel <xen-devel@lists.xen.org>
Subject: Re: xennet: skb rides the rocket: 20 slots
Date: Fri, 11 Jan 2013 15:34:17 +0800 [thread overview]
Message-ID: <50EFC079.1000601@oracle.com> (raw)
In-Reply-To: <1357820816.9456.15.camel@zakaz.uk.xensource.com>
On 2013-1-10 20:26, Ian Campbell wrote:
> On Thu, 2013-01-10 at 11:22 +0000, ANNIE LI wrote:
>> I am thinking to do re-fragment in netfront for these skbs like following,
>>
>> Create a new skb, copy linear data and frag data from original skb into
>> this one, and make every frags data size is PAGE_SIZE except for the
>> last fragment. It is possible that the last fragment length is less than
>> PAGE_SIZE, then free the original skb. The skb packet is large, and
>> there will be lots of copys.
> You don't need (or I suspect want) to copy, you can directly add pages
> from the source skb's frags to the destination skb's frags, with
> appropriate refcount frobbing. You can also share a page between two (or
> more) skbs in the case where the boundary between two skbs happens to be
> in the middle of a page.
>
> But more importantly than all that you need to do more than just
> refragment, you actually need to resegment i.e. you need to duplicate
> the headers (Ethernet, IP, TCP) at the front of each new skb and adjust
> the (psuedo-)checksums as appropriate (which will depend on whether the
> SKB is GSO, or just has checksum offload or nothing).
>
> So you need to go from
> <Ether><IP><TCP><...data... ...data...>
> to
> <Ether><IP><TCP><...data...> <Ether><IP><TCP><...data...>
>
> Where the headers are adjusted to cope with this. Some of data might be
> in frags but equally some might be in skb->data.
>
> I'm guessing that Linux already has code which can do this for you,
> since it has a software fallback for GSO.
There is "skb_gso_segment" existing to perform segmentation on skb and
return a list of segments. From the code, it seems this function is
specific to GSO packets, maybe it is not available to other non-gso
large packets which requires slots is larger than MAX_SKB_FRAGS + 1". So
for non-gso offload packets, I would go forward to write a function to
do resegment.
Thanks
Annie
>
> Ian.
>
>> struct skbuff *xennet_refrag_skb(skb)
>> {
>> create newskb
>> copying data and doing fragmentation
>> return newskb
>> }
>>
>> .......
>>
>> if (unlikely(slots> MAX_SKB_FRAGS + 1)) {
>> net_alert_ratelimited(
>> "xennet: skb rides the rocket: %d slots\n", slots);
>> skb = xennet_refrag_skb(skb);
>> }
>> .....
>>
>> Thanks
>> Annie
>>>> "netchannel vs MAX_SKB_FRAGS". Maybe these two mechanism are all
>>>> necessary?
>>> Lets see first if this is indeed the problem. Perhaps a simple debug
>>> patch that just does:
>>>
>>> s/MAX_SKB_FRAGS/DEBUG_MAX_FRAGS/
>>> #define DEBUG_MAX_FRAGS 21
>>>
>>> in both netback and netfront to set the maximum number of frags we can
>>> handle to 21? If that works with Sander test - then yes, it looks like
>>> we really need to get this 'feature-max-skb-frags' done.
>>>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2013-01-11 7:34 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-04 16:28 xennet: skb rides the rocket: 20 slots Sander Eikelenboom
2013-01-07 10:55 ` Ian Campbell
2013-01-07 12:30 ` Sander Eikelenboom
2013-01-07 13:27 ` Ian Campbell
2013-01-07 14:05 ` Sander Eikelenboom
2013-01-07 14:12 ` Ian Campbell
2013-01-08 2:12 ` ANNIE LI
2013-01-08 10:05 ` Ian Campbell
2013-01-08 10:16 ` Paul Durrant
2013-01-08 20:57 ` James Harper
2013-01-08 22:04 ` Konrad Rzeszutek Wilk
2013-01-08 20:55 ` Sander Eikelenboom
2013-01-09 7:10 ` ANNIE LI
2013-01-09 15:08 ` Konrad Rzeszutek Wilk
2013-01-09 16:34 ` Ian Campbell
2013-01-09 17:05 ` Konrad Rzeszutek Wilk
2013-01-09 18:02 ` Ian Campbell
2013-01-10 11:22 ` ANNIE LI
2013-01-10 12:24 ` Sander Eikelenboom
2013-01-10 12:26 ` Ian Campbell
2013-01-10 15:39 ` Konrad Rzeszutek Wilk
2013-01-10 16:25 ` Ian Campbell
2013-01-11 7:34 ` ANNIE LI [this message]
2013-01-11 9:56 ` Ian Campbell
2013-01-11 10:09 ` Paul Durrant
2013-01-11 10:16 ` Ian Campbell
[not found] ` <50F3D269.6030601@oracle.com>
2013-03-09 12:56 ` Fwd: " Sander Eikelenboom
[not found] ` <19010312768.20130124094542@eikelenboom.it>
2013-03-09 12:57 ` Sander Eikelenboom
2013-03-10 5:22 ` ANNIE LI
2013-03-12 11:37 ` Ian Campbell
2013-03-15 5:14 ` annie li
2013-03-15 21:29 ` Sander Eikelenboom
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=50EFC079.1000601@oracle.com \
--to=annie.li@oracle.com \
--cc=Ian.Campbell@citrix.com \
--cc=konrad.wilk@oracle.com \
--cc=linux@eikelenboom.it \
--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 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).