Re: [PATCH] arch/ppc/8xx_io/enet.c

Re: [PATCH] arch/ppc/8xx_io/enet.c

[Joakim Tjernlund]

On Monday 21 October 2002 15:13, Joakim Tjernlund wrote:
> Hi
>
> Here is a patch to drop the expensive memcpy of received ethernet frames in
> interrupt context. I have not done any bench marking, but mounting a NFS
> rootfs feels faster.
>
> I am using a heavily modified enet.c in my system, but I think I got the
> patch correct.
>
> Also fixed a bug in set_multicast_list(), move the dmi list forward when
> walking it(dmi = dmi->next;)
>
> Comments? Anyone care to do some benchmarking?

No comments so far, no one interested in this?

A question, why do enet.c pass bad frames to netif_rx? Only late collisions
are disregarded, the rest is passed on.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [PATCH] arch/ppc/8xx_io/enet.c

[Ricardo Scop]

On Wednesday 23 October 2002 05:51, Joakim Tjernlund wrote:
> On Monday 21 October 2002 15:13, Joakim Tjernlund wrote:
> > Hi
> >
> > Here is a patch to drop the expensive memcpy of received ethernet frames
> > in interrupt context. I have not done any bench marking, but mounting a
> > NFS rootfs feels faster.
> >
> > I am using a heavily modified enet.c in my system, but I think I got the
> > patch correct.
> >
> > Also fixed a bug in set_multicast_list(), move the dmi list forward when
> > walking it(dmi = dmi->next;)
> >
> > Comments? Anyone care to do some benchmarking?
>
> No comments so far, no one interested in this?
I'm interested! Indeed, I adapted and tested your patch in a 8260 FCC fast
ethernet driver and it worked fine  I had a 20% increase in routing
throughput with the  patch installed!

The bug fix in set_multicast_list worked too. But, since there's a continue
clause inside the for command in this routine, I would suggest that the
(dmi=dmi->next) command go inside the for increment clause, instead of the
place you've put it; that is:
	for (...;...; i++, dmi = dmi->next) {...}
>
> A question, why do enet.c pass bad frames to netif_rx? Only late collisions
> are disregarded, the rest is passed on.
IMHO, this is another bug...

>

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [PATCH] arch/ppc/8xx_io/enet.c

[Ricardo Scop]

On Wednesday 23 October 2002 13:32, Ricardo Scop wrote:
> On Wednesday 23 October 2002 05:51, Joakim Tjernlund wrote:
[snip]

> > No comments so far, no one interested in this?
>
> I'm interested! Indeed, I adapted and tested your patch in a 8260 FCC fast
> ethernet driver and it worked fine  I had a 20% increase in routing
> throughput with the  patch installed!
>
I forgot to mention the bad news. The increase mentioned above was obtained
with large packets (1500 bytes) traversing our board. With very small packets
(64 bytes), we  experimented a 10% DEcrease in PPS (packets per second).
We're still testing, but I guess the overall performance will be better with
the patch installed.

-Scop

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

dc* (Data Cache) instructions in mem*() and *_page() functions not used on 8xx

[Joakim Tjernlund]

Hi again

I trying to understand how the different mem*() and *_page() functions in arch/ppc/kernel/misc.S
and arch/ppc/lib/string.S works wrt data cache.

I found that on 8xx these are not used. Why? Are there 8xx variants that can't handle them?
Do 860 work with these?

Also, why is not dcbtst(write a cache line) used
in the different copy functions, copy_page()for example, instead of the COPY_16_BYTES macro?

  Jocke


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: dc* (Data Cache) instructions in mem*() and *_page() functions not used on 8xx

[Joakim Tjernlund]

It's me again

No response so far. Trying again.

     Jocke
>
> Hi again
>
> I trying to understand how the different mem*() and *_page() functions in arch/ppc/kernel/misc.S
> and arch/ppc/lib/string.S works wrt data cache.
>
> I found that on 8xx these are not used. Why? Are there 8xx variants that can't handle them?
> Do 860 work with these?
>
> Also, why is not dcbtst(write a cache line) used
> in the different copy functions, copy_page()for example, instead of the COPY_16_BYTES macro?
>
>   Jocke


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: dc* (Data Cache) instructions in mem*() and *_page() functions not used on 8xx

[Dan Malek]

Joakim Tjernlund wrote:

>>I found that on 8xx these are not used. Why? Are there 8xx variants that can't handle them?
>>Do 860 work with these?

The TLB/Exception side effects of using these instructions in the 8xx varied
with different silicon versions.  Rather than have a bunch of unique code for
different silicon revisions (and in some cases the side effects didn't occur
at all so the instructions couldn't be used) it is just easier to not use the
instructions.  Any performance gained by using these instructions was lost
in the special exception handling.

>>Also, why is not dcbtst(write a cache line) used

Because dcbtst performs a load operation on a line you know is going to
replaced.  That generates unnecessary bus traffic and is why the dcbz is
used instead.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: dc* (Data Cache) instructions in mem*() and *_page() functions not used on 8xx

[Joakim Tjernlund]

> Joakim Tjernlund wrote:
>
> >>I found that on 8xx these are not used. Why? Are there 8xx variants that can't handle them?
> >>Do 860 work with these?
>
> The TLB/Exception side effects of using these instructions in the 8xx varied
> with different silicon versions.  Rather than have a bunch of unique code for
> different silicon revisions (and in some cases the side effects didn't occur
> at all so the instructions couldn't be used) it is just easier to not use the
> instructions.  Any performance gained by using these instructions was lost
> in the special exception handling.

That figures, just out of curiosity I removed those restrictions in misc.S and
string.S on my 860, rev D4 to see what happened.
Result: It hung in init.
Now I exclude 8xx in __copy_tofrom_user in string.S.
Result: Now it works just fine.

It seems that even the newest 8xx chips still has problems. I did not expect that.

 Jocke

>
> >>Also, why is not dcbtst(write a cache line) used
>
> Because dcbtst performs a load operation on a line you know is going to
> replaced.  That generates unnecessary bus traffic and is why the dcbz is
> used instead.

OK, thanks.

 Jocke


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: dc* (Data Cache) instructions in mem*() and *_page() functions not used on 8xx

[Dan Malek]

Joakim Tjernlund wrote:

> It seems that even the newest 8xx chips still has problems. I did not expect that.

It may be the parts are working fine.  I long ago removed the code necessary
to detect the exception conditions when the cache instructions faulted, so
I wouldn't expect them to work properly.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: dc* (Data Cache) instructions in mem*() and *_page() functions not used on 8xx

[Joakim Tjernlund]

> Joakim Tjernlund wrote:
>
> > It seems that even the newest 8xx chips still has problems. I did not expect that.
>
> It may be the parts are working fine.  I long ago removed the code necessary
> to detect the exception conditions when the cache instructions faulted, so
> I wouldn't expect them to work properly.

Aah, that would explain why __copy_tofrom_user doesn't work I guess. But the
rest seems to be fine. Maybe there should be a new config option that
would one could enable for modern 8xx CPUs? With a big warning sign of cource
and default to off. Maybe even add the missing exception handler?

   Jocke


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: dc* (Data Cache) instructions in mem*() and *_page() functions not used on 8xx

[Joakim Tjernlund]

> > Joakim Tjernlund wrote:
> >
> > > It seems that even the newest 8xx chips still has problems. I did not expect that.
> >
> > It may be the parts are working fine.  I long ago removed the code necessary
> > to detect the exception conditions when the cache instructions faulted, so
> > I wouldn't expect them to work properly.
>
> Aah, that would explain why __copy_tofrom_user doesn't work I guess. But the
> rest seems to be fine. Maybe there should be a new config option that
> would one could enable for modern 8xx CPUs? With a big warning sign of cource
> and default to off. Maybe even add the missing exception handler?
>
>    Jocke

Dan, could you add the missing code for 8xx to detect the exception conditions when
the cache instructions faulted? I would like to give it a try.

Maybe add a new CONFIG option to allow 8xx to use these optimizations when
explicitly enabled. Perhaps it's enough to let it depend on CONFIG_8xx_CPU6, that is,
if CONFIG_8xx_CPU6 is set do NOT enable dcbz et. all, otherwise enable them?

        Jocke


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: dc* (Data Cache) instructions in mem*() and *_page() functions not used on 8xx

[Dan Malek]

Joakim Tjernlund wrote:

> Dan, could you add the missing code for 8xx to detect the exception conditions when
> the cache instructions faulted? I would like to give it a try.

It's not very high on my list of things to do.  As I recall, the VM fault
handler may need knowledge of a dcbz fault and use a different method to
determine the address.  I also have this funny feeling that it isn't a
restartable operation, so we may have to emulate the instruction when
the fault occurs.

I know you can write a test that would show this to be a performance
benefit, which would just copy/zero lots of data, but that's not a real
world application.

IMHO, it's lots of work for little, if any, gain.  It has some specific
uses in specialized applications, but I don't think it's a general speed up
solution.

 > Maybe add a new CONFIG option to allow 8xx to use these optimizations when
> explicitly enabled.

How would you know when to do this?  It seldom appeared in any errata
so you couldn't know for certain if a particular chip version would
allow this.  I suspect people (like I have chosen to do) will just never
use the optimization because the software will always work in this case.
I don't like solutions that depend on luck or trial and error.

I'll do some research into this again, it's been many years since I
thought about it.

	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: dc* (Data Cache) instructions in mem*() and *_page() functions not used on 8xx

[Joakim Tjernlund]

----- Original Message -----
From: "Dan Malek" <dan@embeddededge.com>
To: <joakim.tjernlund@lumentis.se>
Cc: <linuxppc-embedded@lists.linuxppc.org>
Sent: den 1 november 2002 18:33
Subject: Re: dc* (Data Cache) instructions in mem*() and *_page() functions not used on 8xx


> Joakim Tjernlund wrote:
>
> > Dan, could you add the missing code for 8xx to detect the exception conditions when
> > the cache instructions faulted? I would like to give it a try.
>
> It's not very high on my list of things to do.  As I recall, the VM fault
> handler may need knowledge of a dcbz fault and use a different method to
> determine the address.  I also have this funny feeling that it isn't a
> restartable operation, so we may have to emulate the instruction when
> the fault occurs.

I don't follow you here, do you need to do all this for a modern(>=D4) 8xx CPU?
I hope not, but something needs to be done since copytofrom_user does not
work for me.

>
> I know you can write a test that would show this to be a performance
> benefit, which would just copy/zero lots of data, but that's not a real
> world application.
>
> IMHO, it's lots of work for little, if any, gain.  It has some specific
> uses in specialized applications, but I don't think it's a general speed up
> solution.
>
>  > Maybe add a new CONFIG option to allow 8xx to use these optimizations when
> > explicitly enabled.
>
> How would you know when to do this?  It seldom appeared in any errata
> so you couldn't know for certain if a particular chip version would
> allow this.  I suspect people (like I have chosen to do) will just never
> use the optimization because the software will always work in this case.
> I don't like solutions that depend on luck or trial and error.

Pretty much like the 8xx_CPU6 errata. If a user has a CPU with this bug,
he must enable it. If you have a fairly new CPU you don't have to.

The same resoning goes for the new option. If you have a new enough(>=D4) CPU,
then you can enable this optimization(I think?!). I am not talking about enabling
workarounds for non functioning CPUs in runtime. Take me for example,
our boards will never use anything older than D4 since it's a new design.

      Jocke
>
> I'll do some research into this again, it's been many years since I
> thought about it.
>
> -- Dan
>

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: dc* (Data Cache) instructions in mem*() and *_page() functions not used on 8xx

[Dan Malek]

Joakim Tjernlund wrote:

> I don't follow you here, do you need to do all this for a modern(>=D4) 8xx CPU?

Yes.  On "working" silicon, the dcbz (among others) requires special
processing.....probably enough to ensure it costs more to use this
instruction in a general purpose case.

> I hope not, but something needs to be done since copytofrom_user does not
> work for me.

What do you mean it doesn't work?  It should work fine if you don't
try to use the dcbz.  That is, leave the code alone.  The bigger problem
is the newer glibc library has to be modified to conditionally not use
this as well.

> The same resoning goes for the new option. If you have a new enough(>=D4) CPU,
> then you can enable this optimization(I think?!).

I don't know.  Linux is the only OS that will cause VM faults on a dcbz,
maybe it will never work.  Until someone verifies it works on the newer
silicon we can't assume it will.  This certainly isn't a reason to not use
the processor or not ship products.......

Thanks.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: dc* (Data Cache) instructions in mem*() and *_page() functions not used on 8xx

[Joakim Tjernlund]

> Joakim Tjernlund wrote:
>
> > I don't follow you here, do you need to do all this for a modern(>=D4) 8xx CPU?
>
> Yes.  On "working" silicon, the dcbz (among others) requires special
> processing.....probably enough to ensure it costs more to use this
> instruction in a general purpose case.

hmm, then I asume that a "working" 8xx is different from any other PPC that
uses the dcbz? All other PPC arches are allowed to use the dcbz instruction.

>
> > I hope not, but something needs to be done since copytofrom_user does not
> > work for me.
>
> What do you mean it doesn't work?  It should work fine if you don't
> try to use the dcbz.  That is, leave the code alone.  The bigger problem
> is the newer glibc library has to be modified to conditionally not use
> this as well.

I mean that if I remove the #ifndef CONFIG_8xx restrictions in __copy_fromto_user(),
linux does not work anymore(init hangs). That was the experiment I did earlier in this thread.

clear_page() and copy_page() work fine if I remove #ifndef CONFIG_8xx.
I removed the #ifndef CONFIG_8xx in cacheble_memcpy() and cacheble_memzero() also but
these seems to unused.

>
> > The same resoning goes for the new option. If you have a new enough(>=D4) CPU,
> > then you can enable this optimization(I think?!).
>
> I don't know.  Linux is the only OS that will cause VM faults on a dcbz,
> maybe it will never work.  Until someone verifies it works on the newer
> silicon we can't assume it will.  This certainly isn't a reason to not use
> the processor or not ship products.......

Right, I quite like the 860 and even more the 862P(100MHz) I just got :-)

 Regards
         Jocke


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: [PATCH] arch/ppc/8xx_io/enet.c

[Joakim Tjernlund]

> > >
> > > Comments? Anyone care to do some benchmarking?
> >
> > No comments so far, no one interested in this?
> I'm interested! Indeed, I adapted and tested your patch in a 8260 FCC fast
> ethernet driver and it worked fine  I had a 20% increase in routing
> throughput with the  patch installed!

Cool!

>
> The bug fix in set_multicast_list worked too. But, since there's a continue
> clause inside the for command in this routine, I would suggest that the
> (dmi=dmi->next) command go inside the for increment clause, instead of the
> place you've put it; that is:
> 	for (...;...; i++, dmi = dmi->next) {...}

Yes thats better, thanks.
> >
> > A question, why do enet.c pass bad frames to netif_rx? Only late collisions
> > are disregarded, the rest is passed on.
> IMHO, this is another bug...
me too.

       Jocke


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [PATCH] arch/ppc/8xx_io/enet.c

[Steven Scholz]

Ricardo Scop wrote:
>
> On Wednesday 23 October 2002 05:51, Joakim Tjernlund wrote:
> > On Monday 21 October 2002 15:13, Joakim Tjernlund wrote:
> > > Hi
> > >
> > > Here is a patch to drop the expensive memcpy of received ethernet frames
> > > in interrupt context. I have not done any bench marking, but mounting a
> > > NFS rootfs feels faster.
> > >
> > > I am using a heavily modified enet.c in my system, but I think I got the
> > > patch correct.
> > >
> > > Also fixed a bug in set_multicast_list(), move the dmi list forward when
> > > walking it(dmi = dmi->next;)
> > >
> > > Comments? Anyone care to do some benchmarking?
> >
> > No comments so far, no one interested in this?
> I'm interested! Indeed, I adapted and tested your patch in a 8260 FCC fast
> ethernet driver and it worked fine  I had a 20% increase in routing
> throughput with the  patch installed!
> ...

Did I understand that correctly that this patch would work with mith MPC8xx FEC
as well!?!?

Cheers,

Steven

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: [PATCH] arch/ppc/8xx_io/enet.c

[Joakim Tjernlund]

>
> Ricardo Scop wrote:
> >
> > On Wednesday 23 October 2002 05:51, Joakim Tjernlund wrote:
> > > On Monday 21 October 2002 15:13, Joakim Tjernlund wrote:
> > > > Hi
> > > >
> > > > Here is a patch to drop the expensive memcpy of received ethernet frames
> > > > in interrupt context. I have not done any bench marking, but mounting a
> > > > NFS rootfs feels faster.
> > > >
> > > > I am using a heavily modified enet.c in my system, but I think I got the
> > > > patch correct.
> > > >
> > > > Also fixed a bug in set_multicast_list(), move the dmi list forward when
> > > > walking it(dmi = dmi->next;)
> > > >
> > > > Comments? Anyone care to do some benchmarking?
> > >
> > > No comments so far, no one interested in this?
> > I'm interested! Indeed, I adapted and tested your patch in a 8260 FCC fast
> > ethernet driver and it worked fine  I had a 20% increase in routing
> > throughput with the  patch installed!
> > ...
>
> Did I understand that correctly that this patch would work with mith MPC8xx FEC
> as well!?!?

Yes, but you have to adapt it a little.

 Jocke


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

[PATCH] arch/ppc/8xx_io/enet.c

[Joakim Tjernlund]

Hi

Here is a patch to drop the expensive memcpy of received ethernet frames in
interrupt context. I have not done any bench marking, but mounting a NFS rootfs feels faster.

I am using a heavily modified enet.c in my system, but I think I got the patch correct.

Also fixed a bug in set_multicast_list(), move the dmi list forward when walking it(dmi = dmi->next;)

Comments? Anyone care to do some benchmarking?

        Jocke

 --- arch/ppc/8xx_io/enet.c.org	Mon Oct 21 14:35:59 2002
+++ arch/ppc/8xx_io/enet.c	Mon Oct 21 15:06:04 2002
@@ -96,18 +96,17 @@
  * We don't need to allocate pages for the transmitter.  We just use
  * the skbuffer directly.
  */
+#define CPM_ENET_RX_FRSIZE	1600   /* 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
+
 #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 RX_RING_SIZE		64
 #define TX_RING_SIZE		64	/* Must be power of two */
 #define TX_RING_MOD_MASK	63	/*   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 RX_RING_SIZE		8
 #define TX_RING_SIZE		8	/* Must be power of two */
 #define TX_RING_MOD_MASK	7	/*   for this to work */
 #endif
@@ -143,7 +142,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;
 	uint	tx_full;
 	spinlock_t lock;
@@ -449,6 +448,7 @@
 	struct	scc_enet_private *cep;
 	volatile cbd_t	*bdp;
 	struct	sk_buff *skb;
+	struct	sk_buff *skb_tmp;
 	ushort	pkt_len;

 	cep = (struct scc_enet_private *)dev->priv;
@@ -497,25 +497,26 @@
 		pkt_len = bdp->cbd_datlen;
 		cep->stats.rx_bytes += pkt_len;

-		/* This does 16 byte alignment, much more than we need.
+		/* 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) {
+		skb_tmp = dev_alloc_skb(CPM_ENET_RX_FRSIZE);
+		if (skb_tmp == NULL) {
 			printk("%s: Memory squeeze, dropping packet.\n", dev->name);
 			cep->stats.rx_dropped++;
-		}
-		else {
+		} else {
+			skb = cep->rx_vaddr[bdp - cep->rx_bd_base];
 			skb->dev = dev;
 			skb_put(skb,pkt_len-4);	/* Make room */
-			eth_copy_and_sum(skb,
-				cep->rx_vaddr[bdp - cep->rx_bd_base],
-				pkt_len-4, 0);
 			skb->protocol=eth_type_trans(skb,dev);
 			netif_rx(skb);
+
+			invalidate_dcache_range((unsigned long) skb_tmp->data,
+						(unsigned long) skb_tmp->data + CPM_ENET_RX_FRSIZE);
+			bdp->cbd_bufaddr = __pa(skb_tmp->data);
+			cep->rx_vaddr[bdp - cep->rx_bd_base] = skb_tmp;
 		}
 	}

@@ -631,6 +632,7 @@
 				/* this delay is necessary here -- Cort */
 				udelay(10);
 				while (cpmp->cp_cpcr & CPM_CR_FLG);
+				dmi = dmi->next;
 			}
 		}
 	}
@@ -647,8 +649,7 @@
 	struct net_device *dev;
 	struct scc_enet_private *cep;
 	int i, j, k;
-	unsigned char	*eap, *ba;
-	dma_addr_t	mem_addr;
+	unsigned char	*eap;
 	bd_t		*bd;
 	volatile	cbd_t		*bdp;
 	volatile	cpm8xx_t	*cp;
@@ -839,22 +840,15 @@

 	bdp = cep->rx_bd_base;
 	k = 0;
-	for (i=0; i<CPM_ENET_RX_PAGES; i++) {
-
-		/* Allocate a page.
-		*/
-		ba = (unsigned char *)consistent_alloc(GFP_KERNEL, PAGE_SIZE, &mem_addr);
-
-		/* Initialize the BD for every fragment in the page.
-		*/
-		for (j=0; j<CPM_ENET_RX_FRPPG; j++) {
-			bdp->cbd_sc = BD_ENET_RX_EMPTY | BD_ENET_RX_INTR;
-			bdp->cbd_bufaddr = mem_addr;
-			cep->rx_vaddr[k++] = ba;
-			mem_addr += CPM_ENET_RX_FRSIZE;
-			ba += CPM_ENET_RX_FRSIZE;
-			bdp++;
-		}
+	/* Initialize the BDs. */
+	for (j=0; j < RX_RING_SIZE; j++) {
+		struct	sk_buff * skb = dev_alloc_skb(CPM_ENET_RX_FRSIZE);
+		bdp->cbd_sc = BD_ENET_RX_EMPTY | BD_ENET_RX_INTR;
+		bdp->cbd_bufaddr = __pa(skb->data);
+		invalidate_dcache_range((unsigned long) skb->data,
+					(unsigned long) skb->data + CPM_ENET_RX_FRSIZE);
+		cep->rx_vaddr[k++] = skb;
+		bdp++;
 	}

 	/* Set the last buffer to wrap.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/