On Fri, 2006-05-26 at 06:30 -0400, Jeff Garzik wrote:
> Benjamin Herrenschmidt wrote:
> >>> No proper interface exposed, he'll have to do an #ifdef powerpc here or
> >>> such and use __ioremap with explicit page attributes. I have a hack to
> >>> do that automatically for memory covered by prefetch
Benjamin Herrenschmidt wrote:
No proper interface exposed, he'll have to do an #ifdef powerpc here or
such and use __ioremap with explicit page attributes. I have a hack to
do that automatically for memory covered by prefetchable PCI BARs when
mmap'ing from userland but not for kernel ioremap.
S
> > No proper interface exposed, he'll have to do an #ifdef powerpc here or
> > such and use __ioremap with explicit page attributes. I have a hack to
> > do that automatically for memory covered by prefetchable PCI BARs when
> > mmap'ing from userland but not for kernel ioremap.
>
> Stupid quest
Hi there,
Benjamin Herrenschmidt wrote:
> On Wed, 2006-05-24 at 01:39 +1000, Anton Blanchard wrote:
>
> > > +#ifdef CONFIG_MTRR
> > > + mgp->mtrr = mtrr_add(mgp->iomem_base, mgp->board_span,
> > > + MTRR_TYPE_WRCOMB, 1);
> > > +#endif
> > ...
> > > + mgp->sram = ioremap(mgp->
Benjamin Herrenschmidt wrote:
> On Wed, 2006-05-24 at 10:04 +0200, Brice Goglin wrote:
>
>
>> 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.
>>
>
> That is not 100% true I don't know what apple
On Wed, 2006-05-24 at 10:04 +0200, Brice Goglin wrote:
> 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.
That is not 100% true I don't know what apple had in mind. It also
depends in what slot you are.
On Wed, 2006-05-24 at 01:39 +1000, Anton Blanchard wrote:
> > +#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
Hi,
> We didn't get any ppc64 with PCI-E to run Linux so far. What performance
> drop should we expect with our current code ?
We have seen > 20% improvement on ppc64 running some networking
workloads when forcing 128 byte alignment (instead of 16 byte
alignment). DMA writes have to get cacheli
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
Hi Brice,
Sorry this review is based on your previous submission, I just noticed
it was still sitting in my mailbox. Please ignore anything that has been
fixed in the meantime :)
> +/*
> + * Set of routunes to get a new receive buffer. Any buffer which
> + * crosses a 4KB boundary must start on
Brice Goglin wrote:
> Andi Kleen wrote:
>
>> On Friday 19 May 2006 12:00, Arnd Bergmann wrote:
>>
>>
>>> On Friday 19 May 2006 04:25, Brice Goglin wrote:
>>>
>>>
dev_mc_upload() from net/core/dev_mcast.c does
spin_lock_bh(&dev->xmit_lock);
__dev_mc_upload(
> We have tried :) But there is no nice way to split this code. So I guess
> we will have to keep it like this.
You could shorten the #define names a bit (s/MYRI10GE_MCP_ETHER_/MCP_/) Then
everything
will fit better.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
Arnd Bergmann wrote:
>> +static int myri10ge_open(struct net_device *dev)
>>
>
> This function is too long to read easily.
>
Ok we have split it a little bit.
>> +/* allocate the host shadow rings */
>> +
>> +bytes = 8 + (MYRI10GE_MCP_ETHER_MAX_SEND_DESC_TSO + 4)
>> +* siz
Andi Kleen wrote:
> On Friday 19 May 2006 12:00, Arnd Bergmann wrote:
>
>> On Friday 19 May 2006 04:25, Brice Goglin wrote:
>>
>>> dev_mc_upload() from net/core/dev_mcast.c does
>>>
>>> spin_lock_bh(&dev->xmit_lock);
>>> __dev_mc_upload(dev);
>>>
>>> which calls dev->set_multicast_list(), w
> dev_err?
>
[...]
> Could probably use dev_printk.
>
When the interface name is known, we prefer having the message look like
"myri10ge: eth2: something" since it might be easier to read than
""myri10ge: 5:000e: something". The administrator usually knows the
name of the network inter
On Friday 19 May 2006 12:00, Arnd Bergmann wrote:
> On Friday 19 May 2006 04:25, Brice Goglin wrote:
> > dev_mc_upload() from net/core/dev_mcast.c does
> >
> > spin_lock_bh(&dev->xmit_lock);
> > __dev_mc_upload(dev);
> >
> > which calls dev->set_multicast_list(), which is
> > myri10ge_set_multica
On Friday 19 May 2006 04:25, Brice Goglin wrote:
> dev_mc_upload() from net/core/dev_mcast.c does
>
> spin_lock_bh(&dev->xmit_lock);
> __dev_mc_upload(dev);
>
> which calls dev->set_multicast_list(), which is
> myri10ge_set_multicast_list()
>
> which calls myri10ge_change_promisc
>
> which call
Arnd Bergmann wrote:
> Am Friday 19 May 2006 01:56 schrieb Brice Goglin:
>
>> This place is actually the only one where we don't want to use msleep.
>> This function (myri10ge_send_cmd) might be called from various context
>> (spinlocked or not) and pass orders to the NIC whose processing time
>
Am Friday 19 May 2006 01:56 schrieb Brice Goglin:
> This place is actually the only one where we don't want to use msleep.
> This function (myri10ge_send_cmd) might be called from various context
> (spinlocked or not) and pass orders to the NIC whose processing time
> depends a lot on the command.
Arnd Bergmann wrote:
>> +for (sleep_total = 0;
>> + sleep_total < (15 * 1000) && response->result == 0x;
>> + sleep_total += 10) {
>> +udelay(10);
>> +}
>>
>
> udelay does not sleep. If you want to sleep, use msleep instead.
>
This place is actua
Roland Dreier wrote:
> Still some suspicious uses of volatile here.
>
> For example:
>
>
>> +struct myri10ge_priv {
>>
> ...
>
>> +volatile u8 __iomem *sram;
>>
>
> as far as I can see this is always used with proper __iomem accessors,
> often with casts to strip the volatile a
Am Thursday 18 May 2006 00:06 schrieb Brice Goglin:
> +static char *myri10ge_fw_name = NULL;
> +static char *myri10ge_fw_unaligned = "myri10ge_ethp_z8e.dat";
> +static char *myri10ge_fw_aligned = "myri10ge_eth_z8e.dat";
> +static int myri10ge_ecrc_enable = 1;
> +static int myri10ge_max_intr_slots
Still some suspicious uses of volatile here.
For example:
> +struct myri10ge_priv {
...
> + volatile u8 __iomem *sram;
as far as I can see this is always used with proper __iomem accessors,
often with casts to strip the volatile anyway. So why is volatile needed?
I would suggest an audit
23 matches
Mail list logo
