* [PATCH] Remove barriers from the SLB shadow buffer update
From: Michael Neuling @ 2007-08-24 6:58 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
After talking to an IBM POWER hypervisor design and development (PHYP)
guy, there seems to be no need for memory barriers when updating the SLB
shadow buffer provided we only update it from the current CPU, which we
do.
Also, these guys see no need in the future for these barriers.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
Tested on PHYP and BML.
paulus: As you mentioned, this is 2.6.24 material.
arch/powerpc/kernel/entry_64.S | 8 ++++----
arch/powerpc/mm/slb.c | 6 ++----
2 files changed, 6 insertions(+), 8 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/entry_64.S
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/entry_64.S
+++ linux-2.6-ozlabs/arch/powerpc/kernel/entry_64.S
@@ -385,15 +385,15 @@ BEGIN_FTR_SECTION
oris r0,r6,(SLB_ESID_V)@h
ori r0,r0,(SLB_NUM_BOLTED-1)@l
- /* Update the last bolted SLB */
+ /* Update the last bolted SLB. No write barriers are needed
+ * here, provided we only update the current CPU's SLB shadow
+ * buffer.
+ */
ld r9,PACA_SLBSHADOWPTR(r13)
li r12,0
std r12,SLBSHADOW_STACKESID(r9) /* Clear ESID */
- eieio
std r7,SLBSHADOW_STACKVSID(r9) /* Save VSID */
- eieio
std r0,SLBSHADOW_STACKESID(r9) /* Save ESID */
- eieio
slbie r6
slbie r6 /* Workaround POWER5 < DD2.1 issue */
Index: linux-2.6-ozlabs/arch/powerpc/mm/slb.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/mm/slb.c
+++ linux-2.6-ozlabs/arch/powerpc/mm/slb.c
@@ -59,14 +59,12 @@ static inline void slb_shadow_update(uns
{
/*
* Clear the ESID first so the entry is not valid while we are
- * updating it.
+ * updating it. No write barriers are needed here, provided
+ * we only update the current CPU's SLB shadow buffer.
*/
get_slb_shadow()->save_area[entry].esid = 0;
- smp_wmb();
get_slb_shadow()->save_area[entry].vsid = mk_vsid_data(ea, flags);
- smp_wmb();
get_slb_shadow()->save_area[entry].esid = mk_esid_data(ea, entry);
- smp_wmb();
}
static inline void slb_shadow_clear(unsigned long entry)
^ permalink raw reply
* Re: asm-ppc header issues when building ARCH=powerpc
From: Geert Uytterhoeven @ 2007-08-24 7:10 UTC (permalink / raw)
To: Brad Boyer; +Cc: linuxppc-dev@ozlabs.org list, Paul Mackerras, David Gibson
In-Reply-To: <20070823185632.GA3571@cynthia.pants.nu>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 904 bytes --]
On Thu, 23 Aug 2007, Brad Boyer wrote:
> Just as an extra note, the file drivers/macintosh/adb-iop.c is m68k only,
> so you should probably leave that alone as well. It probably doesn't need
> that header, but the change should really come from the 68k side of things.
Thanks, it's indeed not needed.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: asm-ppc header issues when building ARCH=powerpc
From: Kumar Gala @ 2007-08-24 7:24 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linuxppc-dev@ozlabs.org list, Paul Mackerras, David Gibson
In-Reply-To: <Pine.LNX.4.62.0708240909370.19123@pademelon.sonytel.be>
On Aug 24, 2007, at 2:10 AM, Geert Uytterhoeven wrote:
> On Thu, 23 Aug 2007, Brad Boyer wrote:
>> Just as an extra note, the file drivers/macintosh/adb-iop.c is
>> m68k only,
>> so you should probably leave that alone as well. It probably
>> doesn't need
>> that header, but the change should really come from the 68k side
>> of things.
>
> Thanks, it's indeed not needed.
If its ok that the removal comes from my patchset that would be
great. I'm tired of re-spinning these patches at this point ;)
- k
^ permalink raw reply
* Re: asm-ppc header issues when building ARCH=powerpc
From: Geert Uytterhoeven @ 2007-08-24 7:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, Paul Mackerras, David Gibson
In-Reply-To: <9185AE94-7B04-4DC7-8B9D-C92D13AC6D6F@kernel.crashing.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1247 bytes --]
On Fri, 24 Aug 2007, Kumar Gala wrote:
> On Aug 24, 2007, at 2:10 AM, Geert Uytterhoeven wrote:
> > On Thu, 23 Aug 2007, Brad Boyer wrote:
> > > Just as an extra note, the file drivers/macintosh/adb-iop.c is m68k only,
> > > so you should probably leave that alone as well. It probably doesn't need
> > > that header, but the change should really come from the 68k side of
> > > things.
> >
> > Thanks, it's indeed not needed.
>
> If its ok that the removal comes from my patchset that would be great. I'm
> tired of re-spinning these patches at this point ;)
Sure, less work for me! ;-)
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* little endian page mapping on PQ3
From: Jose Almeida @ 2007-08-24 7:59 UTC (permalink / raw)
To: Linuxppc-embedded
Hi all,
Looking at PQ3 documentation, it looks like there is a way to select
on a page basis if we would like to map one particular page in BIG or
LITTLE endian.
This is a very nice feature when you need to exchange some data
between a PC and a PQ3 target.
I am wondering if someone have already tryed this PQ3 feature ?
I guess this would require some kind of hook in the kernel ...
Any clue ?
Thanks - Jose
^ permalink raw reply
* RE: little endian page mapping on PQ3
From: Joyeau Sylvain @ 2007-08-24 11:40 UTC (permalink / raw)
To: Jose Almeida, Linuxppc-embedded
Jose,
You are right, PQ3 supports endianess choice on a per page basis.=20
Without any hook in Linux, you can remap physical address range (but =
RAM), by calling __ioremap() with the "_PAGE_ENDIAN" bit set in the =
flags.
--
sj
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+sylvain.joyeau=3Dthomson.net@ozlabs.or
> g=20
> [mailto:linuxppc-embedded-bounces+sylvain.joyeau=3Dthomson.net@o
> zlabs.org] On Behalf Of Jose Almeida
> Sent: vendredi 24 ao=FBt 2007 09:59
> To: Linuxppc-embedded@ozlabs.org
> Subject: little endian page mapping on PQ3
>=20
> Hi all,
>=20
> Looking at PQ3 documentation, it looks like there is a way to select
> on a page basis if we would like to map one particular page in BIG or
> LITTLE endian.
> This is a very nice feature when you need to exchange some data
> between a PC and a PQ3 target.
>=20
> I am wondering if someone have already tryed this PQ3 feature ?
> I guess this would require some kind of hook in the kernel ...
>=20
> Any clue ?
>=20
> Thanks - Jose
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
^ permalink raw reply
* Re: little endian page mapping on PQ3
From: Jose Almeida @ 2007-08-24 13:08 UTC (permalink / raw)
To: Joyeau Sylvain; +Cc: Linuxppc-embedded
In-Reply-To: <B00307ADBC68954AA8D6FB3AC8FD66F30141DE36@rennsmail05.eu.thmulti.com>
[-- Attachment #1: Type: text/html, Size: 3387 bytes --]
^ permalink raw reply
* Re: little endian page mapping on PQ3
From: Clemens Koller @ 2007-08-24 13:19 UTC (permalink / raw)
To: Jose Almeida; +Cc: Linuxppc-embedded
In-Reply-To: <46CE8FD5.2060609@sysgo.fr>
Hi, Jose!
Jose Almeida schrieb:
> Hi all,
>
> Looking at PQ3 documentation, it looks like there is a way to select
> on a page basis if we would like to map one particular page in BIG or
> LITTLE endian.
> This is a very nice feature when you need to exchange some data
> between a PC and a PQ3 target.
I would be interested, however cannot spend time right now to work
on that subject.
> I am wondering if someone have already tryed this PQ3 feature ?
> I guess this would require some kind of hook in the kernel ...
Just some random bits I found in the web:
http://developer.apple.com/documentation/Hardware/DeviceManagers/pci_srvcs/pci_cards_drivers/PCI_BOOK.250.html
The Interesting part is:
"Thus, the address swizzle is completely transparent to software."
So, I would just try to setup some memory mapping and turn on little endian
mode to access that area... MMMV. Just a guess.
Regards,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* Re: [PATCH] Remove barriers from the SLB shadow buffer update
From: Josh Boyer @ 2007-08-23 20:36 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, paulus
In-Reply-To: <3992.1187938717@neuling.org>
On Fri, 2007-08-24 at 16:58 +1000, Michael Neuling wrote:
> After talking to an IBM POWER hypervisor design and development (PHYP)
> guy, there seems to be no need for memory barriers when updating the SLB
> shadow buffer provided we only update it from the current CPU, which we
> do.
>
> Also, these guys see no need in the future for these barriers.
Does this result in a significant performance gain? I'm just curious.
josh
^ permalink raw reply
* RFC: issues concerning the next NAPI interface
From: Jan-Bernd Themann @ 2007-08-24 13:59 UTC (permalink / raw)
To: netdev
Cc: Thomas Klein, Jan-Bernd Themann, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
Hi,
when I tried to get the eHEA driver working with the new interface,
the following issues came up.
1) The current implementation of netif_rx_schedule, netif_rx_complete
=A0 =A0and the net_rx_action have the following problem: netif_rx_schedule
=A0 =A0sets the NAPI_STATE_SCHED flag and adds the NAPI instance to the pol=
l_list.
=A0 =A0netif_rx_action checks NAPI_STATE_SCHED, if set it will add the devi=
ce
=A0 =A0to the poll_list again (as well). netif_rx_complete clears the NAPI_=
STATE_SCHED.
=A0 =A0If an interrupt handler calls netif_rx_schedule on CPU 2
=A0 =A0after netif_rx_complete has been called on CPU 1 (and the poll funct=
ion=20
=A0 =A0has not returned yet), the NAPI instance will be added twice to the=
=20
=A0 =A0poll_list (by netif_rx_schedule and net_rx_action). Problems occur w=
hen=20
=A0 =A0netif_rx_complete is called twice for the device (BUG() called)
2) If an ethernet chip supports multiple receive queues, the queues are=20
=A0 =A0currently all processed on the CPU where the interrupt comes in. This
=A0 =A0is because netif_rx_schedule will always add the rx queue to the CPU=
's
=A0 =A0napi poll_list. The result under heavy presure is that all queues wi=
ll
=A0 =A0gather on the weakest CPU (with highest CPU load) after some time as=
they
=A0 =A0will stay there as long as the entire queue is emptied. On SMP syste=
ms=20
=A0 =A0this behaviour is not desired. It should also work well without inte=
rrupt
=A0 =A0pinning.
=A0 =A0It would be nice if it is possible to schedule queues to other CPU's=
, or
=A0 =A0at least to use interrupts to put the queue to another cpu (not nice=
for=20
=A0 =A0as you never know which one you will hit).=20
=A0 =A0I'm not sure how bad the tradeoff would be.
3) On modern systems the incoming packets are processed very fast. Especial=
ly
=A0 =A0on SMP systems when we use multiple queues we process only a few pac=
kets
=A0 =A0per napi poll cycle. So NAPI does not work very well here and the in=
terrupt=20
=A0 =A0rate is still high. What we need would be some sort of timer polling=
mode=20
=A0 =A0which will schedule a device after a certain amount of time for high=
load=20
=A0 =A0situations. With high precision timers this could work well. Current
=A0 =A0usual timers are too slow. A finer granularity would be needed to ke=
ep the
latency down (and queue length moderate).
What do you think?
Thanks,
Jan-Bernd
^ permalink raw reply
* [linux kernel 2.6.19] ethernet driver for Marvell bridge GT-64260
From: joachim.bader @ 2007-08-24 13:51 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1475 bytes --]
Hello everybody,
I continue the work of ThomasB to get a linux kernel 2.6.19 up and running
on a PPC750FX based platform using a GT-64260.
From Thomas I got a patched mv643xx_eth driver which is ported to support
the 64260, too.
Now the driver is integrated and runs complete through initialisation
bringing up an eth0 device.
The initialisation seams to be ok (no error messages), the device is up
and routing information is setup.
Now I try to ping a remote station but I receive nothing and I get no
feedback from the remote compter.
As soon as I turn of the net interface (ifconfig eth0 down) I get the
message "Tx time out or no link?)
Is there anything else I can check? Any idea what may cause this problem?
Thanks a lot for your help
Joachim
_______________________________________________________________________________________________________________________
Der Inhalt dieser E-Mail ist für den Absender rechtlich nicht verbindlich.
Informieren Sie uns bitte, wenn Sie diese E-Mail fälschlicherweise erhalten haben (Fax: +49-69-5805-1399). Bitte löschen Sie in diesem Fall die Nachricht. Jede Form der weiteren Benutzung ist untersagt.
The content of this e-mail is not legally binding upon the sender.
If this e-mail was transmitted to you by error, then please inform us accordingly (Fax: +49-69-5805-1399). In such case you are requested to erase the message. Any use of such e-mail message is strictly prohibited.
[-- Attachment #2: Type: text/html, Size: 2375 bytes --]
^ permalink raw reply
* Re: [PATCH 05/20] bootwrapper: flatdevtree fixes
From: Scott Wood @ 2007-08-24 14:48 UTC (permalink / raw)
To: linuxppc-dev, paulus
In-Reply-To: <20070824010122.GA7281@localhost.localdomain>
On Fri, Aug 24, 2007 at 11:01:22AM +1000, David Gibson wrote:
> On Thu, Aug 23, 2007 at 12:48:30PM -0500, Scott Wood wrote:
> > It's likely to be ugly no matter what, though I'll try to come up with
> > something slightly nicer. If I were doing this code from scratch, I'd
> > probably liven the tree first and reflatten it to pass to the kernel.
>
> Eh, probably not worth bothering doing an actual implementation at
> this stage - I'll have to redo it for libfdt anyway.
Too late, I already wrote it -- it wasn't as bad as I thought it would
be.
> flatdevtree uses some of the information it caches in the phandle
> context stuff to remember who's the parent of a node. libfdt uses raw
> offsets into the structure, so the *only* way to implement
> get_parent() is to rescan the dt from the beginning, keeping track of
> parents until reaching the given node.
What is the benefit of doing it that way?
-Scott
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: akepner @ 2007-08-24 15:37 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
In-Reply-To: <200708241559.17055.ossthema@de.ibm.com>
On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
> .......
> 3) On modern systems the incoming packets are processed very fast. Especially
> on SMP systems when we use multiple queues we process only a few packets
> per napi poll cycle. So NAPI does not work very well here and the interrupt
> rate is still high. What we need would be some sort of timer polling mode
> which will schedule a device after a certain amount of time for high load
> situations. With high precision timers this could work well. Current
> usual timers are too slow. A finer granularity would be needed to keep the
> latency down (and queue length moderate).
>
We found the same on ia64-sn systems with tg3 a couple of years
ago. Using simple interrupt coalescing ("don't interrupt until
you've received N packets or M usecs have elapsed") worked
reasonably well in practice. If your h/w supports that (and I'd
guess it does, since it's such a simple thing), you might try
it.
--
Arthur
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: Jan-Bernd Themann @ 2007-08-24 15:47 UTC (permalink / raw)
To: akepner
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
In-Reply-To: <20070824153703.GN5592@sgi.com>
Hi,
On Friday 24 August 2007 17:37, akepner@sgi.com wrote:
> On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
> > .......
> > 3) On modern systems the incoming packets are processed very fast. Espe=
cially
> > =A0 =A0on SMP systems when we use multiple queues we process only a few=
packets
> > =A0 =A0per napi poll cycle. So NAPI does not work very well here and th=
e interrupt=20
> > =A0 =A0rate is still high. What we need would be some sort of timer pol=
ling mode=20
> > =A0 =A0which will schedule a device after a certain amount of time for =
high load=20
> > =A0 =A0situations. With high precision timers this could work well. Cur=
rent
> > =A0 =A0usual timers are too slow. A finer granularity would be needed t=
o keep the
> > latency down (and queue length moderate).
> >=20
>=20
> We found the same on ia64-sn systems with tg3 a couple of years=20
> ago. Using simple interrupt coalescing ("don't interrupt until=20
> you've received N packets or M usecs have elapsed") worked=20
> reasonably well in practice. If your h/w supports that (and I'd=20
> guess it does, since it's such a simple thing), you might try=20
> it.
>=20
I don't see how this should work. Our latest machines are fast enough that =
they
simply empty the queue during the first poll iteration (in most cases).
Even if you wait until X packets have been received, it does not help for
the next poll cycle. The average number of packets we process per poll queue
is low. So a timer would be preferable that periodically polls the=20
queue, without the need of generating a HW interrupt. This would allow us
to wait until a reasonable amount of packets have been received in the mean=
time
to keep the poll overhead low. This would also be useful in combination
with LRO.
Regards,
Jan-Bernd
^ permalink raw reply
* Re: little endian page mapping on PQ3
From: David Hawkins @ 2007-08-24 15:49 UTC (permalink / raw)
To: Jose Almeida; +Cc: Joyeau Sylvain, Linuxppc-embedded
In-Reply-To: <46CED851.70002@sysgo.fr>
Hi Jose,
> I want to do using an mmap() entry point in a driver, in order to map
> this to the user. Of course in that case ioremap() does not work.
>
> Any Clue ?
>
I used the little-endian flag on the Yosemite board (440EP)
to test what the flag did.
http://www.ovro.caltech.edu/~dwh/correlator/pdf/LNX-762-Hawkins.pdf
http://www.ovro.caltech.edu/~dwh/correlator/software/driver_design.tar.gz
Look at the mmap function in pci_io.c.
/* PowerPC endian control
* - default is cleared, big-endian
*/
#ifdef _PAGE_ENDIAN
if (bar->little_endian) {
pgprot_val(vma->vm_page_prot) |= _PAGE_ENDIAN;
} else {
pgprot_val(vma->vm_page_prot) &= ~_PAGE_ENDIAN;
}
if (pgprot_val(vma->vm_page_prot) & _PAGE_ENDIAN) {
LOG_DEBUG("_PAGE_ENDIAN is set\n");
} else {
LOG_DEBUG("_PAGE_ENDIAN is not set\n");
}
#endif
It might be the same for the PQ3 ... at least it'll be
pretty similar.
Dave
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: Stephen Hemminger @ 2007-08-24 15:52 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Marcus, Jan-Bernd Themann, netdev, linux-kernel,
Christoph Raisch, linux-ppc, akepner, Eder, Stefan Roscher
In-Reply-To: <200708241747.16592.ossthema@de.ibm.com>
On Fri, 24 Aug 2007 17:47:15 +0200
Jan-Bernd Themann <ossthema@de.ibm.com> wrote:
> Hi,
>=20
> On Friday 24 August 2007 17:37, akepner@sgi.com wrote:
> > On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
> > > .......
> > > 3) On modern systems the incoming packets are processed very fast. Es=
pecially
> > > =C2=A0 =C2=A0on SMP systems when we use multiple queues we process on=
ly a few packets
> > > =C2=A0 =C2=A0per napi poll cycle. So NAPI does not work very well her=
e and the interrupt=20
> > > =C2=A0 =C2=A0rate is still high. What we need would be some sort of t=
imer polling mode=20
> > > =C2=A0 =C2=A0which will schedule a device after a certain amount of t=
ime for high load=20
> > > =C2=A0 =C2=A0situations. With high precision timers this could work w=
ell. Current
> > > =C2=A0 =C2=A0usual timers are too slow. A finer granularity would be =
needed to keep the
> > > latency down (and queue length moderate).
> > >=20
> >=20
> > We found the same on ia64-sn systems with tg3 a couple of years=20
> > ago. Using simple interrupt coalescing ("don't interrupt until=20
> > you've received N packets or M usecs have elapsed") worked=20
> > reasonably well in practice. If your h/w supports that (and I'd=20
> > guess it does, since it's such a simple thing), you might try=20
> > it.
> >=20
>=20
> I don't see how this should work. Our latest machines are fast enough tha=
t they
> simply empty the queue during the first poll iteration (in most cases).
> Even if you wait until X packets have been received, it does not help for
> the next poll cycle. The average number of packets we process per poll qu=
eue
> is low. So a timer would be preferable that periodically polls the=20
> queue, without the need of generating a HW interrupt. This would allow us
> to wait until a reasonable amount of packets have been received in the me=
antime
> to keep the poll overhead low. This would also be useful in combination
> with LRO.
>=20
You need hardware support for deferred interrupts. Most devices have it (e1=
000, sky2, tg3)
and it interacts well with NAPI. It is not a generic thing you want done by=
the stack,
you want the hardware to hold off interrupts until X packets or Y usecs hav=
e expired.
The parameters for controlling it are already in ethtool, the issue is find=
ing a good
default set of values for a wide range of applications and architectures. M=
aybe some
heuristic based on processor speed would be a good starting point. The dyna=
mic irq
moderation stuff is not widely used because it is too hard to get right.
--=20
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* RE: Only one phy can be accessed through ioctls to a socket (patch available)
From: DI BACCO ANTONIO - technolabs @ 2007-08-24 15:56 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-embedded
In-Reply-To: <B999A34D-92BD-41D1-852A-45C4E2258712@freescale.com>
> I'd certainly be interested in seeing it.
There is not much to see, only few lines in phy_device.c:
/* get_existing_phy_device:
*
* description: returns a phy device with the given address
* if it exists
*/
static int phy_compare_addr(struct device *dev, void *data)
{
return (*((int*)data) =3D=3D to_phy_device(dev)->addr) ? 1 : 0;
}
struct phy_device * get_existing_phy_device(int addr)
{
struct bus_type *bus =3D &mdio_bus_type;
struct phy_device *phydev;
struct device *d;
/* Search the list of PHY devices on the mdio bus for the
* PHY with the requested name */
d =3D bus_find_device(bus, NULL, (void *) &addr,
phy_compare_addr);
if (d)
{
phydev =3D to_phy_device(d);
return phydev;
}
return NULL;
}
EXPORT_SYMBOL(get_existing_phy_device);
And a small change in fs_enet-main.c :
static int fs_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
{
struct fs_enet_private *fep =3D netdev_priv(dev);
struct mii_ioctl_data *mii =3D (struct mii_ioctl_data
*)&rq->ifr_data;
struct phy_device* phydev =3D fep->phydev;
unsigned long flags;
int rc;
if (!netif_running(dev) && (phydev->addr =3D=3D mii->phy_id))
return -EINVAL;
if ((phydev->addr !=3D mii->phy_id))
{
struct phy_device* d;
if ((d =3D get_existing_phy_device(mii->phy_id)) !=3D NULL)
phydev =3D d;
else
return -ENODEV;
}
spin_lock_irqsave(&fep->lock, flags);
rc =3D phy_mii_ioctl(phydev, mii, cmd);
spin_unlock_irqrestore(&fep->lock, flags);
return rc;
}
^ permalink raw reply
* Re: gdbserver and c++
From: khollan @ 2007-08-24 15:57 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <12282029.post@talk.nabble.com>
Any suggestions Im completely lost
--
View this message in context: http://www.nabble.com/gdbserver-and-c%2B%2B-tf4313806.html#a12315137
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* 8555CDS BSP on 8548CDS board
From: mike zheng @ 2007-08-24 16:00 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 206 bytes --]
Hi,
I was told Freescale's 8555CDS board is very similar to 8548CDS board. I
just wonder what exactly the differences are. can I just put the 8555CDS BSP
onto the 8548CDS board?
Thanks in advance,
Mike
[-- Attachment #2: Type: text/html, Size: 310 bytes --]
^ permalink raw reply
* 8555CDS BSP on 8548CDS board
From: mike zheng @ 2007-08-24 16:02 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 207 bytes --]
Hi,
I was told Freescale's 8555CDS board is very similar to 8548CDS board. I
just wonder what exactly the differences are. can I just put the 8555CDS BSP
onto the 8548CDS board?
Thanks in advance,
Mike
[-- Attachment #2: Type: text/html, Size: 356 bytes --]
^ permalink raw reply
* Re: [linux kernel 2.6.19] ethernet driver for Marvell bridge GT-64260
From: Dale Farnsworth @ 2007-08-24 16:13 UTC (permalink / raw)
To: joachim.bader, linuxppc-embedded
In-Reply-To: <OF2C2E8C6F.3860730F-ONC1257341.004B3D4B-C1257341.004C2882@diehl-gruppe.de>
> I continue the work of ThomasB to get a linux kernel 2.6.19 up and running
> on a PPC750FX based platform using a GT-64260.
> From Thomas I got a patched mv643xx_eth driver which is ported to support
> the 64260, too.
> Now the driver is integrated and runs complete through initialisation
> bringing up an eth0 device.
> The initialisation seams to be ok (no error messages), the device is up
> and routing information is setup.
> Now I try to ping a remote station but I receive nothing and I get no
> feedback from the remote compter.
> As soon as I turn of the net interface (ifconfig eth0 down) I get the
> message "Tx time out or no link?)
> Is there anything else I can check? Any idea what may cause this problem?
Steven Hill posted his patch series merging gt64260 ethernet support to
the netdev mailing list last month. You might look at:
http://lists.openwall.net/netdev/2007/07/19/22
and related patches.
The differences between 64260 and 64360 are so large that they are
unlikely to be merged into a single driver, but a separate driver
is a possibility if someone steps up to do the work.
-Dale
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: Linas Vepstas @ 2007-08-24 16:45 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
In-Reply-To: <200708241559.17055.ossthema@de.ibm.com>
On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
> 3) On modern systems the incoming packets are processed very fast. Especially
> on SMP systems when we use multiple queues we process only a few packets
> per napi poll cycle. So NAPI does not work very well here and the interrupt
> rate is still high.
I saw this too, on a system that is "modern" but not terribly fast, and
only slightly (2-way) smp. (the spidernet)
I experimented wih various solutions, none were terribly exciting. The
thing that killed all of them was a crazy test case that someone sprung on
me: They had written a worst-case network ping-pong app: send one
packet, wait for reply, send one packet, etc.
If I waited (indefinitely) for a second packet to show up, the test case
completely stalled (since no second packet would ever arrive). And if I
introduced a timer to wait for a second packet, then I just increased
the latency in the response to the first packet, and this was noticed,
and folks complained.
In the end, I just let it be, and let the system work as a busy-beaver,
with the high interrupt rate. Is this a wise thing to do? I was
thinking that, if the system is under heavy load, then the interrupt
rate would fall, since (for less pathological network loads) more
packets would queue up before the poll was serviced. But I did not
actually measure the interrupt rate under heavy load ...
--linas
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: David Stevens @ 2007-08-24 16:50 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel,
Christoph Raisch, netdev-owner, linux-ppc, akepner, Marcus Eder,
Jan-Bernd Themann, Stefan Roscher
In-Reply-To: <20070824085203.42f4305c@freepuppy.rosehill.hemminger.net>
Stephen Hemminger <shemminger@linux-foundation.org> wrote on 08/24/2007
08:52:03 AM:
>
> You need hardware support for deferred interrupts. Most devices have it
> (e1000, sky2, tg3)
> and it interacts well with NAPI. It is not a generic thing you want done
by the stack,
> you want the hardware to hold off interrupts until X packets or Y usecs
have expired.
For generic hardware that doesn't support it, couldn't you use an
estimater
and adjust the timer dynamicly in software based on sampled values? Switch
to per-packet
interrupts when the receive rate is low...
Actually, that's how I thought NAPI worked before I found out
otherwise (ie,
before I looked :-)).
The hardware-accelerated one is essentially siloing as done by
ancient serial
devices on UNIX systems. If you had a tunable for a target count, and an
estimator
for the time interval, then switch to per-packet when the estimator
exceeds a tunable
max threshold (and also, I suppose, if you near overflowing the ring on
the min
timer granularity), you get almost all of it, right?
Problem is if it increases rapidly, you may drop packets before
you notice
that the ring is full in the current estimated interval.
+-DLS
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: Linas Vepstas @ 2007-08-24 16:51 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel,
Christoph Raisch, linux-ppc, Jan-Bernd Themann, Eder, akepner,
Stefan Roscher, Marcus
In-Reply-To: <20070824085203.42f4305c@freepuppy.rosehill.hemminger.net>
On Fri, Aug 24, 2007 at 08:52:03AM -0700, Stephen Hemminger wrote:
>
> You need hardware support for deferred interrupts. Most devices have it (e1000, sky2, tg3)
> and it interacts well with NAPI. It is not a generic thing you want done by the stack,
> you want the hardware to hold off interrupts until X packets or Y usecs have expired.
Just to be clear, in the previous email I posted on this thread, I
described a worst-case network ping-pong test case (send a packet, wait
for reply), and found out that a deffered interrupt scheme just damaged
the performance of the test case. Since the folks who came up with the
test case were adamant, I turned off the defferred interrupts.
While defferred interrupts are an "obvious" solution, I decided that
they weren't a good solution. (And I have no other solution to offer).
--linas
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: Rick Jones @ 2007-08-24 17:07 UTC (permalink / raw)
To: Linas Vepstas
Cc: Thomas Klein, Jan-Bernd Themann, Stefan Roscher, netdev,
linux-kernel, Christoph Raisch, linux-ppc, Jan-Bernd Themann,
Eder, akepner, Stephen Hemminger, Marcus
In-Reply-To: <20070824165110.GH4282@austin.ibm.com>
> Just to be clear, in the previous email I posted on this thread, I
> described a worst-case network ping-pong test case (send a packet, wait
> for reply), and found out that a deffered interrupt scheme just damaged
> the performance of the test case. Since the folks who came up with the
> test case were adamant, I turned off the defferred interrupts.
> While defferred interrupts are an "obvious" solution, I decided that
> they weren't a good solution. (And I have no other solution to offer).
Sounds exactly like the default netperf TCP_RR test and any number of other
benchmarks. The "send a request, wait for reply, send next request, etc etc
etc" is a rather common application behaviour afterall.
rick jones
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox