All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.