* RE: 8xx_io/enet.c
[not found] <IGEFJKJNHJDCBKALBJLLMELCFIAA.joakim.tjernlund@lumentis.se>
@ 2002-12-10 17:52 ` Stephan Linke
0 siblings, 0 replies; 5+ messages in thread
From: Stephan Linke @ 2002-12-10 17:52 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: Linuxppc-Embedded
Hi,
> -----Original Message-----
> From: Joakim Tjernlund [mailto:joakim.tjernlund@lumentis•se]
> Sent: Dienstag, 10. Dezember 2002 16:47
> To: Stephan Linke
> Subject: RE: 8xx_io/enet.c
>
>
> >
> > Hi,
> >
> > just checked the mailing list for the patches. Looks like you
> mean the 'copy
> > large buffers' patch.
> > I took the second version and applied it to fec.c too.
> > It works fine on both devices. The only thing that confused me was the
> > discussion about the possibility of inconsistent data.
>
> Thats the one. However there is a small bug in version 2 w.r.t when the
> invalidate_dcache_range call is made. In the second version the
> call is made
> AFTER the buffer has been received as opposed in my first version
> where the
> call is made BEFORE handing over the buffer to the CPM. That may in some
> rare case corrupt the packet. See
> http://lists.linuxppc.org/linuxppc-embedded/200211/msg00120.html
>
> This is only relevant for 8xx, 82xx don't have to invalidate.
>
> > But we didn't noticed
> > any performance impact when testing it with IP packets.
>
> Didn't you get any performace increase after appling my patch?
> If you did, could you send me your performace numbers?
> Did you try the first version also? If so,any performance
> difference compared with version 2?
>
> Jocke
Indeed we had a better performance with the patch applied to fec.c
(100base-Tx). Unfortunately I don't have the results at the moment. At
enet.c I didn't noticed mutch of a difference since handling 10base-T
traffic isn't that mutch of a problem at the moment and I didn't spend time
to figure out the exact CPU load.
I remember that someone said he had an performance impact at small packets.
I didn't noticed any (even though there must be a slight on caused by the
additinal if-statement).
I can post some of our results results after I did some more tests but that
may take a while since I am buisy with other stuff at the moment.
Stephan
>
> PS.
> Any perticular reason not to cc the embedded list also? Others would
> probably be intressted also.
>
Well, there is a 'reason'. I simply didn't payed attention to the fact that
a simple reply doesn't reply to the list.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <IGEFJKJNHJDCBKALBJLLGEKOFIAA.joakim.tjernlund@lumentis.se>]
* RE: 8xx_io/enet.c
[not found] <IGEFJKJNHJDCBKALBJLLGEKOFIAA.joakim.tjernlund@lumentis.se>
@ 2002-12-10 15:02 ` Stephan Linke
0 siblings, 0 replies; 5+ messages in thread
From: Stephan Linke @ 2002-12-10 15:02 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: Linuxppc-Embedded
Hi Joakim,
> > Since the errors are reported on packet base it is always the last
packed
> > that get's corrupted. (I think it's like this: when there are no more
> > buffers the CPM simply continues writing on the current buffer causing
this
> > problem).
>
> I think not, once the CPM has received a packet in a BD, it
> closes that BD and
> will not modify that BD until you tell the CPM its free again. Atleast
> this should be the case for the SCC, don't know if the FEC is supposed
> to do the same
>
we are using the one in the 2.4.18 kernel (hardhead). Sorry I don't actualy
know wich patch. :(
But I recall that we had this problem with fec.c while our CPU was under
heavy load. But I think it's the same situation on enet.c.
Finaly you are right. SCCE_ENET_BSY dosn't cause such problems. At the FEC
there is no BSY interrupt event. There's only BD_ENET_RX_OV signaling a
buffer overflow. Since that is an error condition the buffer has to be
discarded leading to the condition I tried to describe.
It looks like BD_ENET_RX_OV occures in enet.c ONLY for 'oversized' frames.
On FEC it occures on missing BD's too cuasing that stupid behavior.
I didn't expect that mutch of a difference. Sorry.
Stephan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: 8xx_io/enet.c
@ 2002-12-10 12:03 Kári Davíðsson
0 siblings, 0 replies; 5+ messages in thread
From: Kári Davíðsson @ 2002-12-10 12:03 UTC (permalink / raw)
To: joakim.tjernlund, linuxppc-embedded
Duhhh, I was not even running with CONFIG_ENET_BIG_BUFFERS enabled.
Enabling this got rid of the error..
Regarding your patch, then 20% throughput increase looks very tempting 8-)....
Thanks and sorry for the noise,
K.D.
> -----Original Message-----
> From: Joakim Tjernlund [mailto:joakim.tjernlund@lumentis•se]
> Sent: 10. desember 2002 10:47
> To: Kári Davíðsson; linuxppc-embedded@lists•linuxppc.org
> Subject: RE: 8xx_io/enet.c
>
>
> >
> > Hello,
> >
> > I am hitting the following code (i.e. the printk() is
> reached) in the interrupt handler for the ethernet on a custom 823e
> > board in arch/ppc/8xx_io/enet.c
> >
> > /* Check for receive busy, i.e. packets coming but no place to
> > * put them. This "can't happen" because the receive interrupt
> > * is tossing previous frames.
> > */
> > if (int_events & SCCE_ENET_BSY) {
> > cep->stats.rx_dropped++;
> > printk("CPM ENET: BSY can't happen.\n");
> > }
> >
> > Clearly this can happen, even though the comment sais otherwise.
> > This happens for a "high" datarate sunrpc interface
> operating over TCP/IP.
> >
> > Is it safe to ignore this "error" or is it a real bug that
> should be investigated?
>
> hmm, not sure it's safe to ignore this "error", chances are
> that receive
> gets "stuck" since there won't be any more RX interrupts
> until at least
> one RX BD is freed. Try increasing the number of RX
> BD's(CONFIG_ENET_BIG_BUFFERS,
> will increase TX and RX BD's to 32).
>
> You can also try my patch, see
> http://lists.linuxppc.org/linuxppc-embedded/200210/msg00272.html
> or
> http://lists.linuxppc.org/linuxppc-embedded/200210/msg00317.html
>
> Version 2 has a small bug(need to move the invalidate_dcache_range).
>
> It's still under verification so there may be problems with it.
>
> Jocke
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread* 8xx_io/enet.c
@ 2002-12-10 10:19 Kári Davíðsson
2002-12-10 10:46 ` 8xx_io/enet.c Joakim Tjernlund
0 siblings, 1 reply; 5+ messages in thread
From: Kári Davíðsson @ 2002-12-10 10:19 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am hitting the following code (i.e. the printk() is reached) in the interrupt handler for the ethernet on a custom 823e board in arch/ppc/8xx_io/enet.c
/* Check for receive busy, i.e. packets coming but no place to
* put them. This "can't happen" because the receive interrupt
* is tossing previous frames.
*/
if (int_events & SCCE_ENET_BSY) {
cep->stats.rx_dropped++;
printk("CPM ENET: BSY can't happen.\n");
}
Clearly this can happen, even though the comment sais otherwise.
This happens for a "high" datarate sunrpc interface operating over TCP/IP.
Is it safe to ignore this "error" or is it a real bug that should be investigated?
I am a litle unclear on the ethernet operation in whole.
Thanks, for any comment.
K.D.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread* RE: 8xx_io/enet.c
2002-12-10 10:19 8xx_io/enet.c Kári Davíðsson
@ 2002-12-10 10:46 ` Joakim Tjernlund
0 siblings, 0 replies; 5+ messages in thread
From: Joakim Tjernlund @ 2002-12-10 10:46 UTC (permalink / raw)
To: =?UNKNOWN?Q?K=E1ri_Dav=ED=F0sson?=, linuxppc-embedded
>
> Hello,
>
> I am hitting the following code (i.e. the printk() is reached) in the interrupt handler for the ethernet on a custom 823e
> board in arch/ppc/8xx_io/enet.c
>
> /* Check for receive busy, i.e. packets coming but no place to
> * put them. This "can't happen" because the receive interrupt
> * is tossing previous frames.
> */
> if (int_events & SCCE_ENET_BSY) {
> cep->stats.rx_dropped++;
> printk("CPM ENET: BSY can't happen.\n");
> }
>
> Clearly this can happen, even though the comment sais otherwise.
> This happens for a "high" datarate sunrpc interface operating over TCP/IP.
>
> Is it safe to ignore this "error" or is it a real bug that should be investigated?
hmm, not sure it's safe to ignore this "error", chances are that receive
gets "stuck" since there won't be any more RX interrupts until at least
one RX BD is freed. Try increasing the number of RX BD's(CONFIG_ENET_BIG_BUFFERS,
will increase TX and RX BD's to 32).
You can also try my patch, see
http://lists.linuxppc.org/linuxppc-embedded/200210/msg00272.html
or
http://lists.linuxppc.org/linuxppc-embedded/200210/msg00317.html
Version 2 has a small bug(need to move the invalidate_dcache_range).
It's still under verification so there may be problems with it.
Jocke
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2002-12-10 17:52 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <IGEFJKJNHJDCBKALBJLLMELCFIAA.joakim.tjernlund@lumentis.se>
2002-12-10 17:52 ` 8xx_io/enet.c Stephan Linke
[not found] <IGEFJKJNHJDCBKALBJLLGEKOFIAA.joakim.tjernlund@lumentis.se>
2002-12-10 15:02 ` 8xx_io/enet.c Stephan Linke
2002-12-10 12:03 8xx_io/enet.c Kári Davíðsson
-- strict thread matches above, loose matches on Subject: below --
2002-12-10 10:19 8xx_io/enet.c Kári Davíðsson
2002-12-10 10:46 ` 8xx_io/enet.c Joakim Tjernlund
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox