All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Liu <wei.liu2@citrix.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: 'Wei Liu' <wei.liu2@citrix.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Zoltan Kiss <zoltan.kiss@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [PATCH net-next] xen-netfront: try linearizing SKB if it occupies too many slots
Date: Fri, 30 May 2014 13:35:54 +0100	[thread overview]
Message-ID: <20140530123554.GD2655@zion.uk.xensource.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D172506AE@AcuExch.aculab.com>

On Fri, May 30, 2014 at 12:28:53PM +0000, David Laight wrote:
> From: Wei Liu
> > On Fri, May 30, 2014 at 10:06:48AM +0200, Stefan Bader wrote:
> > [...]
> > > I had been idly wondering about this onwards. And trying to understand the whole
> > > skb handling environment, I tried to come up with some idea as well. It may be
> > > totally stupid and using the wrong assumptions. It seems to work in the sense
> > > that things did not blow up into my face immediately and somehow I did not see
> > > dropped packages due to the number of slots either.
> > > But again, I am not sure I am doing the right thing. The idea was to just try to
> > > get rid of so many compound pages (which I believe are the only ones that can
> > > have an offset big enough to allow some alignment savings)...
> > >
> > > -Stefan
> > >
> > 
> > Thanks. I think the general idea is OK, but it still involves
> > unnecessary page allocation. We don't actually need to get rid of
> > compound page by replacing it with a new page, we just need to make sure
> > the data inside is aligned.
> > 
> > If you look at xennet_make_frags, it only grants the 4K page which
> > contains data. I presume a simple memove would be better than alloc_page
> > + memcpy. What do you think?
> > 
> > Like:
> >    memmove(page_address(fpage), page_address(fpage)+offset, size);
> >    frag->page_offset = 0;
> 
> Isn't the rest of the page likely to contain fragments of other ethernet
> frames?  Even possibly of other data?
> 

You're right, this is a valid concern.

  parent reply	other threads:[~2014-05-30 12:35 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 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:47               ` Eric Dumazet
2014-05-16 16:47               ` Eric Dumazet
2014-05-16 16:51                 ` Zoltan Kiss
2014-05-16 16:51                 ` Zoltan Kiss
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 [this message]
2014-05-30 12:28                   ` David Laight
2014-05-30 12:11                 ` Wei Liu
2014-05-16 16:29             ` Zoltan Kiss
2014-05-16 15:34           ` Wei Liu
2014-05-16 15:22         ` Eric Dumazet
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=20140530123554.GD2655@zion.uk.xensource.com \
    --to=wei.liu2@citrix.com \
    --cc=David.Laight@ACULAB.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=xen-devel@lists.xen.org \
    --cc=zoltan.kiss@citrix.com \
    /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.