Network driver for SMSC91c111 and linked mbufs

[Jonas Moberg]

Ian, Thanks for your information. I have double checked the 5249 user manual
and there is
(as far as I can see) no way to write individual bytes (no a0, no BWEx
signals).
I have browsed the linux driver "smc91111" that supports the mcf5206c3
evaluation board
and have found that a CONFIG_SMC16BITONLY switch has been added to support
this
variant.
However the linux net uses a sk_buf's that is large enough to hold a
complete ethernet packet.
This buffer could have an even or odd length - this is not a problem as we
only have to set
the "odd length" bit when completing the frame to the 91111 controller.
To my real question:
As I understand RTEMS may allocate several mbufs to hold one ethernet
packet.
If one mbuf is not enough and there is a need to chain another buffer - what
would be the reason
for such buffer not be of certain (even) size?
Best regards
Jonas Moberg
----- Original Message -----
From: "Ian Caddy" <ianc at microsol.iinet.net.au>
To: "Jonas Moberg" <jonas.moberg at solidsoftware.net>
Cc: <rtems-users at rtems.com>
Sent: Monday, November 22, 2004 3:19 AM
Subject: Re: Network driver for SMSC91c111 and linked mbufs


> Hi Jonas,
>
>
>
> Jonas Moberg wrote:
> > When tx-ing an ethernet packet that is assembled from linked mbufs -
could
> > ever the mbufs have
> > an odd length (except for the last mbuf in chain if the complete frame
has
> > an odd length).
>
> Yes, it is quite possible for mbufs to have an odd length.
>
> > Our problem is that the mcf5249 Coldfire chip can not issue external
byte
> > writes so that all accesses
> > to the network controller must be words.
>
> Are you sure about this.  I am not directly familiar with the mcf5249,
> but we use a MCF5307 with the SMC chip, and all you need to do is use
> the BWE0 and BWE1 lines to setup a byte write to the SMC chip.  Does the
> 5248 have BWE lines?
>
>
> > I can see no way to put single bytes in the tx fifo and then continue
> > writing words again
> > on next mbuf boundry.
>
> The way we look after this is that we do DMA transfers for each mbuf.
> When you setup the DMA, make sure it is an exact number of words, by
> ANDing the length with 0xFFFE.  Then on the DMA Tx completion, we check
> if there is a byte left in the mbuf and write the individual byte out to
> the SMC chip, setup the next DMA transfer for the next mbuf (if
> required) and start the DMA up again.
>
> > Re-aligning between a potential "odd mbuf chained to next mbuf" would
then
> > degrade performance.
>
> This may also not be possible, as I am fairly sure the DMA will want to
> perform word transfers on a word boundary, but before anyone says
> otherwise, I haven't checked this, it is just a hunch... ;-)
>
> You still could transmit the Ethernet packets at the Tx task level, and
> the performance hit is not that great, as in a tight loop, the cache
> will be used for the instructions so they will be executing at full
> speed, but it will be interrupted by interrupts (unless you turn off the
> interrupts, but will increase your latency).
>
> regards,
>
> Ian Caddy
>