Messages in this thread | | | Date | Wed, 01 Sep 2010 19:04:04 +0200 | From | Oliver Hartkopp <> | 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
| |