netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brice Goglin <brice@myri.com>
To: Anton Blanchard <anton@samba.org>
Cc: netdev@vger.kernel.org, gallatin@myri.com,
	linux-kernel@vger.kernel.org, benh@kernel.crashing.org
Subject: Re: [PATCH 3/4] myri10ge - Driver core
Date: Wed, 24 May 2006 10:04:28 +0200	[thread overview]
Message-ID: <4474138C.2050705@myri.com> (raw)
In-Reply-To: <20060523153928.GB5938@krispykreme>

Anton Blanchard wrote:
>> +/*
>> + * Set of routunes to get a new receive buffer.  Any buffer which
>> + * crosses a 4KB boundary must start on a 4KB boundary due to PCIe
>> + * wdma restrictions. We also try to align any smaller allocation to
>> + * at least a 16 byte boundary for efficiency.  We assume the linux
>> + * memory allocator works by powers of 2, and will not return memory
>> + * smaller than 2KB which crosses a 4KB boundary.  If it does, we fall
>> + * back to allocating 2x as much space as required.
>> + *
>> + * We intend to replace large (>4KB) skb allocations by using
>> + * pages directly and building a fraglist in the near future.
>> + */
>>     
>
> You go to a lot of trouble to align things. One thing on ppc64 is that
> we really want to start all DMA writes on a cacheline boundary. We
> enforce that in network drivers by making NET_IP_ALIGN = 0 and having
> the drivers do:
>
> skb_reserve(skb, NET_IP_ALIGN);
>
> It sounds like your small allocations will be only aligned to 16 bytes.
>   

We didn't get any ppc64 with PCI-E to run Linux so far. What performance
drop should we expect with our current code ?

> Id suggest using the dma API instead of the pci API. We have seen
> machines in the field that have failed large pci_alloc_consistent calls
> because it always asks for GFP_ATOMIC memory (it presumes the worst).
> The dma API allows you to pass a GFP_ flag in which will have a much
> better chance of succeeding when you dont need GFP_ATOMIC memory.
>   

Good idea, thanks,

>> +#ifdef CONFIG_MTRR
>> +	mgp->mtrr = mtrr_add(mgp->iomem_base, mgp->board_span,
>> +			     MTRR_TYPE_WRCOMB, 1);
>> +#endif
>>     
> ...
>   
>> +	mgp->sram = ioremap(mgp->iomem_base, mgp->board_span);
>>     
>
> Not sure how we are meant to specify write through in drivers. Any ideas Ben?
>   

I am not sure what you mean.
The only ppc64 with PCI-E that we have seen so far (a G5) couldn't do
write combining according to Apple.

Thanks,
Brice


  reply	other threads:[~2006-05-24  8:05 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-17 22:02 [PATCH 0/4] myri10ge - Myri-10G Ethernet driver - v2 Brice Goglin
2006-05-17 22:03 ` [PATCH 1/4] myri10ge - Revive pci_find_ext_capability Brice Goglin
2006-05-17 22:04 ` [PATCH 2/4] myri10ge - Driver header files Brice Goglin
2006-05-17 22:28   ` Randy.Dunlap
2006-05-18 23:36     ` Brice Goglin
2006-05-17 22:06 ` [PATCH 3/4] myri10ge - Driver core Brice Goglin
2006-05-17 22:36   ` Roland Dreier
2006-05-18 23:38     ` Brice Goglin
2006-05-17 23:08   ` Arnd Bergmann
2006-05-18 23:56     ` Brice Goglin
2006-05-19  1:55       ` Arnd Bergmann
2006-05-19  2:25         ` Brice Goglin
2006-05-19 10:00           ` Arnd Bergmann
2006-05-19 11:09             ` Andi Kleen
2006-05-19 15:48               ` Brice Goglin
2006-05-20  7:58                 ` Brice Goglin
2006-05-19 14:39     ` Brice Goglin
2006-05-19 23:15     ` Brice Goglin
2006-05-20  0:01       ` Andi Kleen
2006-05-23 15:39   ` Anton Blanchard
2006-05-24  8:04     ` Brice Goglin [this message]
2006-05-24 21:21       ` Anton Blanchard
2006-05-25  7:59       ` Benjamin Herrenschmidt
2006-05-25  9:07         ` Brice Goglin
2006-05-25  7:56     ` Benjamin Herrenschmidt
2006-05-26  9:49       ` Ingo Oeser
2006-05-26 10:02         ` Benjamin Herrenschmidt
2006-05-26 10:30           ` Jeff Garzik
2006-05-26 10:56             ` Benjamin Herrenschmidt
2006-05-17 22:07 ` [PATCH 4/4] myri10ge - Kconfig and Makefile Brice Goglin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4474138C.2050705@myri.com \
    --to=brice@myri.com \
    --cc=anton@samba.org \
    --cc=benh@kernel.crashing.org \
    --cc=gallatin@myri.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).