netdev - RE: [PATCH net-next] xen-netfront: try linearizing SKB if it occupies too many slots

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <063D6719AE5E284EB5DD2968C1650D6D172506AE@AcuExch.aculab.com>
Date:	Fri, 30 May 2014 12:28:53 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Wei Liu' <wei.liu2@...rix.com>,
	Stefan Bader <stefan.bader@...onical.com>
CC:	Zoltan Kiss <zoltan.kiss@...rix.com>,
	Eric Dumazet <eric.dumazet@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"xen-devel@...ts.xen.org" <xen-devel@...ts.xen.org>,
	David Vrabel <david.vrabel@...rix.com>,
	Konrad Wilk <konrad.wilk@...cle.com>,
	"Boris Ostrovsky" <boris.ostrovsky@...cle.com>
Subject: RE: [PATCH net-next] xen-netfront: try linearizing SKB if it
 occupies too many slots

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?

	David



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html