From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from VA3EHSOBE005.bigfish.com (va3ehsobe005.messaging.microsoft.com [216.32.180.15]) by ozlabs.org (Postfix) with ESMTP id 47AF8B7D54 for ; Wed, 7 Apr 2010 06:12:45 +1000 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver Date: Tue, 6 Apr 2010 14:12:28 -0600 In-Reply-To: <1270584223.3949.57.camel@iscandar.digidescorp.com> References: <1270502993.9013.36.camel@edumazet-laptop> <2fefb2a2-d0dc-461d-ac8c-3e7d177b7cf8@VA3EHSMHS032.ehs.local> <1270573233.2081.47.camel@edumazet-laptop> <1270584223.3949.57.camel@iscandar.digidescorp.com> From: John Linn To: , Message-ID: <2913b19f-188e-475e-8f16-d3ad94614a08@VA3EHSMHS030.ehs.local> Cc: Eric Dumazet , linuxppc-dev@ozlabs.org, netdev@vger.kernel.org, John Tyner , michal.simek@petalogix.com, john.williams@petalogix.com List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , > -----Original Message----- > From: Steven J. Magnani [mailto:steve@digidescorp.com] > Sent: Tuesday, April 06, 2010 2:04 PM > To: grant.likely@secretlab.ca > Cc: John Linn; Eric Dumazet; netdev@vger.kernel.org; linuxppc-dev@ozlabs.org; > jwboyer@linux.vnet.ibm.com; john.williams@petalogix.com; michal.simek@petalogix.com; John Tyner > Subject: Re: [PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver > = > On Tue, 2010-04-06 at 12:53 -0600, Grant Likely wrote: > = > > Hold on.... BUFFER_ALIGN is being used to align the DMA buffer on a > > cache line boundary. I don't think netdev_alloc_skb() makes any > > guarantees about how the start of the IP header lines up against cache > > line boundaries. The amount of padding needed is not known until an > > skbuff is obtained from netdev_alloc_skb(), and > > netdev_alloc_skb_ip_align() can only handle a fixed size padding, > > > > It doesn't look like netdev_alloc_skb_ip_align() is the right thing in > > this regard. > = > __netdev_alloc_skb reserves NET_SKB_PAD bytes which gets us cacheline > alignment on Microblaze. From include/linux/skbuff.h: > = Good find. I'll give it a test on MicroBlaze and PowerPC. > /* > * The networking layer reserves some headroom in skb data (via > * dev_alloc_skb). This is used to avoid having to reallocate skb data > when > * the header has to grow. In the default case, if the header has to > grow > * 32 bytes or less we avoid the reallocation. > * > * Unfortunately this headroom changes the DMA alignment of the > resulting > * network packet. As for NET_IP_ALIGN, this unaligned DMA is expensive > * on some architectures. An architecture can override this value, > * perhaps setting it to a cacheline in size (since that will maintain > * cacheline alignment of the DMA). It must be a power of 2. > * > * Various parts of the networking layer expect at least 32 bytes of > * headroom, you should not reduce this. > */ > #ifndef NET_SKB_PAD > #define NET_SKB_PAD 32 > #endif > = > If this doesn't work for some of the PPC variants with larger cache > lines, maybe one of the PPC header files needs to define NET_SKB_PAD? Looks like it is defined in system.h in powerpc so that it works. > And if we want to guard against possible future changes to the default > NET_SKB_PAD breaking Microblaze operation, maybe one of its headers > should define NET_SKB_PAD as well? Good idea, we can add that to system.h for MicroBlaze also. Thanks, John > = > ------------------------------------------------------------------------ > Steven J. Magnani "I claim this network for MARS! > www.digidescorp.com Earthling, return my space modulator!" > = > #include > = > = > = This email and any attachments are intended for the sole use of the named r= ecipient(s) and contain(s) confidential information that may be proprietary= , privileged or copyrighted under applicable law. If you are not the intend= ed recipient, do not read, copy, or forward this email message or any attac= hments. Delete this email message and any attachments immediately.