Status: SMC91C111 Ethernet Driver Development

Ian Caddy ianc at microsol.iinet.net.au
Thu Mar 21 01:30:10 UTC 2002


Hi,


Joel Sherrill wrote:

> >
> > There were some overruns while performing the test (the Coldfire was the
> > receiver) which I expect to get fixed once I get the DMA in place.  This
> > seems to really slow down the TCP stream.
> >
>
> Great!!!  Believe it or not 350Kis not that bad for an initial cut.  The
> old
> KA9Q TCPIP stack port topped out there.  Sometimes improving interrupt
> handling can make a big difference.  When you sasy no DMA are you
> responsible
> for copying data on a per byte or buffer basis from chip memory to
> mbufs?
>

The SMC chip provides 8K data space on chip, which is broken into 4 2KByte
buffers.  Unfortunately in our design we only have a 16-bit interface to the
chip and so can only access this space through the data registers.  For
receive, I get an interrupt telling me that there is a whole packet waiting
for me in a particular buffer.  At the moment, I send an event to the receive
task who finds the buffer and pulls out the whole packet into an mbuf and
sends it on.  This is done currently by getting an mbuf and then copying word
by word at the rx task level.  This is obviously not ideal but it was a quick
way for me to test the functionality of the SMC chip.

What I want to do next is allocate a ring of mbufs for receive, and then when
I get an interrupt, start the DMA transfer to fill an mbuf and once this is
complete, then event the rx task.  The task can then send up the mbuf.  While
this is happening, another packet can be being DMAed into another mbuf.

With the transmit task, I allocate a SMC buffer, and then copy the mbuf
fragments one by one into the SMC buffer, and then launch it.  I am not sure
how much we would gain by moving this into a DMA transfer. As the tx packet is
fragmented into mulitple mbufs and so there would need to be multiple DMA
transfers....I might try it and see if it significantly improves performance.


>
> > There may be a slight delay in this as I have to go to the US early next
> > week for a couple of weeks.
>
> Where are you headed?  You might bump into some RTEMS folks. :)

Apparently the current plan is for me to go to Houston for one day, the
Tuesday after Easter.  Now getting from Perth, Australia to Houston is about
35 hours travelling time, so I am going just before Easter and flying via
Vancouver where I have some friends who are willing to take me skiing over
Easter.....not much snow in Perth....:-), then to Houston for the day and then
back home.


> > Just another note: I got the webserver application in the netdemos stuff
> > working, as this impresses the marketing types...:-), but there was a
> > problem with the make file (had a space on a line that shouldn't have
> > had one) and the init.c did not initialise the hostname so the webserver
> > would not startup.
>
> Could you (1) generate a patch and (2) file this using GNATS?
>
> http://www.oarcorp.com/cgi-bin/gnatsweb.pl
>
> User/password guest/guest
>

I will give it a whirl today.  I am more than happy to help out in this
respect.


> Please also write a ChangeLog entry for the mod.
>

Noted.

>
> I am happy to teach anyone how to do any of this since that is
> best long term.

That is great to hear.  I am very impressed with the support available for
RTEMS.  I am also very impressed with how fast we have been able to get a
system up and running with such powerful features

Talk  to you all soon,

Ian Caddy

--

ianc at microsol.iinet.net.au
Microsol (Aust) Pty Ltd

Phone: (+61) 08 9473 6600
Fax:   (+61) 08 9473 6699





More information about the users mailing list