Hi Kedar,
On 3/15/19 11:04 AM, Appana Durga Kedareswara Rao wrote:
Having about 10 elements in a CAN driver tx queue allows to work with
queueing disciplines
(http://rtime.felk.cvut.cz/can/socketcan-qdisc-final.pdf) and also to maintain a
nearly real-time behaviour with outgoing traffic.
When the CAN interface is not able to cope with the (intened) outgoing traffic
load, the applications should get an instant feedback about it.
There is a difference between running CAN applications in the real world and
doing performance tests, where it makes sense to increase the tx-queue-len to
e.g. 1000 and dump 1000 frames into the driver to check the hardware
performance.
Thanks, Oliver, Martin, Andre, Toke, Dave for your inputs...
So to conclude this the default txqueuelen 10 is ideal for real-time CAN traffic,
For Stress/Performance tests user manually need to increase the txqueuelen based on his requirements.
Please correct me if my understanding is wrong.
Yes, I would confirm that approach.
As Martin Jerabek pointed to a discussion with Michal Sojka here:
https://marc.info/?l=linux-can&m=155222580602047&w=2
You might also go for a more academic view based on the number of
different CAN applications on the host.
@Martin: Would you like to propose a patch for can.txt (now can.rst)?
Regards,
Oliver
