* Re: increase buffer size
[not found] <1567213.2GCzMlGyKY@lisa>
@ 2012-01-24 12:01 ` Oliver Hartkopp
2012-01-24 15:42 ` [Socketcan-users] " Steffen Rose
2012-01-24 17:12 ` About PCAN-USB issues Stephane Grosjean
0 siblings, 2 replies; 6+ messages in thread
From: Oliver Hartkopp @ 2012-01-24 12:01 UTC (permalink / raw)
To: Steffen Rose
Cc: socketcan-users-0fE9KPoRgkgATYTw5x5z8w, linux-can-u79uwXL29TY76Z2rM5mHXA
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Socketcan-users] increase buffer size
2012-01-24 12:01 ` increase buffer size Oliver Hartkopp
@ 2012-01-24 15:42 ` Steffen Rose
2012-01-24 16:17 ` Oliver Hartkopp
2012-01-24 17:12 ` About PCAN-USB issues Stephane Grosjean
1 sibling, 1 reply; 6+ messages in thread
From: Steffen Rose @ 2012-01-24 15:42 UTC (permalink / raw)
To: linux-can
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Socketcan-users] increase buffer size
2012-01-24 15:42 ` [Socketcan-users] " Steffen Rose
@ 2012-01-24 16:17 ` Oliver Hartkopp
0 siblings, 0 replies; 6+ messages in thread
From: Oliver Hartkopp @ 2012-01-24 16:17 UTC (permalink / raw)
To: Steffen Rose; +Cc: linux-can
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* About PCAN-USB issues
2012-01-24 12:01 ` increase buffer size Oliver Hartkopp
2012-01-24 15:42 ` [Socketcan-users] " Steffen Rose
@ 2012-01-24 17:12 ` Stephane Grosjean
2012-01-25 10:25 ` Wolfgang Grandegger
2012-01-31 17:58 ` Marc Kleine-Budde
1 sibling, 2 replies; 6+ messages in thread
From: Stephane Grosjean @ 2012-01-24 17:12 UTC (permalink / raw)
To: Oliver Hartkopp, Sebastian Haas, Wolfgang Grandegger; +Cc: linux-can
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: About PCAN-USB issues
2012-01-24 17:12 ` About PCAN-USB issues Stephane Grosjean
@ 2012-01-25 10:25 ` Wolfgang Grandegger
2012-01-31 17:58 ` Marc Kleine-Budde
1 sibling, 0 replies; 6+ messages in thread
From: Wolfgang Grandegger @ 2012-01-25 10:25 UTC (permalink / raw)
To: s.grosjean; +Cc: Oliver Hartkopp, Sebastian Haas, linux-can
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: About PCAN-USB issues
2012-01-24 17:12 ` About PCAN-USB issues Stephane Grosjean
2012-01-25 10:25 ` Wolfgang Grandegger
@ 2012-01-31 17:58 ` Marc Kleine-Budde
1 sibling, 0 replies; 6+ messages in thread
From: Marc Kleine-Budde @ 2012-01-31 17:58 UTC (permalink / raw)
To: s.grosjean
Cc: Oliver Hartkopp, Sebastian Haas, Wolfgang Grandegger, linux-can
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-01-31 17:58 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <1567213.2GCzMlGyKY@lisa>
2012-01-24 12:01 ` increase buffer size Oliver Hartkopp
2012-01-24 15:42 ` [Socketcan-users] " Steffen Rose
2012-01-24 16:17 ` Oliver Hartkopp
2012-01-24 17:12 ` About PCAN-USB issues Stephane Grosjean
2012-01-25 10:25 ` Wolfgang Grandegger
2012-01-31 17:58 ` Marc Kleine-Budde
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.