Message-ID: <4C7E8784.9060509@hartkopp.net>
Date:	Wed, 01 Sep 2010 19:04:04 +0200
From:	Oliver Hartkopp <socketcan@...tkopp.net>
To:	Masayuki Ohtake <masa-korg@....okisemi.com>
CC:	Wolfgang Grandegger <wg@...ndegger.com>,
	"Wang, Yong Y" <yong.y.wang@...el.com>, arjan@...ux.intel.com,
	gregkh@...e.de, Qi <qi.wang@...el.com>,
	Andrew Chih Howe <andrew.chih.howe.khor@...el.com>,
	ML linux-kernel <linux-kernel@...r.kernel.org>,
	ML netdev <netdev@...r.kernel.org>,
	socketcan-core@...ts.berlios.de,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Barry Song <21cnbao@...il.com>,
	Christian Pellegrin <chripell@...e.org>,
	Wolfram Sang <w.sang@...gutronix.de>,
	"David S. Miller" <davem@...emloft.net>
Subject: out-of-order tx objects - was Re: [MeeGo-Dev][PATCH] Topcliff: Update
 PCH_CAN driver to 2.6.35

Hello Ohtake,

i'm only picking up the out-of-order issue here ...

On 01.09.2010 09:45, Masayuki Ohtake wrote:

>>>>> - I see that the driver uses many TX and RX objects. How do you avoid
>>>>>   out-of-order transmission and reception?
>>>> What do you mean out-of-order RX and TX?
>>>> Atom processor only supports in-order execution, and PCIe-based peripherals
>>> can solve it with consumer-producer model. Actually IC designer will take care
>>> of out-of-order PCIe CPLD transaction.
>>>
>>> I mean out-of-order transmission to or from the CAN bus. This is handled
>>> by the CAN controller hardware. It has nothing to to with the processor.
> Cannot avoid occurring rx or tx our-of-order.

The CAN frames that are sent by the local system have to touch the wire in the
same order as you put them into the socket as user.

An example:

You send CAN-frames with CAN Identifiers via can-raw sockets

0x123
0x456
0x010

and of course you expect these frames sent in exactly this order.
This is easy to archive as you get each of these CAN frames out of the
netdevices tx-queue in this order.

The problems comes up when you use multiple "tx objects" of your CAN
controller. Some CAN controllers have a "magic intelligence" that leads to
some re-ordering according to the CAN-Identifiers priority.

E.g.

0x123
0x456
0x010

leads to

0x123
0x010
0x456

because you pushed these CAN-frames into different tx objects and the CAN
controller sorts them on its own by priority. For CAN newbies: A lower CAN-ID
value has a higher priority in arbitration on the *physical* layer.

In the example above the CAN controller checks after sending the 0x123 CAN
frame if there's a priority order in the tx objects that are ready to send,
and selects 0x010 ...

This behaviour might be interesting in single-user/single-application
environments - but it is just wrong in multi-user systems where several
different applications use the (same) CAN bus. Standard networking behaviour.

Please ensure that the CAN frame order given by the tx-queue of the Linux
kernel netdevice infrastructure is send on the wire in the same order.

This usually leads to the use of ONLY ONE tx object of your CAN controller.
Probably you can use two tx objects to increase the throughput if this does
not have any impact to the frame order. See your controllers documentation for
details about this tx object behaviour.

I hope this makes the question of Wolfgang a bit clearer :-)

Regards,
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists