Re: socket can receive order

[Daniel Squires <dan@engineeredarts.co.uk>]

On 08/09/15 12:13, Marc Kleine-Budde wrote:
> On 09/08/2015 12:41 PM, Daniel Squires wrote:
>> On my laptop and Desktop PC I have not seen it happen.
>> Both the application PC (NUC) and the Laptop are running Ubuntu kernel
>> 3.19.0-26-generic
>>
>> The NUC has the kernel rebuilt without xhci due to problems it causes
>> with another USB peripheral.
>>
>> I am not entirely sure what you mean by which can core I am using but if
>> it helps i am opening the socket as follows :
> I mean what kind of CAN adapter...
>
>>       sock = socket(PF_CAN,SOCK_RAW,CAN_RAW);
>>
>> in a small standalone test application which I wrote after having
>> difficulty with our main application.
>>
>> I am using custom hardware/firmware and am using the kernel module found
>> here : https://github.com/fabiobaltieri/open-usb-can
>> though it has a small change to stop the net queue at the top of
>> open_usb_can_start_xmit as otherwise its prone to loosing TX packets
>> when loaded.
> Yes, this looks racy - You should ask then to mainline working the driver.
>
>> I can see the packets coming in the correct order in wireshark and it is
>> not immediately obvious to me how the kernel module could mix up the
>> order, so it seems that it must be something that happens at the socket
>> level?
> The kernel module "produces" the CAN frames, so if you see them in the
> correct order in wireshark, they have left the module in the right order.

Sorry , I should have been clearer here, in wireshark was looking at the 
USB frames not the CAN frames. however I think what you say still stands 
due to the time stamps being in the correct order.
>
>> candump can3 -tz
>> <snip>
>>    (003.088648)  can3  043   [8]  F7 2D 00 00 00 00 00 00
>>    (003.089149)  can3  045   [8]  F9 2D 00 00 00 00 00 00
>>    (003.088897)  can3  044   [8]  F8 2D 00 00 00 00 00 00
> The timestamps are in the correct order. Maybe Oliver can help here,
> he's an expert when it comes to strange reordering :)
>
>> On the top level I am using CANFestival for CANOpen implementation, so
>> it has occurred to me I could implement a CANFestival "driver" using
>> libusb and completely bypass the kernel module and socket can layers,
>> but I hope not to have to do this.
> Na, you don't want to do this.
>
> Marc

-- 
Dan Squires

Engineered Arts Ltd.