netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* reasons for dev_alloc_skb +16?
@ 2003-07-09 15:25 Jeff Garzik
  2003-07-09 15:53 ` Andi Kleen
  0 siblings, 1 reply; 6+ messages in thread
From: Jeff Garzik @ 2003-07-09 15:25 UTC (permalink / raw)
  To: netdev

I knew this at one time, but have forgotten it :)

What is the reason for adding 16 to the dev_alloc_skb length?
(and skb_reserve of the same length)

	Jeff

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: reasons for dev_alloc_skb +16?
@ 2003-07-09 15:35 Hen, Shmulik
  0 siblings, 0 replies; 6+ messages in thread
From: Hen, Shmulik @ 2003-07-09 15:35 UTC (permalink / raw)
  To: Jeff Garzik, netdev

Could be for alignment issues.
Or preparation for things like 8021q tagging.


	Shmulik.

> -----Original Message-----
> From: Jeff Garzik [mailto:jgarzik@pobox.com]
> Sent: Wednesday, July 09, 2003 6:26 PM
> To: netdev@oss.sgi.com
> Subject: reasons for dev_alloc_skb +16?
> 
> 
> I knew this at one time, but have forgotten it :)
> 
> What is the reason for adding 16 to the dev_alloc_skb length?
> (and skb_reserve of the same length)
> 
> 	Jeff
> 
> 
> 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: reasons for dev_alloc_skb +16?
  2003-07-09 15:25 reasons for dev_alloc_skb +16? Jeff Garzik
@ 2003-07-09 15:53 ` Andi Kleen
  2003-07-09 16:06   ` Jeff Garzik
  2003-07-10  0:20   ` David S. Miller
  0 siblings, 2 replies; 6+ messages in thread
From: Andi Kleen @ 2003-07-09 15:53 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: netdev

On Wed, 9 Jul 2003 11:25:53 -0400
Jeff Garzik <jgarzik@pobox.com> wrote:

> I knew this at one time, but have forgotten it :)
> 
> What is the reason for adding 16 to the dev_alloc_skb length?
> (and skb_reserve of the same length)

For the skb_reserve alignment to align the IP header. 

But it's not clear it is still a good idea because it leads to cache line 
misalignment of the beginning of the packet, forcing the card to do a
costly Read-Modify-Write cycle.

-Andi

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: reasons for dev_alloc_skb +16?
  2003-07-09 15:53 ` Andi Kleen
@ 2003-07-09 16:06   ` Jeff Garzik
  2003-07-09 16:13     ` Andi Kleen
  2003-07-10  0:20   ` David S. Miller
  1 sibling, 1 reply; 6+ messages in thread
From: Jeff Garzik @ 2003-07-09 16:06 UTC (permalink / raw)
  To: Andi Kleen; +Cc: netdev

On Wed, Jul 09, 2003 at 05:53:55PM +0200, Andi Kleen wrote:
> On Wed, 9 Jul 2003 11:25:53 -0400
> Jeff Garzik <jgarzik@pobox.com> wrote:
> 
> > I knew this at one time, but have forgotten it :)
> > 
> > What is the reason for adding 16 to the dev_alloc_skb length?
> > (and skb_reserve of the same length)
> 
> For the skb_reserve alignment to align the IP header. 
> 
> But it's not clear it is still a good idea because it leads to cache line 
> misalignment of the beginning of the packet, forcing the card to do a
> costly Read-Modify-Write cycle.

Exactly.  Ben H is running into this, and pondering direct use of
alloc_skb for precisely this reason.

	Jeff

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: reasons for dev_alloc_skb +16?
  2003-07-09 16:06   ` Jeff Garzik
@ 2003-07-09 16:13     ` Andi Kleen
  0 siblings, 0 replies; 6+ messages in thread
From: Andi Kleen @ 2003-07-09 16:13 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: netdev

On Wed, 9 Jul 2003 12:06:57 -0400
Jeff Garzik <jgarzik@pobox.com> wrote:

> On Wed, Jul 09, 2003 at 05:53:55PM +0200, Andi Kleen wrote:
> > On Wed, 9 Jul 2003 11:25:53 -0400
> > Jeff Garzik <jgarzik@pobox.com> wrote:
> > 
> > > I knew this at one time, but have forgotten it :)
> > > 
> > > What is the reason for adding 16 to the dev_alloc_skb length?
> > > (and skb_reserve of the same length)
> > 
> > For the skb_reserve alignment to align the IP header. 
> > 
> > But it's not clear it is still a good idea because it leads to cache line 
> > misalignment of the beginning of the packet, forcing the card to do a
> > costly Read-Modify-Write cycle.
> 
> Exactly.  Ben H is running into this, and pondering direct use of
> alloc_skb for precisely this reason.

Problem with changing it is that the payload ends up misaligned.
And user space usually aligns the buffer passed to recvmsg. This
means csum_copy_to_user has to csum-copy unaligned->aligned, which will
be likely very slow. 

Related problem is that the TCP/IP headers are unaligned, but if your CPU
has fast enough misalignment handling it shouldn't be too bad.

-Andi

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: reasons for dev_alloc_skb +16?
  2003-07-09 15:53 ` Andi Kleen
  2003-07-09 16:06   ` Jeff Garzik
@ 2003-07-10  0:20   ` David S. Miller
  1 sibling, 0 replies; 6+ messages in thread
From: David S. Miller @ 2003-07-10  0:20 UTC (permalink / raw)
  To: ak; +Cc: jgarzik, netdev

   From: Andi Kleen <ak@suse.de>
   Date: Wed, 9 Jul 2003 17:53:55 +0200
   
   But it's not clear it is still a good idea because it leads to cache line 
   misalignment of the beginning of the packet, forcing the card to do a
   costly Read-Modify-Write cycle.
   
Only "dumb cards" do that, smart ones rewind to the beginning of
the current cache line and ask for the whole thing instead of
pieces.

The +16 is actually needed to align the first hunk of the outgoing
packet so we can do a 16-byte aligned memcpy of the hard-header
cache as we build the packet.

Jeff, look at LL_RESERVED_SPACE() and the comment above it in
include/linux/netdevice.h

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2003-07-10  0:20 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-07-09 15:25 reasons for dev_alloc_skb +16? Jeff Garzik
2003-07-09 15:53 ` Andi Kleen
2003-07-09 16:06   ` Jeff Garzik
2003-07-09 16:13     ` Andi Kleen
2003-07-10  0:20   ` David S. Miller
  -- strict thread matches above, loose matches on Subject: below --
2003-07-09 15:35 Hen, Shmulik

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).