Networking: Still waiting for mbuf cluster.

[Keith Robertson]

Torsten Landschoff wrote:
> Hi Thomas,
> 
> Thanks for your reply.
> 
> Thomas Doerfler wrote:
>> the messages you mentioned are a typical signal, that someone (the
>> driver?) eats up the network buffers. Either they are dropped and not
>> properly returned to the free buffer pool, or they are stuck to the
>> transmit queue.

Or, the application is using lots of mbufs and hasn't read the data out 
of the ip stack yet.

> Okay, so much seems clear to me. It's just that an ping -f works fine,
> therefore I would expect the driver to correctly transmit and receive
> packets. It also creates a hell lot of interrupts - there is a lot of
> room for improvements of the xiltemac driver.

What type of improvements are you thinking of?  The one area for 
improvement that I'm aware of is adding (almost) zero copy sending. 
Currently the driver copies out of mbuf into a buffer because the emac 
requires aligned data.  With open/close semantics on the tx writing, it 
is possible to remove most of this copying and writing directly to the 
emac from the mbuf.

>> I saw this once, when the network driver's transmit interrupt did not
>> properly clean up things. You should make sure that:
>>
>> - The ethernet hardware properly generates interrupts, when a buffer has
>> been transmitted
>>   
> Good point. I was sure the driver would work once the original interrupt
> connection is working. The network statistics of the Temac driver look
> suspicious:
> 
> xiltemac: Statistics for interface 'eth0'
> xiltemac:        Ipif Interrupts: 1041
> xiltemac:          Rx Interrupts: 1041
> xiltemac: Rx Rejected Interrupts: 0
> xiltemac:   Rx Rej Invalid Frame: 0
> xiltemac:  Rx Rej Data Fifo Full: 0
> xiltemac:Rx Rej Length Fifo Full: 0
> xiltemac:        Rx Stray Events: 0
> xiltemac:         Rx Max Drained: 12
> xiltemac:          Tx Interrupts: 0
> xiltemac:         Tx Max Drained: 2

I don't see any inherent problems with these statistics.  You only get 
tx interrupts in this driver under heavy load.  Otherwise tx interrupts 
do not need to be enabled.  The Rx Max drained indicates that at one 
point you received 12 packets whilst copying data out the hardware into 
mbufs.

> So I'll have to look into the Tx interrupt handling, it seems. As the
> same code is working with another FPGA setup, I think it might be that
> the tx interrupt was improperly routed. Let's see.
>> - The network driver makes sure that it cleans up the transmitted
>> buffers, even if it gets only one transmit interrupt for multiple
>> buffers transmitted.
>>

This virtex networking driver doesn't depend on tx interrupts to free 
mbufs.  They always get freed as soon as the data is copied into the 
hardware.

Cheers.

Keith