[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1321221657.17837.51.camel@edumazet-laptop>
Date: Sun, 13 Nov 2011 23:00:57 +0100
From: Eric Dumazet <eric.dumazet@...il.com>
To: eilong@...adcom.com
Cc: David Miller <davem@...emloft.net>,
"bhutchings@...arflare.com" <bhutchings@...arflare.com>,
"pstaszewski@...are.pl" <pstaszewski@...are.pl>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] bnx2x: reduce skb truesize by 50%
Le dimanche 13 novembre 2011 à 22:08 +0200, Eilon Greenstein a écrit :
> On Sun, 2011-11-13 at 11:42 -0800, Eric Dumazet wrote:
> > Le dimanche 13 novembre 2011 à 20:53 +0200, Eilon Greenstein a écrit :
> >
> > > I’m not sure I’m following the math over here. Assuming L1 is 64 bytes,
> > > we need up to 63 bytes to align the start address (assuming SLOB is
> > > being used) and additional (up to) 63 bytes at the end. That can sum up
> > > to 126 bytes am I missing something?
> > >
> >
> > What do you really mean by aligning the end ?
>
> I mean padding it to full cache line.
>
> > How can both start and end of a frame can be aligned ?
>
> The packet will start at aligned address and (using padding) will end at
> cache line boundaries.
>
OK, so hardware adds up to 63 bytes of padding at the end of the packet.
> > If hardware needs extra room after the end of frame, then we already
> > have it (since we store struct skb_shared_info here)
>
> We have some space in there, but as far as I can tell it's not up to 63
> bytes, right? We will overrun the dataref.
>
OK then we need using build_skb() for this driver :)
http://lists.openwall.net/netdev/2011/07/11/19
This way, we build the skb_shared_info content _after_ frame is
delivered by device.
--
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
Powered by blists - more mailing lists