C_CAN: can frame drops

RFC In review Ssagarr Patil 4 participants 27 messages Jul 23, 2014 – Dec 18, 2014 CAN network drivers

Share & tools

Ssagarr Patil

author

2014-07-23 14:53 UTC #0 lore raw

Hi,

I am using the c_can driver for latest kernel and using the latest canutils to dump to a file. My can bus is set at a rate of 1Mb (receiving 7000fps bus load of 80%).

When I use the candump tool to dump can frames I get following message,

'DROPCOUNT: dropped 2223 CAN frames on 'any' socket (total drops 1629092)'

SO to solve this problem if I use the -r option of candump and tried candump any -d -e -r 999999999 -l

If I do this the can frames are dropped in the driver ie I see
this c_can_handle_lost_msg_obj() function being called frequently in which can frame is overwritten.

How to solve this issue any pointers would be helpful.

Thanks,
--Sagar

Oliver Hartkopp

2014-07-23 16:04 UTC #1 lore raw

Hello Sagar,

generally dropping CAN frames on driver level is a complete different problem in opposite to dropping CAN frames on socket receive level.

A drop on the socket layer usually occurs, when the application does not get enough CPU time to read and process the CAN frames. But drops on CAN driver layer lead to a possible resource problem on your system.

Can you tell a bit more about your platform (hardware, CPU, cpu clock, RAM) and Linux Kernel version?

Regards,
Oliver

Quoted 25 lines · Ssagarr Patil

Hi,
I am using the c_can driver for latest kernel and using the latest canutils to dump to a file. My can bus is set at a rate of 1Mb (receiving 7000fps bus load of 80%).
When I use the candump tool to dump can frames I get following message,
'DROPCOUNT: dropped 2223 CAN frames on 'any' socket (total drops 1629092)'
SO to solve this problem if I use the -r option of candump and tried candump any -d -e -r 999999999 -l
If I do this the can frames are dropped in the driver ie I see
this c_can_handle_lost_msg_obj() function being called frequently in which can frame is overwritten.
How to solve this issue any pointers would be helpful.
Thanks,
--Sagar
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Ssagarr Patil

author

2014-07-23 16:33 UTC #2 lore raw

Hi Oliver,

Thanks for your response :-)

Quoted 4 lines

generally dropping CAN frames on driver level is a complete different problem in opposite to dropping CAN frames on socket receive level.

Agreed.

Quoted 4 lines

A drop on the socket layer usually occurs, when the application does not get enough CPU time to read and process the CAN frames. But drops on CAN driver layer lead to a possible resource problem on your system.

For the application layer I have used chrt so that it gets higher priority.

Quoted 3 lines

Can you tell a bit more about your platform (hardware, CPU, cpu clock, RAM) and Linux Kernel version?

The Linux version is 2.6.37 where as I have patched this kernel to use the v3.15 C_CAN driver(which uses D_CAN) to use.

Hardware is DM8148 EVM, ARM clock is @1000Mhz, DDR @533Mhz,

Regards,
--Sagar

Quoted 34 lines

Regards,
Oliver
Quoted 16 lines · Ssagarr Patil
Hi,
I am using the c_can driver for latest kernel and using the latest canutils to dump to a file. My can bus is set at a rate of 1Mb (receiving 7000fps bus load of 80%).
When I use the candump tool to dump can frames I get following message,
'DROPCOUNT: dropped 2223 CAN frames on 'any' socket (total drops 1629092)'
SO to solve this problem if I use the -r option of candump and tried candump any -d -e -r 999999999 -l
If I do this the can frames are dropped in the driver ie I see
this c_can_handle_lost_msg_obj() function being called frequently in which can frame is overwritten.
Quoted 9 lines
How to solve this issue any pointers would be helpful.
Thanks,
--Sagar
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Ssagarr Patil

author

2014-07-24 07:40 UTC #3 lore raw

Quoted 16 lines

Hi Oliver,
Thanks for your response :-)
Quoted 4 lines
generally dropping CAN frames on driver level is a complete different problem in opposite to dropping CAN frames on socket receive level.
Agreed.
Quoted 4 lines
A drop on the socket layer usually occurs, when the application does not get enough CPU time to read and process the CAN frames. But drops on CAN driver layer lead to a possible resource problem on your system.
For the application layer I have used chrt so that it gets higher priority.

Quoted 7 lines

Quoted 3 lines
Can you tell a bit more about your platform (hardware, CPU, cpu clock, RAM) and Linux Kernel version?
The Linux version is 2.6.37 where as I have patched this kernel to use the v3.15 C_CAN driver(which uses D_CAN) to use.
Hardware is DM8148 EVM, ARM clock is @1000Mhz, DDR @533Mhz,

BTW I also tried it on AM335x with the v3.16-rc5 which supports D_CAN the problem is the same.

Thanks,
--Sagar

Quoted 39 lines

Regards,
--Sagar
Quoted 34 lines
Regards,
Oliver
Quoted 16 lines · Ssagarr Patil
Hi,
I am using the c_can driver for latest kernel and using the latest canutils to dump to a file. My can bus is set at a rate of 1Mb (receiving 7000fps bus load of 80%).
When I use the candump tool to dump can frames I get following message,
'DROPCOUNT: dropped 2223 CAN frames on 'any' socket (total drops 1629092)'
SO to solve this problem if I use the -r option of candump and tried candump any -d -e -r 999999999 -l
If I do this the can frames are dropped in the driver ie I see
this c_can_handle_lost_msg_obj() function being called frequently in which can frame is overwritten.
Quoted 9 lines
How to solve this issue any pointers would be helpful.
Thanks,
--Sagar
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Oliver Hartkopp

2014-07-24 18:09 UTC #4 lore raw

Hi Sagar,

unfortunately I'm not really a C_CAN expert.

I know from a Beaglebone Black which run's at 99% busload without any issues on the two integrated D_CAN controllers.

Do you have these problems with a stock 2.6.37.x on your hardware too?

Can you send the dmesg output of the c_can related content?

Regards,
Oliver

Quoted 71 lines · Ssagarr Patil

Quoted 16 lines
Hi Oliver,
Thanks for your response :-)
Quoted 4 lines
generally dropping CAN frames on driver level is a complete different problem in opposite to dropping CAN frames on socket receive level.
Agreed.
Quoted 4 lines
A drop on the socket layer usually occurs, when the application does not get enough CPU time to read and process the CAN frames. But drops on CAN driver layer lead to a possible resource problem on your system.
For the application layer I have used chrt so that it gets higher priority.
Quoted 7 lines
Quoted 3 lines
Can you tell a bit more about your platform (hardware, CPU, cpu clock, RAM) and Linux Kernel version?
The Linux version is 2.6.37 where as I have patched this kernel to use the v3.15 C_CAN driver(which uses D_CAN) to use.
Hardware is DM8148 EVM, ARM clock is @1000Mhz, DDR @533Mhz,
BTW I also tried it on AM335x with the v3.16-rc5 which supports D_CAN the problem is the same.
Thanks,
--Sagar
Quoted 39 lines
Regards,
--Sagar
Quoted 34 lines
Regards,
Oliver
Quoted 16 lines · Ssagarr Patil
Hi,
I am using the c_can driver for latest kernel and using the latest canutils to dump to a file. My can bus is set at a rate of 1Mb (receiving 7000fps bus load of 80%).
When I use the candump tool to dump can frames I get following message,
'DROPCOUNT: dropped 2223 CAN frames on 'any' socket (total drops 1629092)'
SO to solve this problem if I use the -r option of candump and tried candump any -d -e -r 999999999 -l
If I do this the can frames are dropped in the driver ie I see
this c_can_handle_lost_msg_obj() function being called frequently in which can frame is overwritten.
Quoted 9 lines
How to solve this issue any pointers would be helpful.
Thanks,
--Sagar
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Ssagarr Patil

author

2014-07-25 08:20 UTC #5 lore raw

Hi Oliver,

Quoted 6 lines

unfortunately I'm not really a C_CAN expert.
I know from a Beaglebone Black which run's at 99% busload without any issues on the two integrated D_CAN controllers.

Ok.

Quoted 2 lines

Do you have these problems with a stock 2.6.37.x on your hardware too?

Yes

Quoted 2 lines

Can you send the dmesg output of the c_can related content?

Unfortunately in c_can driver there are no lot of debug prints but I am only concerned about function c_can_handle_lost_msg_obj() being called frequently in which can frame is overwritten.

Rest of the driver works fine.

Regards,
--Sagar

Marc Kleine-Budde

maintainer

2014-07-25 07:18 UTC #6 lore raw

In reply to Ssagarr Patil

Quoted 8 lines · Ssagarr Patil

Hi,
I am using the c_can driver for latest kernel and using the latest canutils to dump to a file. My can bus is set at a rate of 1Mb (receiving 7000fps bus load of 80%).
When I use the candump tool to dump can frames I get following message,
'DROPCOUNT: dropped 2223 CAN frames on 'any' socket (total drops 1629092)'

These are the CAN frames dropped by the socket, this means as Oliver pointed out, that the candump fails to read the CAN frames fast enough from the socket. How do you connect to the linux box with the c_can? Where are the CAN frames printed to?

Dropped CAN frames by the hardware should be counted in the rx dropped in ifconfig.

Marc

Signature · 4 lines

Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

Ssagarr Patil

author

2014-07-25 08:13 UTC #7 lore raw

Hi Marc,

Quoted 4 lines

Quoted 4 lines
I am using the c_can driver for latest kernel and using the latest canutils to dump to a file. My can bus is set at a rate of 1Mb (receiving 7000fps bus load of 80%).

Quoted 9 lines

Quoted 3 lines
When I use the candump tool to dump can frames I get following message,
'DROPCOUNT: dropped 2223 CAN frames on 'any' socket (total drops 1629092)'
These are the CAN frames dropped by the socket, this means as Oliver pointed out, that the candump fails to read the CAN frames fast enough from the socket. How do you connect to the linux box with the c_can? Where are the CAN frames printed to?

Agreed this is dropped by the socket, so for this to solve I increased the socket size (with -r option of candump to 111173056) after doing this I see that there is frame drop in the driver ie I see this function c_can_handle_lost_msg_obj() being called frequently in which can frame is overwritten.

I have a can frame generator which I have connected to the EVM, the EVM is recieving the frames and just dumping it on stdout going ahead I need to log the canframes to SD card.

Quoted 2 lines

Dropped CAN frames by the hardware should be counted in the rx dropped in ifconfig.

Yes I can even see this too.

Thanks,
--Sagar

Marc Kleine-Budde

maintainer

2014-07-25 08:16 UTC #8 lore raw

Quoted 12 lines · Ssagarr Patil

Quoted 12 lines
Quoted 6 lines
I am using the c_can driver for latest kernel and using the latest canutils to dump to a file. My can bus is set at a rate of 1Mb (receiving 7000fps bus load of 80%).
When I use the candump tool to dump can frames I get following message,
'DROPCOUNT: dropped 2223 CAN frames on 'any' socket (total drops 1629092)'
These are the CAN frames dropped by the socket, this means as Oliver pointed out, that the candump fails to read the CAN frames fast enough from the socket. How do you connect to the linux box with the c_can? Where are the CAN frames printed to?

Quoted 7 lines

Agreed this is dropped by the socket, so for this to solve I increased the socket size (with -r option of candump to 111173056) after doing this I see that there is frame drop in the driver ie I see this function c_can_handle_lost_msg_obj() being called frequently in which can frame is overwritten.
I have a can frame generator which I have connected to the EVM, the EVM is recieving the frames and just dumping it on stdout going ahead I need to log the canframes to SD card.

...and where is your stdout going? serial line, telnet, ssh?

Marc

Signature · 4 lines

Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

Ssagarr Patil

author

2014-07-25 08:22 UTC #9 lore raw

Hi Marc,

Quoted 19 lines · Ssagarr Patil

Quoted 17 lines
Quoted 12 lines
Quoted 6 lines
I am using the c_can driver for latest kernel and using the latest canutils to dump to a file. My can bus is set at a rate of 1Mb (receiving 7000fps bus load of 80%).
When I use the candump tool to dump can frames I get following message,
'DROPCOUNT: dropped 2223 CAN frames on 'any' socket (total drops 1629092)'
These are the CAN frames dropped by the socket, this means as Oliver pointed out, that the candump fails to read the CAN frames fast enough from the socket. How do you connect to the linux box with the c_can? Where are the CAN frames printed to?
Agreed this is dropped by the socket, so for this to solve I increased the socket size (with -r option of candump to 111173056) after doing this I see that there is frame drop in the driver ie I see this function c_can_handle_lost_msg_obj() being called frequently in which can frame is overwritten.

Quoted 5 lines

Quoted 2 lines
I have a can frame generator which I have connected to the EVM, the EVM is recieving the frames and just dumping it on stdout going ahead I need to log the canframes to SD card.
...and where is your stdout going? serial line, telnet, ssh?

Its the serial line.

Regards,
--Sagar

Marc Kleine-Budde

maintainer

2014-07-25 08:27 UTC #10 lore raw

Quoted 21 lines · Ssagarr Patil

Hi Marc,
Quoted 19 lines · Ssagarr Patil
Quoted 17 lines
Quoted 12 lines
Quoted 6 lines
I am using the c_can driver for latest kernel and using the latest canutils to dump to a file. My can bus is set at a rate of 1Mb (receiving 7000fps bus load of 80%).
When I use the candump tool to dump can frames I get following message,
'DROPCOUNT: dropped 2223 CAN frames on 'any' socket (total drops 1629092)'
These are the CAN frames dropped by the socket, this means as Oliver pointed out, that the candump fails to read the CAN frames fast enough from the socket. How do you connect to the linux box with the c_can? Where are the CAN frames printed to?
Agreed this is dropped by the socket, so for this to solve I increased the socket size (with -r option of candump to 111173056) after doing this I see that there is frame drop in the driver ie I see this function c_can_handle_lost_msg_obj() being called frequently in which can frame is overwritten.

Quoted 6 lines

Quoted 5 lines
Quoted 2 lines
I have a can frame generator which I have connected to the EVM, the EVM is recieving the frames and just dumping it on stdout going ahead I need to log the canframes to SD card.
...and where is your stdout going? serial line, telnet, ssh?
Its the serial line.

That's not good. As printing to the serial console is quite costly.

Marc

Signature · 4 lines

Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

Ssagarr Patil

author

2014-07-25 08:36 UTC #11 lore raw

Hi Marc,

Thanks for the response!

Quoted 23 lines · Ssagarr Patil

Quoted 21 lines
Hi Marc,
Quoted 19 lines · Ssagarr Patil
Quoted 17 lines
Quoted 12 lines
Quoted 6 lines
I am using the c_can driver for latest kernel and using the latest canutils to dump to a file. My can bus is set at a rate of 1Mb (receiving 7000fps bus load of 80%).
When I use the candump tool to dump can frames I get following message,
'DROPCOUNT: dropped 2223 CAN frames on 'any' socket (total drops 1629092)'
These are the CAN frames dropped by the socket, this means as Oliver pointed out, that the candump fails to read the CAN frames fast enough from the socket. How do you connect to the linux box with the c_can? Where are the CAN frames printed to?
Agreed this is dropped by the socket, so for this to solve I increased the socket size (with -r option of candump to 111173056) after doing this I see that there is frame drop in the driver ie I see this function c_can_handle_lost_msg_obj() being called frequently in which can frame is overwritten.

Quoted 9 lines

Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
I have a can frame generator which I have connected to the EVM, the EVM is recieving the frames and just dumping it on stdout going ahead I need to log the canframes to SD card.
...and where is your stdout going? serial line, telnet, ssh?
Its the serial line.
That's not good. As printing to the serial console is quite costly.

Yes agreed, although I also see some frame drops pointed by ifconfig can0 when dumping it to file (with -l option of candump)
I have also used chrt to increase the priority of candump.

Any suggestion on how to still improve the performance so as there is zero frame loss ? either on driver or application side.

Thanks,
--Sagar

Marc Kleine-Budde

maintainer

2014-07-25 08:48 UTC #12 lore raw

Quoted 4 lines · Ssagarr Patil

Quoted 4 lines
Quoted 3 lines
Quoted 2 lines
...and where is your stdout going? serial line, telnet, ssh?
Its the serial line.

Quoted 8 lines

Quoted 2 lines
That's not good. As printing to the serial console is quite costly.
Yes agreed, although I also see some frame drops pointed by ifconfig can0 when dumping it to file (with -l option of candump)
I have also used chrt to increase the priority of candump.
Any suggestion on how to still improve the performance so as there is zero frame loss ? either on driver or application side.

Use the latest kernel, at least v3.15 which has tglx's patches integrated. v3.16 might even be better. If you want to log all CAN messages, you can probably make use of recvmmsg() to receive more than one CAN frame at a time (instead of using recvmsg() or read()). When writing to disk, don't write a single CAN frame at a time, it's better to write large blocks, i.e. several 4k of data.

Depending on the actual c_can/d_can implementation you're using, there might be some optimisation left in the driver, i.e. use 32 bit access if possible. However before touching the driver, measurement to identify the hot spots should be done.

The next step would be to switch to preempt rt enabled system.

Hope that helps,
Marc

Signature · 4 lines

Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

Ssagarr Patil

author

2014-07-25 09:47 UTC #13 lore raw

Hi Marc,

Quoted 10 lines

Quoted 9 lines
Quoted 3 lines
That's not good. As printing to the serial console is quite costly.
Yes agreed, although I also see some frame drops pointed by ifconfig can0 when dumping it to file (with -l option of candump)
I have also used chrt to increase the priority of candump.
Any suggestion on how to still improve the performance so as there is zero frame loss ? either on driver or application side.

Quoted 7 lines

Use the latest kernel, at least v3.15 which has tglx's patches integrated. v3.16 might even be better. If you want to log all CAN messages, you can probably make use of recvmmsg() to receive more than one CAN frame at a time (instead of using recvmsg() or read()). When writing to disk, don't write a single CAN frame at a time, it's better to write large blocks, i.e. several 4k of data.

I am using the v3.16 (the master branch from git://gitorious.org/linux-can/linux-can.git)

OK will try experiment with recvmmsg() & and writing to disk with large blocks.

Quoted 5 lines

Depending on the actual c_can/d_can implementation you're using, there might be some optimisation left in the driver, i.e. use 32 bit access if possible. However before touching the driver, measurement to identify the hot spots should be done.

Quoted 2 lines

The next step would be to switch to preempt rt enabled system.

I am afraid I cant use this, as project needs to be run on normal Linux.

Thanks,
--Sagar

Marc Kleine-Budde

maintainer

2014-07-25 10:10 UTC #14 lore raw

Quoted 19 lines · Ssagarr Patil

Quoted 10 lines
Quoted 2 lines
Any suggestion on how to still improve the performance so as there is zero frame loss ? either on driver or application side.
Use the latest kernel, at least v3.15 which has tglx's patches integrated. v3.16 might even be better. If you want to log all CAN messages, you can probably make use of recvmmsg() to receive more than one CAN frame at a time (instead of using recvmsg() or read()). When writing to disk, don't write a single CAN frame at a time, it's better to write large blocks, i.e. several 4k of data.
I am using the v3.16 (the master branch from git://gitorious.org/linux-can/linux-can.git)
OK will try experiment with recvmmsg() & and writing to disk with large blocks.
Quoted 5 lines
Depending on the actual c_can/d_can implementation you're using, there might be some optimisation left in the driver, i.e. use 32 bit access if possible. However before touching the driver, measurement to identify the hot spots should be done.

Quoted 5 lines

OK
Quoted 2 lines
The next step would be to switch to preempt rt enabled system.
I am afraid I cant use this, as project needs to be run on normal Linux.

Preempt-rt is a normal Linux system, though. :)

Marc

Signature · 4 lines

Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

Ssagarr Patil

author

2014-07-25 11:22 UTC #15 lore raw

Hi Marc,

Quoted 21 lines · Ssagarr Patil

Quoted 19 lines
Quoted 10 lines
Quoted 2 lines
Any suggestion on how to still improve the performance so as there is zero frame loss ? either on driver or application side.
Use the latest kernel, at least v3.15 which has tglx's patches integrated. v3.16 might even be better. If you want to log all CAN messages, you can probably make use of recvmmsg() to receive more than one CAN frame at a time (instead of using recvmsg() or read()). When writing to disk, don't write a single CAN frame at a time, it's better to write large blocks, i.e. several 4k of data.
I am using the v3.16 (the master branch from git://gitorious.org/linux-can/linux-can.git)
OK will try experiment with recvmmsg() & and writing to disk with large blocks.
Quoted 5 lines
Depending on the actual c_can/d_can implementation you're using, there might be some optimisation left in the driver, i.e. use 32 bit access if possible. However before touching the driver, measurement to identify the hot spots should be done.

Quoted 8 lines

Quoted 5 lines
OK
Quoted 2 lines
The next step would be to switch to preempt rt enabled system.
I am afraid I cant use this, as project needs to be run on normal Linux.
Preempt-rt is a normal Linux system, though. :)

Yes but our requirement is to not to have on rt-linux :(

Thanks,
--Sagar

Oliver Hartkopp

2014-07-25 10:43 UTC #16 lore raw

In reply to Ssagarr Patil

Hi Sagar,

Quoted 11 lines

Quoted 7 lines
If you want to log all CAN
messages, you can probably make use of recvmmsg() to receive more than one CAN frame at a time (instead of using recvmsg() or read()). When writing to disk, don't write a single CAN frame at a time, it's better to write large blocks, i.e. several 4k of data.
I am using the v3.16 (the master branch from git://gitorious.org/linux-can/linux-can.git)
OK will try experiment with recvmmsg() & and writing to disk with large blocks.

I implemented a proof-of-concept for recvmmsg() for candump.

You can try:

https://gitorious.org/linux-can/canpump

:-)

Maybe it helps.

Regards,
Oliver

Ssagarr Patil

author

2014-07-25 11:24 UTC #17 lore raw

Hi Oliver,

Quoted 13 lines

Quoted 8 lines
Quoted 8 lines
If you want to log all CAN
messages, you can probably make use of recvmmsg() to receive more than one CAN frame at a time (instead of using recvmsg() or read()). When writing to disk, don't write a single CAN frame at a time, it's better to write large blocks, i.e. several 4k of data.
Quoted 4 lines
I am using the v3.16 (the master branch from git://gitorious.org/linux-can/linux-can.git)
OK will try experiment with recvmmsg() & and writing to disk with large blocks.

Quoted 8 lines

I implemented a proof-of-concept for recvmmsg() for candump.
You can try:
https://gitorious.org/linux-can/canpump
:-)

Thanks for implementing it I was too doing the same thing although you have removed the logging part of it I am adding it and testing.

Thanks,
--sagar

Prabhakar Lad

2014-07-30 11:28 UTC #18 lore raw

In reply to Oliver Hartkopp

Hi Oliver,

Quoted 11 lines · Oliver Hartkopp

Hi Sagar,
Quoted 9 lines
Quoted 7 lines
If you want to log all CAN
messages, you can probably make use of recvmmsg() to receive more than one CAN frame at a time (instead of using recvmsg() or read()). When writing to disk, don't write a single CAN frame at a time, it's better to write large blocks, i.e. several 4k of data.
I am using the v3.16 (the master branch from git://gitorious.org/linux-can/linux-can.git)

Quoted 9 lines

Quoted 2 lines
OK will try experiment with recvmmsg() & and writing to disk with large blocks.
I implemented a proof-of-concept for recvmmsg() for candump.
You can try:
https://gitorious.org/linux-can/canpump

Any plans of adding this into mainline can-utils ?

Thanks,
--Prabhakar Lad

Oliver Hartkopp

2014-07-30 16:18 UTC #19 lore raw

Quoted 11 lines · Prabhakar Lad

Quoted 11 lines
Quoted 10 lines
Quoted 6 lines
If you want to log all CAN
messages, you can probably make use of recvmmsg() to receive more than one CAN frame at a time (instead of using recvmsg() or read()). When writing to disk, don't write a single CAN frame at a time, it's better to write large blocks, i.e. several 4k of data.
I am using the v3.16 (the master branch from git://gitorious.org/linux-can/linux-can.git)
OK will try experiment with recvmmsg() & and writing to disk with large blocks.

Quoted 9 lines

Quoted 6 lines
I implemented a proof-of-concept for recvmmsg() for candump.
You can try:
https://gitorious.org/linux-can/canpump
Any plans of adding this into mainline can-utils ?

Hm - currently not.

If it turns out to really help to increase the throughput for e.g. candump it would be worth thinking to integrate it into candump.

But so far there was no feedback from Sagar, if it was at least helpful.

So from my current perspective the canpump source code would be a candidate for can-tests as many other SocketCAN code examples are sitting there too.

Regards,
Oliver

Ssagarr Patil

author

2014-07-31 12:41 UTC #20 lore raw

Hi Oliver,

Sorry for the delayed response! was busy with other work load.

Quoted 22 lines

Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
Quoted 7 lines
If you want to log all CAN
messages, you can probably make use of recvmmsg() to receive more than one CAN frame at a time (instead of using recvmsg() or read()). When writing to disk, don't write a single CAN frame at a time, it's better to write large blocks, i.e. several 4k of data.
I am using the v3.16 (the master branch from git://gitorious.org/linux-can/linux-can.git)
OK will try experiment with recvmmsg() & and writing to disk with large blocks.
Quoted 9 lines
Quoted 6 lines
I implemented a proof-of-concept for recvmmsg() for candump.
You can try:
https://gitorious.org/linux-can/canpump
Any plans of adding this into mainline can-utils ?

Quoted 7 lines

Hm - currently not.
If it turns out to really help to increase the throughput for e.g. candump it would be worth thinking to integrate it into candump.
But so far there was no feedback from Sagar, if it was at least helpful.

Yes it was beneficial I used MSG_WAITALL flag for recvmmsg() so that it waits for n frames and there is no memory wastage.

Also is it possible to configure qdiscs for improving the performance ?

Regards,
--Sagar

Marc Kleine-Budde

maintainer

2014-07-31 12:43 UTC #21 lore raw

Quoted 31 lines · Ssagarr Patil

Hi Oliver,
Sorry for the delayed response! was busy with other work load.
Quoted 27 lines
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
Quoted 7 lines
If you want to log all CAN
messages, you can probably make use of recvmmsg() to receive more than one CAN frame at a time (instead of using recvmsg() or read()). When writing to disk, don't write a single CAN frame at a time, it's better to write large blocks, i.e. several 4k of data.
I am using the v3.16 (the master branch from git://gitorious.org/linux-can/linux-can.git)
OK will try experiment with recvmmsg() & and writing to disk with large blocks.
Quoted 9 lines
Quoted 6 lines
I implemented a proof-of-concept for recvmmsg() for candump.
You can try:
https://gitorious.org/linux-can/canpump
Any plans of adding this into mainline can-utils ?
Hm - currently not.
If it turns out to really help to increase the throughput for e.g. candump it would be worth thinking to integrate it into candump.

Quoted 6 lines

Quoted 2 lines
But so far there was no feedback from Sagar, if it was at least helpful.
Yes it was beneficial I used MSG_WAITALL flag for recvmmsg() so that it waits for n frames and there is no memory wastage.
Also is it possible to configure qdiscs for improving the performance ?

AFAIK qdiscs are only used in the tx path.

Marc

Signature · 4 lines

Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

Oliver Hartkopp

2014-07-31 14:11 UTC #22 lore raw

Quoted 7 lines · Marc Kleine-Budde

Quoted 5 lines · Ssagarr Patil
Quoted 2 lines
But so far there was no feedback from Sagar, if it was at least helpful.
Yes it was beneficial I used MSG_WAITALL flag for recvmmsg() so that it waits for n frames and there is no memory wastage.

This is probably not usable for candump, which has to provide the displayed CAN frames pretty fast. I think there's some timeout mechanism too, to stop the infinitive waiting for n frames.

Quoted 3 lines

Quoted 1 line
Also is it possible to configure qdiscs for improving the performance ?
AFAIK qdiscs are only used in the tx path.

Yep! See:
http://rtime.felk.cvut.cz/can/socketcan-qdisc-final.pdf

Regards,
Oliver

Prabhakar Lad

2014-07-31 14:19 UTC #23 lore raw

Hi Oliver,

Quoted 5 lines · Oliver Hartkopp

Quoted 4 lines · Marc Kleine-Budde
Quoted 2 lines · Ssagarr Patil
Quoted 2 lines
But so far there was no feedback from Sagar, if it was at least helpful.

Quoted 8 lines

Quoted 3 lines
Quoted 3 lines
Yes it was beneficial I used MSG_WAITALL flag for recvmmsg() so that it waits for n frames and there is no memory wastage.
This is probably not usable for candump, which has to provide the displayed CAN frames pretty fast. I think there's some timeout mechanism too, to stop the infinitive waiting for n frames.

It would be helpful with -l option being enabled ?

Regards,
--Prabhakar Lad

Quoted 11 lines

Quoted 3 lines
Quoted 1 line
Also is it possible to configure qdiscs for improving the performance ?
AFAIK qdiscs are only used in the tx path.
Yep! See:
http://rtime.felk.cvut.cz/can/socketcan-qdisc-final.pdf
Regards,
Oliver

Oliver Hartkopp

2014-12-18 09:42 UTC #24 lore raw

RFC 1/1 sched policies for candump

Hello Prabhakar,

I just discovered your pull-request for candump to add scheduling policies for candump:

https://gitorious.org/linux-can/can-utils/commit/0ea8caacfa723271778d000e8cb97b2be4f92165

Is this still needed / valuable?

If so I would suggest to make the commandline option able to handle more than only SCHED_RR ...

Would the following patch be ok for you?

Regards,
Oliver

---

candump.c +33 -1

index a1146f5..4334be5 100644
@@ -51,6 +51,7 @@
 #include <libgen.h>
 #include <time.h>
 #include <errno.h>
+#include <sched.h>
 
 #include <sys/time.h>
 #include <sys/types.h>

@@ -124,6 +125,7 @@ void print_usage(char *prg)
 	fprintf(stderr, "         -e          (dump CAN error frames in human-readable format)\n");
 	fprintf(stderr, "         -x          (print extra message infos, rx/tx brs esi)\n");
 	fprintf(stderr, "         -T <msecs>  (terminate after <msecs> without any reception)\n");
+	fprintf(stderr, "         -R <p:prio> (set priority for scheduling policy p={R,F})\n");
 	fprintf(stderr, "\n");
 	fprintf(stderr, "Up to %d CAN interfaces with optional filter sets can be specified\n", MAXSOCK);
 	fprintf(stderr, "on the commandline in the form: <ifname>[,filter]*\n");

@@ -216,6 +218,8 @@ int main(int argc, char **argv)
 	unsigned char logfrmt = 0;
 	int count = 0;
 	int rcvbuf_size = 0;
+	int sched_policy = 0;
+	int sched_priority = 0;
 	int opt, ret;
 	int currmax, numfilter;
 	char *ptr, *nptr;

@@ -240,7 +244,7 @@ int main(int argc, char **argv)
 	last_tv.tv_sec  = 0;
 	last_tv.tv_usec = 0;
 
-	while ((opt = getopt(argc, argv, "t:ciaSs:b:B:u:ldxLn:r:heT:?")) != -1) {
+	while ((opt = getopt(argc, argv, "t:ciaSs:b:B:u:ldxLn:r:heT:R:?")) != -1) {
 		switch (opt) {
 		case 't':
 			timestamp = optarg[0];

@@ -366,6 +370,23 @@ int main(int argc, char **argv)
 			timeout_config.tv_usec = (timeout_config.tv_usec % 1000) * 1000;
 			timeout_current = &timeout;
 			break;
+
+		case 'R':
+		{
+			/* check for supported scheduling policy 'p:<prio>' */
+			if (optarg[0] == 'R' && optarg[1] == ':')
+				sched_policy = SCHED_RR;
+			else if (optarg[0] == 'F' && optarg[1] == ':')
+				sched_policy = SCHED_FIFO;
+			else {
+				print_usage(basename(argv[0]));
+				exit(1);
+			}
+			/* get priority from behind the ':' */
+			sched_priority = atoi(optarg+2);
+			break;
+		}
+
 		default:
 			print_usage(basename(argv[0]));
 			exit(1);

@@ -596,6 +617,17 @@ int main(int argc, char **argv)
 		}
 	}
 
+	/* set scheduler policy and priority */
+	if (sched_policy) {
+		struct sched_param sched;
+
+		memset(&sched, 0, sizeof sched);
+		sched.sched_priority = sched_priority;
+		if (sched_setscheduler(0, sched_policy, &sched) < 0)
+			fprintf(stderr, "\nFailed to select scheduler policy: %s (%d)\n",
+				strerror(errno), errno);
+	}
+
 	/* these settings are static and can be held out of the hot path */
 	iov.iov_base = &frame;
 	msg.msg_name = &addr;

Prabhakar Lad

2014-12-18 12:33 UTC #25 lore raw

Re: [RFC] sched policies for candump

Hi Oliver,

Quoted 8 lines · Oliver Hartkopp

Hello Prabhakar,
I just discovered your pull-request for candump to add scheduling policies for candump:
https://gitorious.org/linux-can/can-utils/commit/0ea8caacfa723271778d000e8cb97b2be4f92165
Is this still needed / valuable?

If I remember correctly we agreed upon using chrt/nice to achieve this.

But I still feel having an option in the tool itself would be better choice as some
of the novice users might not be aware of chrt/nice.

Quoted 4 lines

If so I would suggest to make the commandline option able to handle more than only SCHED_RR ...
Would the following patch be ok for you?

I am OK with it, but still depends on Marc.

Regards,
--Prabhakar Lad

Oliver Hartkopp

2014-12-18 13:51 UTC #26 lore raw

Re: [RFC] sched policies for candump

Quoted 8 lines · Prabhakar Lad

Quoted 2 lines
Is this still needed / valuable?
If I remember correctly we agreed upon using chrt/nice to achieve this.
But I still feel having an option in the tool itself would be better choice as some
of the novice users might not be aware of chrt/nice.

Ah - now I remember myself.

The point was that you then become in charge to put this into all relevant tools - which is probably not what you want.

So increase the awareness for novice users to use chrt/nice looks like the better option ;-)

Best regards,
Oliver