Hi Bhupesh, On 06/07/2011 07:00 AM, 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. > > 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?
NAPI will slow down reading and processing CAN messages from the CAN controller to some extent. Therefore the risk to loose messages will be slightly higher, especially on slow low-end systems and at hight message rate. As Oliver pointed out, messages could also be dropped when the user space task can not keep up with the rate. When they are dropped by the CAN controller, then you might get an error message. Therefore it's always good practice to use: "# candump -d any 0:0,#FFFFFFFF". Also "ip -d -s link show canX" may list useful information. Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
