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 tha
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
> >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-em
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 ge
> >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
> 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
> 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_d
> 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.o
nlund [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 l
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/
t: 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
ache_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
.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_cac
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 appl
> > 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
> 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 siz
On 11/13/02 11:12 PM, Dan Malek wrote:
> This isn't something new that hasn't been tried before. The problem
> in the past with non-coherent processors, incoming DMA, and skbufs is
> the buffers would share cache lines with other data which would get
> corrupted as the result of the invalidate f
> Joakim Tjernlund wrote:
>
> > OK, anyone against? Dan?
>
> I'm currently looking at the patches and I'll be integrating something
> that hopefully works :-)
Please tell me if there is something in that patch you don't like(besides the
moving the invalidate call).
>
> This isn't something new th
> - Original Message -
> From: Joakim Tjernlund
>
> > You may be right, perhaps one must invalidate the whole buffer before
> > giving it
> > to the CPM/DMA. Suppose you reuse a buffer which has been modified before it
> > was freed and the dcache must write back data to free up space an
- Original Message -
From: Joakim Tjernlund <[EMAIL PROTECTED]>
> You may be right, perhaps one must invalidate the whole buffer before giving
> it
> to the CPM/DMA. Suppose you reuse a buffer which has been modified before it
> was freed and the dcache must write back data to free up sp
> On 10/24/02 04:23 PM, Joakim Tjernlund wrote:
> > Hi
> >
> > This is the second version of my patch that removes the expensive memcpy of
> > received
> > ethernet frames in interrupt context.
>
> Isn't it so that this patch works because you have snooping? Without
> snooping the driver would fai
Joakim Tjernlund wrote:
> OK, anyone against? Dan?
I'm currently looking at the patches and I'll be integrating something
that hopefully works :-)
This isn't something new that hasn't been tried before. The problem
in the past with non-coherent processors, incoming DMA, and skbufs is
the buffe
On 10/24/02 04:23 PM, Joakim Tjernlund wrote:
> Hi
>
> This is the second version of my patch that removes the expensive memcpy of
> received
> ethernet frames in interrupt context.
Isn't it so that this patch works because you have snooping? Without
snooping the driver would fail because of cach
Hi Tom
Will you apply this patch? No problems reported so far.
Jocke
> >
> > On Thu, Oct 24, 2002 at 04:23:31PM +0200, Joakim Tjernlund wrote:
> >
> > > This is the second version of my patch that removes the expensive memcpy
> > > of
> > > received
> > > ethernet frames in interrupt context
mbedded at lists.linuxppc.org
> > Cc: scop at digitel.com.br; thomas at corelatus.com
> > Subject: [PATCH] arch/ppc/8xx_io/enet.c, version 2
> >
> >
> >
> > Hi
> >
> > This is the second version of my patch that removes the expensive
> > memcpy
.org
> Cc: scop at digitel.com.br; thomas at corelatus.com
> Subject: [PATCH] arch/ppc/8xx_io/enet.c, version 2
>
>
>
> Hi
>
> This is the second version of my patch that removes the expensive
> memcpy of
> received
> ethernet frames in interrupt context.
>
>
>
>
> On Thu, Oct 24, 2002 at 04:23:31PM +0200, 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
> >
Hi
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
decreas
>
> 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 do
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 marki
> > >
> > > 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 installe
On Thu, Oct 24, 2002 at 04:23:31PM +0200, 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
> ap
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 ha
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
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
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_multicas
36 matches
Mail list logo
