Networking: Still waiting for mbuf cluster.
chrisj at rtems.org
Wed Sep 26 07:38:22 UTC 2007
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.
More information about the users