[PATCH] arch/ppc/8xx_io/enet.c, version 3
Joakim Tjernlund wrote: >>>hmm, something is broken here. I can apply my patch to my local copy of >>>8xx_io/enet.c, BK version 1.24 just fine. Whats your version of enet.c? >>> >>> Jocke >>> >>> >>> >>> >>> >>> >>My version is the head of the BK tree, updated today. >> >> > >What version is that? > > Jocke > > > > > > > 2.4.21-pre4 Regards Pantelis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] arch/ppc/8xx_io/enet.c, version 3
Joakim Tjernlund wrote: >>>Hi Pantelis >>> >>>I don't follow you here. Didn't my patch apply cleanly against >>>linuxppc_2_4_devel? >>>I generated my patch against linuxppc_2_4_devel(I think). >>> >>> Jocke >>> >>Nope. >> >>Fails at hunks #7 and #8. >>Don't worry, it's trivial stuff. >> >>Here is enet.c.rej, if you want to check it. >> > >hmm, something is broken here. I can apply my patch to my local copy of >8xx_io/enet.c, BK version 1.24 just fine. Whats your version of enet.c? > > Jocke > > > > My version is the head of the BK tree, updated today. Regards Pantelis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] arch/ppc/8xx_io/enet.c, version 3
> >hmm, something is broken here. I can apply my patch to my local copy of > >8xx_io/enet.c, BK version 1.24 just fine. Whats your version of enet.c? > > > > Jocke > > > > > > > > > My version is the head of the BK tree, updated today. What version is that? Jocke ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] arch/ppc/8xx_io/enet.c, version 3
Joakim Tjernlund wrote: >>Hi guys, >> >>I have created a patch that applies cleanly to the head of >>linuxppc_2_4_devel >>and it works great. >> >>Keep up the good work! >> >>Pantelis >> >> > >Hi Pantelis > >I don't follow you here. Didn't my patch apply cleanly against >linuxppc_2_4_devel? >I generated my patch against linuxppc_2_4_devel(I think). > >Jocke > > > > > Nope. Fails at hunks #7 and #8. Don't worry, it's trivial stuff. Here is enet.c.rej, if you want to check it. Regards -- next part -- An embedded and charset-unspecified text was scrubbed... Name: enet.c.rej Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20030210/0bc35bce/attachment.txt
[PATCH] arch/ppc/8xx_io/enet.c, version 3
> >Hi Pantelis > > > >I don't follow you here. Didn't my patch apply cleanly against > >linuxppc_2_4_devel? > >I generated my patch against linuxppc_2_4_devel(I think). > > > >Jocke > Nope. > > Fails at hunks #7 and #8. > Don't worry, it's trivial stuff. > > Here is enet.c.rej, if you want to check it. hmm, something is broken here. I can apply my patch to my local copy of 8xx_io/enet.c, BK version 1.24 just fine. Whats your version of enet.c? Jocke ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] arch/ppc/8xx_io/enet.c, version 3
> Hi there,
>
> has someone actually ported Jocke's patch to 8xx FEC !?
>
> Any benchmarks?
>
> Thanks,
>
> Steven
Actually I had a copy at work so here it goes. Not tested(not even compiled)
Jocke
--- arch/ppc/8xx_io/fec.c Fri Nov 1 14:44:05 2002
+++ arch/ppc/8xx_io/new_fec.c Sun Feb 9 14:24:45 2003
@@ -83,26 +83,34 @@
} phy_info_t;
#endif /* CONFIG_USE_MDIO */
+/* Define COPY_SMALL_FRAMES if you want to save buffer memory for small packets
+ * at a small performance hit. Note performance testing needed */
+/* #define COPY_SMALL_FRAMES 1 */
+
+#ifdef COPY_SMALL_FRAMES
+ #define RX_COPYBREAK (256-16) /* dev_alloc_skb() adds 16 bytes for internal
use */
+#endif
+
+
/* The number of Tx and Rx buffers. These are allocated from the page
* pool. The code may assume these are power of two, so it is best
* to keep them that size.
* We don't need to allocate pages for the transmitter. We just use
* the skbuffer directly.
*/
+
#ifdef CONFIG_ENET_BIG_BUFFERS
-#define FEC_ENET_RX_PAGES 16
-#define FEC_ENET_RX_FRSIZE 2048
-#define FEC_ENET_RX_FRPPG (PAGE_SIZE / FEC_ENET_RX_FRSIZE)
-#define RX_RING_SIZE (FEC_ENET_RX_FRPPG * FEC_ENET_RX_PAGES)
-#define TX_RING_SIZE 16 /* Must be power of two */
-#define TX_RING_MOD_MASK 15 /* for this to work */
+ #define RX_RING_SIZE 32
+ #define TX_RING_SIZE 16 /* Must be power of two for this to
work */
#else
-#define FEC_ENET_RX_PAGES 4
-#define FEC_ENET_RX_FRSIZE 2048
-#define FEC_ENET_RX_FRPPG (PAGE_SIZE / FEC_ENET_RX_FRSIZE)
-#define RX_RING_SIZE (FEC_ENET_RX_FRPPG * FEC_ENET_RX_PAGES)
-#define TX_RING_SIZE 8 /* Must be power of two */
-#define TX_RING_MOD_MASK 7 /* for this to work */
+ #define RX_RING_SIZE 8
+ #define TX_RING_SIZE 8 /* Must be power of two for this to
work */
+#endif
+#define TX_RING_MOD_MASK (TX_RING_SIZE-1)
+
+#define CPM_ENET_RX_FRSIZE 1552 /* must be a multiple of cache line */
+#if CPM_ENET_RX_FRSIZE % L1_CACHE_LINE_SIZE != 0
+#error CPM_ENET_RX_FRSIZE must be a multiple of L1 cache size
#endif
/* Interrupt events/masks.
@@ -573,7 +581,7 @@
/* Check for errors. */
if (bdp->cbd_sc & (BD_ENET_RX_LG | BD_ENET_RX_SH | BD_ENET_RX_NO |
- BD_ENET_RX_CR | BD_ENET_RX_OV)) {
+ BD_ENET_RX_CR | BD_ENET_RX_OV | BD_ENET_RX_CL)) {
fep->stats.rx_errors++;
if (bdp->cbd_sc & (BD_ENET_RX_LG | BD_ENET_RX_SH)) {
/* Frame too long or too short. */
@@ -585,41 +593,53 @@
fep->stats.rx_crc_errors++;
if (bdp->cbd_sc & BD_ENET_RX_OV)/* FIFO overrun */
fep->stats.rx_crc_errors++;
- }
-
- /* Report late collisions as a frame error.
-* On this error, the BD is closed, but we don't know what we
-* have in the buffer. So, just drop this frame on the floor.
-*/
- if (bdp->cbd_sc & BD_ENET_RX_CL) {
- fep->stats.rx_errors++;
- fep->stats.rx_frame_errors++;
- goto rx_processing_done;
- }
-
- /* Process the incoming frame.
-*/
- fep->stats.rx_packets++;
- pkt_len = bdp->cbd_datlen;
- fep->stats.rx_bytes += pkt_len;
- data = fep->rx_vaddr[bdp - fep->rx_bd_base];
-
- /* This does 16 byte alignment, exactly what we need.
-* The packet length includes FCS, but we don't want to
-* include that when passing upstream as it messes up
-* bridging applications.
-*/
- skb = dev_alloc_skb(pkt_len-4);
-
- if (skb == NULL) {
- printk("%s: Memory squeeze, dropping packet.\n", dev->name);
- fep->stats.rx_dropped++;
+ if (bdp->cbd_sc & BD_ENET_RX_CL)/* Late collision */
+ fep->stats.rx_frame_errors++; /* Report as a frame
error. */
} else {
- skb->dev = dev;
- skb_put(skb,pkt_len-4); /* Make room */
- eth_copy_and_sum(skb, data, pkt_len-4, 0);
- skb->protocol=eth_type_trans(skb,dev);
- netif_rx(skb);
+
+ /* Process the incoming frame.
+*/
+ fep->stats.rx_packets++;
+ pkt_len = bdp->cbd_datlen;
+ fep->stats.rx_bytes += pkt_len;
+ pkt_len -= 4; /* The packet length includes FCS, but we don't
want to
+ * include that when passing upstream as it
messes up
+ * bridging applications. Is this still true
*/
+#ifdef COPY_SMALL_FRAMES
+ /* Allocate the next buffer now so we are sure to have one when
needed
+* This does 16 byte alignment, exactly what we need(L1_CACHE
aligned). */
+ if(pkt_len < RX_COPYBREAK)
+
[PATCH] arch/ppc/8xx_io/enet.c, version 3
> Hi guys, > > I have created a patch that applies cleanly to the head of > linuxppc_2_4_devel > and it works great. > > Keep up the good work! > > Pantelis Hi Pantelis I don't follow you here. Didn't my patch apply cleanly against linuxppc_2_4_devel? I generated my patch against linuxppc_2_4_devel(I think). Jocke ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] arch/ppc/8xx_io/enet.c, version 3
> has someone actually ported Jocke's patch to 8xx FEC !? I just did a port, but the patch is on my home computer. I can send it later ... It's not tested at all since I don't have the FEC connected on my boards. Jocke ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] arch/ppc/8xx_io/enet.c, version 3
Joakim Tjernlund wrote:
>>Hi,
>>
>>I am on an 862. Anyway I can't find another definition of dma_cache_inv() but
>>the NO OP in asm-ppc/io.h. Could you give me e hint
>>where it is defined in your kernel?
>>
>
>It's in asm-ppc/io.h (2.4.20) and there are 2 definitions of dma_cache_inv()
>which depends on
>CONFIG_NOT_COHERENT_CACHE(should be defined for 8xx). What kernel version are
>you running?
>
> Jocke
>
>>Thanks, Stephan
>>
>>
>>>-Original Message-
>>>From: Joakim Tjernlund [mailto:joakim.tjernlund at lumentis.se]
>>>Sent: Montag, 3. Februar 2003 18:23
>>>To: Stephan Linke
>>>Subject: RE: [PATCH] arch/ppc/8xx_io/enet.c, version 3
>>>
>>>
>>>
>>>>Hi Jocke,
>>>>
>>>>in your latest patch you are using dma_cache_inv() instead of
>>>>invalidate_dcache_range().
>>>>The only dma_cache_inv() I can find is in include/asm-ppc/io.h. and it's a
>>>>"do{}while(0)".
>>>>Are you shure that this was your intention? It seames to me like you could
>>>>remove that call as well.
>>>>
>>>I guess you are on 8260? On 8260 there is no need for
>>>invalidate_dcache_range() since
>>>it's the CPM is cache coherent. On 8xx it is not cache coherent. I switched
>>>to dma_cache_inv() because it's a no op on 8260 and a
>>>invalidate_dcache_range() on 8xx so
>>>it would be easy to adapt the patch to both CPU's.
>>>
>>> Jocke
>>>
>>>
>>>
>>
>
>
>
>
>
>
Hi guys,
I have created a patch that applies cleanly to the head of
linuxppc_2_4_devel
and it works great.
Keep up the good work!
Pantelis
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: joakim-enet-8xx-panto.patch
Url:
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20030210/547be440/attachment.txt
[PATCH] arch/ppc/8xx_io/enet.c, version 3
Hi there, has someone actually ported Jocke's patch to 8xx FEC !? Any benchmarks? Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] arch/ppc/8xx_io/enet.c, version 3
Hi Jocke,
I am running a 2.4.18 kernel. Maybe that's the problem?
But let me guess: keeping the invalidate_dcache_range() would be fine as well
for our 8xx board?
Stephan
> -Original Message-
> From: Joakim Tjernlund [mailto:joakim.tjernlund at lumentis.se]
> Sent: Dienstag, 4. Februar 2003 10:59
> To: Stephan Linke
> Cc: Linuxppc-Embedded
> Subject: RE: [PATCH] arch/ppc/8xx_io/enet.c, version 3
>
>
> >
> > Hi,
> >
> > I am on an 862. Anyway I can't find another definition of dma_cache_inv()
> > but the NO OP in asm-ppc/io.h. Could you give
> me e hint
> > where it is defined in your kernel?
>
> It's in asm-ppc/io.h (2.4.20) and there are 2 definitions of dma_cache_inv()
> which depends on
> CONFIG_NOT_COHERENT_CACHE(should be defined for 8xx). What kernel version are
> you running?
>
> Jocke
> >
> > Thanks, Stephan
> >
> > > -Original Message-
> > > From: Joakim Tjernlund [mailto:joakim.tjernlund at lumentis.se]
> > > Sent: Montag, 3. Februar 2003 18:23
> > > To: Stephan Linke
> > > Subject: RE: [PATCH] arch/ppc/8xx_io/enet.c, version 3
> > >
> > >
> > > > Hi Jocke,
> > > >
> > > > in your latest patch you are using dma_cache_inv() instead of
> > > > invalidate_dcache_range().
> > > > The only dma_cache_inv() I can find is in include/asm-ppc/io.h. and
> > > > it's a "do{}while (0)".
> > > > Are you shure that this was your intention? It seames to me like you
> > > > could remove that call as well.
> > >
> > > I guess you are on 8260? On 8260 there is no need for
> > > invalidate_dcache_range() since
> > > it's the CPM is cache coherent. On 8xx it is not cache coherent. I
> > > switched
> > > to dma_cache_inv() because it's a no op on 8260 and a
> > > invalidate_dcache_range() on 8xx so
> > > it would be easy to adapt the patch to both CPU's.
> > >
> > > Jocke
> > >
> > >
> >
> >
>
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] arch/ppc/8xx_io/enet.c, version 3
>
> Hi,
>
> I am on an 862. Anyway I can't find another definition of dma_cache_inv() but
> the NO OP in asm-ppc/io.h. Could you give me e hint
> where it is defined in your kernel?
It's in asm-ppc/io.h (2.4.20) and there are 2 definitions of dma_cache_inv()
which depends on
CONFIG_NOT_COHERENT_CACHE(should be defined for 8xx). What kernel version are
you running?
Jocke
>
> Thanks, Stephan
>
> > -Original Message-
> > From: Joakim Tjernlund [mailto:joakim.tjernlund at lumentis.se]
> > Sent: Montag, 3. Februar 2003 18:23
> > To: Stephan Linke
> > Subject: RE: [PATCH] arch/ppc/8xx_io/enet.c, version 3
> >
> >
> > > Hi Jocke,
> > >
> > > in your latest patch you are using dma_cache_inv() instead of
> > > invalidate_dcache_range().
> > > The only dma_cache_inv() I can find is in include/asm-ppc/io.h. and it's
> > > a "do{}while(0)".
> > > Are you shure that this was your intention? It seames to me like you
> > > could remove that call as well.
> >
> > I guess you are on 8260? On 8260 there is no need for
> > invalidate_dcache_range() since
> > it's the CPM is cache coherent. On 8xx it is not cache coherent. I switched
> > to dma_cache_inv() because it's a no op on 8260 and a
> > invalidate_dcache_range() on 8xx so
> > it would be easy to adapt the patch to both CPU's.
> >
> > Jocke
> >
> >
>
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] arch/ppc/8xx_io/enet.c, version 3
Hi,
I am on an 862. Anyway I can't find another definition of dma_cache_inv() but
the NO OP in asm-ppc/io.h. Could you give me e hint
where it is defined in your kernel?
Thanks, Stephan
> -Original Message-
> From: Joakim Tjernlund [mailto:joakim.tjernlund at lumentis.se]
> Sent: Montag, 3. Februar 2003 18:23
> To: Stephan Linke
> Subject: RE: [PATCH] arch/ppc/8xx_io/enet.c, version 3
>
>
> > Hi Jocke,
> >
> > in your latest patch you are using dma_cache_inv() instead of
> > invalidate_dcache_range().
> > The only dma_cache_inv() I can find is in include/asm-ppc/io.h. and it's a
> > "do{}while(0)".
> > Are you shure that this was your intention? It seames to me like you could
> > remove that call as well.
>
> I guess you are on 8260? On 8260 there is no need for
> invalidate_dcache_range() since
> it's the CPM is cache coherent. On 8xx it is not cache coherent. I switched
> to dma_cache_inv() because it's a no op on 8260 and a
> invalidate_dcache_range() on 8xx so
> it would be easy to adapt the patch to both CPU's.
>
> Jocke
>
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] arch/ppc/8xx_io/enet.c, version 3
Joakim Tjernlund wrote: >>>This is the second version of my patch that removes the expensive memcpy of >>>received >>>ethernet frames in interrupt context. >>> >>>I have 1 report(from Ricardo Scop) of 20% increase in packets/second, packet >>>size 1500 when >>>applied to 8260 FEC(needs to be applied manually). But min packet size >>>decreased with 10 %. >>>This version should fix the 10% decrease case. >>> >>>This patch could be adapted 8xx_io/fec.c and 8260_io/enet.c and >>>8260/fcc_enet.c with little effort. >>> >>>Better fix a bug in set_multicast_list(), move the dmi list forward when >>>walking it(dmi = dmi->next;) >>> >>>New stuff: >>> - Configrable: copy small packets or pass them directly, see >>>COPY_SMALL_FRAMES in code. >>> - Collision reporting fix form Thomas Lange. >>> - Don't pass receive frames which has error upwards. >>> - Report RX_OV errors as fifo errors, not crc errors. >>> >>>Please test and report any problems and performace improvements. >>> >>> >>Hi >> >>This is the third version of my optimized enet.c patch. >>Changes since version 2: >> 1) invalidate the whole buffer BEFORE it is given to he CPM. Previously >> it was invalidated after the packet was received and that could lead to >> buffer >> corruption in some cases. >> >> 2) use dma_cache_inv() instead of invalidate_dcache_range() since that will >> work >> for both 8xx and 82xx. >> >> 3) decrease the allocated buffer length. >> >> 4) disabled COPY_SMALL_FRAME. Define it somewhere if you want to save some >> memory. >> >> 5) probably some white space changes got in too. >> >>Any chance to see it the devel tree? >> >>More than 3 months has passed since version 2 and the only problem reported >>was >>1) and the fix has been know since mid November. >> >>Dan, you said you would integrate this patch(or some version of it) in >>November. I >>think I have waited long enough now. Please do ASAP. >> >> Jocke >> >> >[SNIP] > >Zero feedback so far. Is there zero interest to improve the mpc code in >linuxppc? >Anyhow, I give up. Don't have the energy to resend over and over again. > > Jocke > > > > > > Please don't give up. I'll try it and you'll have my feedback within the week. Anyhow, what is the deal with 8xx/82xx? At least the maintainers should ack the patch, and if it is not suitable for inclusion they should state for what reason. We don't want to discourage people sending patches. Right? Pantelis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] arch/ppc/8xx_io/enet.c, version 3
> > This is the second version of my patch that removes the expensive memcpy of > > received > > ethernet frames in interrupt context. > > > > I have 1 report(from Ricardo Scop) of 20% increase in packets/second, packet > > size 1500 when > > applied to 8260 FEC(needs to be applied manually). But min packet size > > decreased with 10 %. > > This version should fix the 10% decrease case. > > > > This patch could be adapted 8xx_io/fec.c and 8260_io/enet.c and > > 8260/fcc_enet.c with little effort. > > > > Better fix a bug in set_multicast_list(), move the dmi list forward when > > walking it(dmi = dmi->next;) > > > > New stuff: > >- Configrable: copy small packets or pass them directly, see > > COPY_SMALL_FRAMES in code. > >- Collision reporting fix form Thomas Lange. > >- Don't pass receive frames which has error upwards. > >- Report RX_OV errors as fifo errors, not crc errors. > > > > Please test and report any problems and performace improvements. > > Hi > > This is the third version of my optimized enet.c patch. > Changes since version 2: > 1) invalidate the whole buffer BEFORE it is given to he CPM. Previously > it was invalidated after the packet was received and that could lead to > buffer > corruption in some cases. > > 2) use dma_cache_inv() instead of invalidate_dcache_range() since that will > work > for both 8xx and 82xx. > > 3) decrease the allocated buffer length. > > 4) disabled COPY_SMALL_FRAME. Define it somewhere if you want to save some > memory. > > 5) probably some white space changes got in too. > > Any chance to see it the devel tree? > > More than 3 months has passed since version 2 and the only problem reported > was > 1) and the fix has been know since mid November. > > Dan, you said you would integrate this patch(or some version of it) in > November. I > think I have waited long enough now. Please do ASAP. > > Jocke [SNIP] Zero feedback so far. Is there zero interest to improve the mpc code in linuxppc? Anyhow, I give up. Don't have the energy to resend over and over again. Jocke ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] arch/ppc/8xx_io/enet.c, version 3
> This is the second version of my patch that removes the expensive memcpy of
> received
> ethernet frames in interrupt context.
>
> I have 1 report(from Ricardo Scop) of 20% increase in packets/second, packet
> size 1500 when
> applied to 8260 FEC(needs to be applied manually). But min packet size
> decreased with 10 %.
> This version should fix the 10% decrease case.
>
> This patch could be adapted 8xx_io/fec.c and 8260_io/enet.c and
> 8260/fcc_enet.c with little effort.
>
> Better fix a bug in set_multicast_list(), move the dmi list forward when
> walking it(dmi = dmi->next;)
>
> New stuff:
>- Configrable: copy small packets or pass them directly, see
> COPY_SMALL_FRAMES in code.
>- Collision reporting fix form Thomas Lange.
>- Don't pass receive frames which has error upwards.
>- Report RX_OV errors as fifo errors, not crc errors.
>
> Please test and report any problems and performace improvements.
Hi
This is the third version of my optimized enet.c patch.
Changes since version 2:
1) invalidate the whole buffer BEFORE it is given to he CPM. Previously
it was invalidated after the packet was received and that could lead to
buffer
corruption in some cases.
2) use dma_cache_inv() instead of invalidate_dcache_range() since that will
work
for both 8xx and 82xx.
3) decrease the allocated buffer length.
4) disabled COPY_SMALL_FRAME. Define it somewhere if you want to save some
memory.
5) probably some white space changes got in too.
Any chance to see it the devel tree?
More than 3 months has passed since version 2 and the only problem reported was
1) and the fix has been know since mid November.
Dan, you said you would integrate this patch(or some version of it) in
November. I
think I have waited long enough now. Please do ASAP.
Jocke
--- arch/ppc/8xx_io/enet.c Fri Nov 1 14:44:05 2002
+++ arch/ppc/8xx_io/new_enet.c Sat Jan 25 19:57:50 2003
@@ -34,7 +34,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -86,6 +85,14 @@
* All functions are directly controlled using I/O pins. See .
*/
+/* Define COPY_SMALL_FRAMES if you want to save buffer memory for small packets
+ * at a small performance hit. Note performance testing needed */
+/* #define COPY_SMALL_FRAMES 1 */
+
+#ifdef COPY_SMALL_FRAMES
+ #define RX_COPYBREAK (256-16) /* dev_alloc_skb() adds 16 bytes for internal
use */
+#endif
+
/* The transmitter timeout
*/
#define TX_TIMEOUT (2*HZ)
@@ -97,19 +104,17 @@
* the skbuffer directly.
*/
#ifdef CONFIG_ENET_BIG_BUFFERS
-#define CPM_ENET_RX_PAGES 32
-#define CPM_ENET_RX_FRSIZE 2048
-#define CPM_ENET_RX_FRPPG (PAGE_SIZE / CPM_ENET_RX_FRSIZE)
-#define RX_RING_SIZE (CPM_ENET_RX_FRPPG * CPM_ENET_RX_PAGES)
-#define TX_RING_SIZE 64 /* Must be power of two */
-#define TX_RING_MOD_MASK 63 /* for this to work */
+ #define RX_RING_SIZE 64
+ #define TX_RING_SIZE 64 /* Must be power of two for this to
work */
#else
-#define CPM_ENET_RX_PAGES 4
-#define CPM_ENET_RX_FRSIZE 2048
-#define CPM_ENET_RX_FRPPG (PAGE_SIZE / CPM_ENET_RX_FRSIZE)
-#define RX_RING_SIZE (CPM_ENET_RX_FRPPG * CPM_ENET_RX_PAGES)
-#define TX_RING_SIZE 8 /* Must be power of two */
-#define TX_RING_MOD_MASK 7 /* for this to work */
+ #define RX_RING_SIZE 8
+ #define TX_RING_SIZE 8 /* Must be power of two for this to
work */
+#endif
+#define TX_RING_MOD_MASK (TX_RING_SIZE-1)
+
+#define CPM_ENET_RX_FRSIZE 1552 /* must be a multiple of cache line */
+#if CPM_ENET_RX_FRSIZE % L1_CACHE_LINE_SIZE != 0
+#error CPM_ENET_RX_FRSIZE must be a multiple of L1 cache size
#endif
/* The CPM stores dest/src/type, data, and checksum for receive packets.
@@ -143,7 +148,7 @@
/* Virtual addresses for the receive buffers because we can't
* do a __va() on them anymore.
*/
- unsigned char *rx_vaddr[RX_RING_SIZE];
+ void*rx_vaddr[RX_RING_SIZE];
struct net_device_stats stats;
uinttx_full;
spinlock_t lock;
@@ -370,11 +375,11 @@
cep->stats.tx_packets++;
- /* Deferred means some collisions occurred during transmit,
-* but we eventually sent the packet OK.
-*/
- if (bdp->cbd_sc & BD_ENET_TX_DEF)
- cep->stats.collisions++;
+ /* Check retry counter, i.e. collision counter */
+ if (bdp->cbd_sc & BD_ENET_TX_RCMASK){
+ /* Note that counter cannot go higher than 15 */
+ cep->stats.collisions+=(bdp->cbd_sc &
BD_ENET_TX_RCMASK)>>2;
+ }
/* Free the sk buffer associated with this last transmit.
*/
@@ -449,6 +454,7 @@
struct scc_enet_private *cep;
volatile cbd_t *bdp;
struct sk_buff *skb;
+ s
