Re: increase buffer size

Re: increase buffer size

[Oliver Hartkopp]

Hi Steffen,

On 24.01.2012 12:18, Steffen Rose wrote:

> I want to increase the transmit quere of a can device.


You can do this with ifconfig or the 'ip' tool from the iproute2 package.

Examples:

ifconfig can0 txqueuelen 1000

or

ip link set can0 txqueuelen 1000


> 
> As I understand, the virtual devices don't have a quere. Is it right?
> 


Generally yes. A vcan is a software device like the 'lo' interface for IP.
Both (vcan & lo) transfer the packets directly back to the rx queue instantly.

But you can create vcans having a tx-queue len:

Here i created a virtual CAN interface 'xxx' with a txqueuelen of 10:

root# ip link add xxx type vcan
root# ip link set xxx txqueuelen 10
root# ip link set xxx up
root# ip link show xxx
10: xxx: <NOARP,UP,LOWER_UP> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 10
    link/can
root#

But this has no effect as long as you do not add some kind of queueing
discipline that throttles the bandwidth on the specific interface.

> As I understand, for physical devices the transmit quere is located within the 
> sockets, not in the can device driver. Is it right?


The tx buffers of the sockets are not really used e.g. for CAN_RAW sockets.
The tx queue len of the CAN network interface are relevant for you.

> 
> Do you have an small code snippet for the changing of the quere size?


Better use the tools stated above.

But you can (as root) modify these values e.g. with netlink sockets.

Regards,
Oliver

ps.

please do not use this mailing list any longer but send your questions
to the new "linux-can" mailing list address "linux-can-u79uwXL29TY76Z2rM5mHXA@public.gmane.org".
For subscription or mailing list archives please have a look to:

   http://vger.kernel.org/vger-lists.html#linux-can

Mail archives of the new linux-can mailing list can be found at:

   http://dir.gmane.org/gmane.linux.can
   http://marc.info/?l=linux-can&r=1&w=2

Re: [Socketcan-users] increase buffer size

[Steffen Rose]

Hello Oliver

Am Dienstag, 24. Januar 2012, 13:01:45 schrieb Oliver Hartkopp:
> ifconfig can0 txqueuelen 1000
> ip link set can0 txqueuelen 1000

You wrote, that this command do not change the socket quere, this command 
change the quere within the can adaptation. I hope, I understand this 
correctly.

Is there a dependency to a specific SocketCAN version? Especially I'm 
interested on embedded linux devices. Is the quere part of the common 
socketcan code or is it depend of the implementation?

-- 
Mit freundlichen Grüßen / Regards
Steffen Rose
www.emtas.de

Re: [Socketcan-users] increase buffer size

[Oliver Hartkopp]

On 24.01.2012 16:42, Steffen Rose wrote:

> Hello Oliver
> 
> Am Dienstag, 24. Januar 2012, 13:01:45 schrieb Oliver Hartkopp:
>> ifconfig can0 txqueuelen 1000
>> ip link set can0 txqueuelen 1000
> 
> You wrote, that this command do not change the socket quere, this command 
> change the quere within the can adaptation. I hope, I understand this 
> correctly.


You have an amount of rx/tx buffersizes inside each socket.

You may refer to the  '-r' option of the candump tool which can modify the
socket rx buffer size.

But there is currently no quota for the socket tx buffer size, as the CAN
frames are put directly into the CAN netdevice queue (which can by modified
with the commands 'ip' and 'ifconfig').

> Is there a dependency to a specific SocketCAN version? Especially I'm 
> interested on embedded linux devices.


No. SocketCAN is the official CAN networking stack of Linux.
I also run it on a MPC5200 based embedded device.

> Is the quere part of the common 
> socketcan code or is it depend of the implementation?


The queue implementation is part of Linux' general network stack on which
SocketCAN bases.

Regards,
Oliver

About PCAN-USB issues

[Stephane Grosjean]

Hello all,

I'm finally back to the linux-can... I'm currently working on several 
projects so the peak_usb did progress slowly these last days...

Back to the issue: I changed the way the can state is handled in the 
peak_usb driver and finally get an easy tesbed to create bus-off 
events... Now, the driver puts the candev into that state only once, no 
more periodic error-warnings or else. I'm looking now to how the restart 
mechanism works.

1st: since the restart can be automatic, the related do_set_mode 
callback is called from a timer context, in which you're not allowed to 
sleep. So I suppose this is the reason of some Kernel hangs you (Oliver) 
detected last week: the peak_usb driver (tries to) reset the device by 
sending an usb message, using usb_bulk_msg(), which usage is not allowed 
in such a context! To confirm, is someone able to do the same with the 
ems_usb driver, please? It seems that this driver acts as the peak_usb does.

Moreover, it seems that the "manual" restart is also called from such a 
timer context, so the consequences are the same...

I'll have to change the way that reset is done into full asynchronous mode.

Regards,

Stéphane

--
PEAK-System Technik GmbH, Otto-Roehm-Strasse 69, D-64293 Darmstadt 
Geschaeftsleitung: A.Gach/U.Wilhelm,St.Nr.:007/241/13586 FA Darmstadt 
HRB-9183 Darmstadt, Ust.IdNr.:DE 202220078, WEE-Reg.-Nr.: DE39305391 
Tel.+49 (0)6151-817320 / Fax:+49 (0)6151-817329, info@peak-system.com

Re: About PCAN-USB issues

[Wolfgang Grandegger]

Hi Stephane,

On 01/24/2012 06:12 PM, Stephane Grosjean wrote:
> Hello all,
> 
> I'm finally back to the linux-can... I'm currently working on several
> projects so the peak_usb did progress slowly these last days...
> 
> Back to the issue: I changed the way the can state is handled in the
> peak_usb driver and finally get an easy tesbed to create bus-off
> events... Now, the driver puts the candev into that state only once, no
> more periodic error-warnings or else. I'm looking now to how the restart
> mechanism works.
> 
> 1st: since the restart can be automatic, the related do_set_mode
> callback is called from a timer context, in which you're not allowed to
> sleep. So I suppose this is the reason of some Kernel hangs you (Oliver)
> detected last week: the peak_usb driver (tries to) reset the device by
> sending an usb message, using usb_bulk_msg(), which usage is not allowed
> in such a context! To confirm, is someone able to do the same with the
> ems_usb driver, please? It seems that this driver acts as the peak_usb
> does.

The timer handler is called from softirq context, which is not valid for
usb_bulk_msg().

> 
> Moreover, it seems that the "manual" restart is also called from such a
> timer context, so the consequences are the same...

Yes, it uses the timer as well, see:

  http://lxr.linux.no/#linux+v3.2.1/drivers/net/can/dev.c#L406

Otherwise it would be called from the process context, which causes
other problems.

> I'll have to change the way that reset is done into full asynchronous mode.

You will find some comments here:

  http://lxr.linux.no/#linux+v3.2.1/drivers/usb/core/message.c#L192

Wolfgang.

Re: About PCAN-USB issues

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]

On 01/24/2012 06:12 PM, Stephane Grosjean wrote:
> Hello all,
> 
> I'm finally back to the linux-can... I'm currently working on several
> projects so the peak_usb did progress slowly these last days...
> 
> Back to the issue: I changed the way the can state is handled in the
> peak_usb driver and finally get an easy tesbed to create bus-off
> events... Now, the driver puts the candev into that state only once, no
> more periodic error-warnings or else. I'm looking now to how the restart
> mechanism works.
> 
> 1st: since the restart can be automatic, the related do_set_mode
> callback is called from a timer context, in which you're not allowed to
> sleep. So I suppose this is the reason of some Kernel hangs you (Oliver)
> detected last week: the peak_usb driver (tries to) reset the device by
> sending an usb message, using usb_bulk_msg(), which usage is not allowed
> in such a context! To confirm, is someone able to do the same with the
> ems_usb driver, please? It seems that this driver acts as the peak_usb
> does.
> 
> Moreover, it seems that the "manual" restart is also called from such a
> timer context, so the consequences are the same...
> 
> I'll have to change the way that reset is done into full asynchronous mode.

Does it make sense to replace the timer by a workqueue and schedule it
by schedule_delayed_work(). On the downside a workqueue can only be
delayed in jiffies granularity.

Marc

-- 
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   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]