Networking: Still waiting for mbuf cluster.

[Chris Johns]

Torsten Landschoff wrote:
> Hi Chris,
> 
> Chris Johns wrote:
>> Torsten Landschoff wrote:
>>> 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.
>> The continuous stream of packets and therefore interrupts can be
>> keeping the driver working. I have seen cases like this on other
>> hardware and it tended to be the way the interrupt acknowledge
>> sequence worked.
> I can't really follow what you are trying to say. Either
> a) "Creating a lot of interrupts is normal and it should be that way." or
> b) "No wonder your system breaks down with that many interrupts."

I am saying neither. I am saying the sequence which you acknowledge the 
interrupts can result in this type of behavior. For example a stream of 
interrupts can prime an edge in some part of the hardware and therefore make 
it all work. Maybe a receive interrupt causes you to handle a tx request as 
well. In a system I worked on we had a problem of interrupts stopping and it 
was found to be the interrupt controller configured for edge rather than 
level. In some cases the interrupt triggered before the acknowledge and the 
edge was missed. Being a level interrupt fixed it.

> 
> About (a): I was referring to the fact that the Xilinx tri-mode MAC
> supports interrupt coalescing. However, as I just noticed, this is only
> supported when scatter-gather DMA is enable. Currently neither my FPGA
> configuration nor the RTEMS driver support that.
> 
> About (b): Interestingly, the working configuration generates as many
> interrupts and works flawless (what ttcp is concerned at least).
> 

What I was trying to say is maybe the driver is fine and the issue is up 
stream in the interrupt configuration or how those interrupts are acknowledged.

Regards
Chris