Network driver for SMSC91c111 and linked mbufs

[Ian Caddy]

Hi Jonas,

Hmm, that is no good about not being able to perform byte addressing.

Let me preface this discussion by saying I am in no way a BSD stack 
guru, but I know enough to be dangerous... ;-)

On the mbuf side there are two forms that it can take, it can be a 
standard mbuf or it can be an mbuf cluster.  From memory, mbufs are 
around 256 bytes, although not all that is usable, and mbuf clusters are 
I think 2048 bytes (I have not checked these values).

While the IP and TCP headers are going to be of even length, there is 
nothing to state that your user data is going to be even length.  In a 
TCP frame, a user application may send 5 chunks of data that are each of 
odd length.  If these are small enough, each will be alocated when send 
is called into an mbuf (or cluster is they are larger).  If these chunks 
of data are seny close enough together in time, they may be packed into 
one TCP frame that will be sent out the Ethernet.  In this case you will 
have a linked list of mbufs, containing the IP and TCP headers, and one 
mbuf for each of the chunks of data (which could be odd) forming the one 
linked list to be sent out.  In this case you could have a number of odd 
length mbufs in the middle of your frame.

I am sorry, you probably didn't want to hear this, but you can not 
guarantee you will not have odd length mbufs in the middle of your frames.

regards,

Ian Caddy


Jonas Moberg wrote:
> 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
>>
> 
> 
>