[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH 05/10] net: move destructor_arg to the front of sk_buff.
- To: Alexander Duyck <alexander.h.duyck@xxxxxxxxx>
- From: Eric Dumazet <eric.dumazet@xxxxxxxxx>
- Date: Tue, 10 Apr 2012 20:41:05 +0200
- Cc: Wei Liu <wei.liu2@xxxxxxxxxx>, Ian Campbell <ian.campbell@xxxxxxxxxx>, "Michael S. Tsirkin" <mst@xxxxxxxxxx>, netdev@xxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxx, David Miller <davem@xxxxxxxxxxxxx>
- Delivery-date: Tue, 10 Apr 2012 18:41:45 +0000
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; bh=ZCP1up106rowQebNEXhW82E7PSWtu84WlESvG/LSP+k=; b=jJdlUZKDcJB2sHzdgE3LgJCLNnTANCa/S+TJBqbdbK9XIhNSMb6TqjFzgqpBrK6FQf cydwXzzmL5W8Ft0KFLCaCo8qaE+Ux3thFf+/UNKz4YG7lWwm1SM6wEUzwGqJGekTKqxP mU55LgNzRhWfsOfFMpelfLlKp/RW26SFe+DVb/I3c3hZnq6tmNCOYsEtXgfVe/35W39I Ct5gPI0aCT40bwRsE8Oo757R0qiYmo3V+1QLfviP76KuuVBGqsJHNTHnX6vZPr67VgSJ 73MXB55+syN1SDYww48ZsqzdZAwA2RlymUAHw/T2yXwQ46X4eHtZmi4txKo7AV3wPoYe w7oQ==
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
On Tue, 2012-04-10 at 11:33 -0700, Alexander Duyck wrote:
> Have you checked this for 32 bit as well as 64? Based on my math your
> next patch will still mess up the memset on 32 bit with the structure
> being split somewhere just in front of hwtstamps.
> Why not just take frags and move it to the start of the structure? It
> is already an unknown value because it can be either 16 or 17 depending
> on the value of PAGE_SIZE, and since you are making changes to frags the
> changes wouldn't impact the alignment of the other values later on since
> you are aligning the end of the structure. That way you would be
> guaranteed that all of the fields that will be memset would be in the
> last 64 bytes.
Now when a fragmented packet is copied in pskb_expand_head(), you access
two separate zones of memory to copy the shinfo. But its supposed to be
Problem with this is that the offsets of often used fields will be big
(instead of being < 127) and code will be bigger on x86.
Xen-devel mailing list