Network driver for SMSC91c111 and linked mbufs

[Ian Caddy]

Hi Jonas,

Just another thought on this, getting back to writing a byte to the 
FIFO, just do the word DMA transfer as I originally indicated, but this 
time writing a word instead of the last byte, so you have written an 
extra rubbish byte.

Then on the completion of that DMA transfer, check if you have written 
too much and if so, adjust the tx PTR register to go back one byte, 
ready for your next transfer.  The SMC chip allows you to write byte or 
words on odd boundaries without limitation, so this would be no problem.

Then just start your next DMA transfer for the next mbuf.

It should be fairly straight forward.

I hope this helps.

regards,


Ian Caddy


Ian Caddy wrote:
> 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
>>>
>>
>>
>>
>