Hi,
I have been debugging a case of random loss of certain CAN frames at the RX end,
when I use the c_can driver.
I use a fairly simple setup:
~ For TX, I use a vector CANAnalyzer tool (which can generate CAN frames
with high bus load)
~ At RX end I use my board which has a bosch c_can core and use the
`candump` application to dump all the frames arriving on the CAN
interface.
~ For testing I compare the sent frames with the frames received by
candump.
I driver is available in david miller's net-next here:
http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=tree;f=drivers/net/can/c_can;h=3237fb1a163258cc364b366976119090d94ea27d;hb=HEAD
and is written by me.
I am wondering whether this random loss can be due to NAPI, as I remember a
case while designing a Ethernet driver that the NAPI implementation will
mitigate the RX interrupt load but sometimes some frames would be dropped
at the RX end and would never reach the stack.
In such a case the design we usually implement, to keep two buckets of RX
messages to ensure in-order reception of RX packets:
~ Lower Bucket: which stores the RX frames, but the interrupts of these
lower bucket message objects are not cleared until we reach the SPLIT
mark
between the lower and upper bucket.
~ Upper Bucket: which acts as a sort of buffer for overflow objects.
Can this design and the NAPI quota combination have some impact on the number
of frames
lost during RX?
Any ideas?
Regards,
Bhupesh
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
