On 07.06.2011 07:00, Bhupesh SHARMA wrote: > 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.
Hello Bhupesh, the first interesting thing would be to check whether the frames are dropped on socketlayer (due to a slow processing in userspace) or somewhere in the driver. Please run the candump with the '-d' option, that enables the dropcounter in the socket receive path. See details here: https://lists.berlios.de/pipermail/socketcan-users/2010-January/001226.html If it's not on the socketlayer it's worth checking the driver ;-) Regards, Oliver > > 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 _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
