From: ANNIE LI <annie.li@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: 'Steven Haigh' <netwiz@crc.id.au>,
Ian Campbell <Ian.Campbell@citrix.com>,
"Palagummi, Siva" <Siva.Palagummi@ca.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
"msw@amazon.com" <msw@amazon.com>,
Jacek Milewicz <jacekowski@jacekowski.org>
Subject: Re: Is: SKB_MAX_LEN bites again. Was: Re: bug disabling guest interface
Date: Tue, 12 Mar 2013 23:07:05 +0800 [thread overview]
Message-ID: <513F4499.9080804@oracle.com> (raw)
In-Reply-To: <1363090704.29093.87.camel@zion.uk.xensource.com>
On 2013-3-12 20:18, Wei Liu wrote:
> On Tue, 2013-03-12 at 11:40 +0000, Ian Campbell wrote:
>> On Sun, 2013-03-10 at 19:18 +0000, Wei Liu wrote:
>>> On Sat, Mar 09, 2013 at 02:57:16AM +0000, Ian Campbell wrote:
>>>>>> - change MAX_SKB_FRAGS to 19 to accommodate all guests
>>>> Changing MAX_SKB_FRAGS is *not* an option upstream. This might be a
>>>> useful local hack but we need to drop the idea as a long term fix.
>>>>
>>>>> Ugh. The negotiations between host and guest is probably the best
>>>>> choice. The issues you are going to hit are that you might need
>>>>> to redo the skbs to match what the frontend's max is.
>>>> IMHO the right fix is for netback to coalesce as it copies from the
>>>> frontend if it needs to do so, it is copying anyway so it should be
>>>> cheap enough. I thought we had discussed this and someone was working on
>>>> implementing it. If not Annie then perhaps it was Matt or Siva (both now
>>>> CC'd)
>>>>
>>> As a short term fix, can we use skb_linearize() if skb->nr_frags>=
>>> MAX_SKB_FRAGS?
>> No, because that would require changing the frontend, while this fix
>> needs to be in the backend if older guests are to continue working.
>>
>> You can't use skb_linearize in netback as is because you would first
>> need to be able to build the skb with nr_frags>= MAX_SKB_FRAGS in order
>> to pass it to that function.
>>
> Yes, the idea is to define NETBK_MAX_SKB_FRAGS to some bigger number
> (say 20) to accommodate the possible maximum number of frags in
> frontend. The thing that truly matters it the skb->len, which should be
> <64K, nr_frags is not important.
I doubt this would work since you can not build out skb with nr_frags >=
MAX_SKB_FRAGS. See following code in skbuff.h,
#if (65536/PAGE_SIZE + 1) < 16
#define MAX_SKB_FRAGS 16UL
#else
#define MAX_SKB_FRAGS (65536/PAGE_SIZE + 1)
#endif
and every skb contains MAX_SKB_FRAGS frags,
struct skb_shared_info {
....
skb_frag_t frags[MAX_SKB_FRAGS];
...
}
Coalescing frags before building skb could avoid this issue.
Thanks
Annie
>
> I wrote some code during weekend and it seemed to work, but I have not
> verify it extensively.
>
>
> Wei.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2013-03-12 15:07 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-08 8:46 bug disabling guest interface Steven Haigh
2013-03-08 19:36 ` Jacek Milewicz
2013-03-08 20:36 ` Is: SKB_MAX_LEN bites again. Was: " Konrad Rzeszutek Wilk
2013-03-08 22:09 ` Jacek Milewicz
2013-03-09 2:19 ` Steven Haigh
2013-03-12 14:49 ` Konrad Rzeszutek Wilk
2013-03-12 14:56 ` Ian Campbell
2013-03-12 15:05 ` Steven Haigh
2013-03-12 15:08 ` Ian Campbell
2013-03-12 22:19 ` James Harper
2013-03-13 4:09 ` jacek burghardt
2013-03-12 14:49 ` Konrad Rzeszutek Wilk
2013-03-09 2:57 ` Ian Campbell
2013-03-09 3:16 ` Steven Haigh
2013-03-09 12:53 ` Sander Eikelenboom
2013-03-10 4:58 ` ANNIE LI
2013-03-10 4:49 ` ANNIE LI
2013-03-12 11:39 ` Ian Campbell
2013-03-10 19:18 ` Wei Liu
2013-03-12 11:40 ` Ian Campbell
2013-03-12 12:18 ` Wei Liu
2013-03-12 15:07 ` ANNIE LI [this message]
2013-03-12 15:25 ` Wei Liu
2013-03-12 20:13 ` Wei Liu
2013-03-12 21:08 ` Wei Liu
2013-03-13 6:44 ` annie li
2013-03-13 9:43 ` Ian Campbell
2013-03-13 11:24 ` Wei Liu
2013-03-13 6:22 ` annie li
2013-03-13 11:26 ` Wei Liu
2013-03-10 4:48 ` ANNIE LI
[not found] <CAHyyzzTtK+LbxOh2r_X0=Zd2FsTxoAiLLaWahv5FY-QZnQxhLQ@mail.gmail.com>
[not found] ` <CAHyyzzSO0vY3LquDjXVAeV3U9sLnAY28+iADzsOLFkMGcJHLOQ@mail.gmail.com>
[not found] ` <CAHyyzzSDqmBNWmyRKFijei8YrJD5i40AJ9mcxxnme9CeCLZX2g@mail.gmail.com>
[not found] ` <CAHyyzzQcjzeWv-Z6SBOb8Ra0u6BOMzjKV3Ze482rMmMHkAMccw@mail.gmail.com>
[not found] ` <CAHyyzzQsh30y7-4M1xmJc+8p-EcqS0+jaibpTrXxTQi92iGDgw@mail.gmail.com>
2013-04-10 15:28 ` (no subject) jacek burghardt
[not found] ` <20130411010344.GY11427@reaktio.net>
2013-04-11 7:31 ` Is: SKB_MAX_LEN bites again. Was: Re: bug disabling guest interface Brian Menges
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=513F4499.9080804@oracle.com \
--to=annie.li@oracle.com \
--cc=Ian.Campbell@citrix.com \
--cc=Siva.Palagummi@ca.com \
--cc=jacekowski@jacekowski.org \
--cc=konrad.wilk@oracle.com \
--cc=msw@amazon.com \
--cc=netwiz@crc.id.au \
--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 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).