On Thu. 8 Aug. 2024 at 15:18, Matthias Unterrainer <matthias.unterrainer@xxxxxxxxxxxxxxxxxxxx> wrote: > On 07-08-2024 12:25, Vincent Mailhol wrote: > > On Sat. 27 Jul. 2024 at 12:17, Matthias Unterrainer > > <matthias.unterrainer@xxxxxxxxxxxxxxxxxxxx> wrote: > >> Hi Vincent, > >> > >> apologies for the late reply. > > > > No problem. I am myself abroad until the end of August. My answers > > will also be delayed. > > > >> On 07-07-2024 17:23, Vincent Mailhol wrote: > >>> Hi Matthias, > >>> > >>> On Fri. 5 Jul. 2024 at 02:47, Matthias Unterrainer > >>> <matthias.unterrainer@xxxxxxxxxxxxxxxxxxxx> wrote: > >>>> Hi Linux-CAN Community, > >>>> > >>>> my name is Matthias and I recently developed a kernel module during my Bachelor's thesis that allows for transferring CAN frames over IP networks, similar to userland tools like socketcand [0] or cannelloni [1]. > >>>> > >>>> I wrote the thesis at dissecto GmbH [2], a german Startup that specializes in security diagnostics and analytics for embedded systems, primarily within the automotive industry. > >>>> > >>>> The idea behind the project is that dissecto has developed a hardware device that can be connected to a CAN bus and acts as an ethernet gateway to the bus. It is capable of capturing the CAN traffic along with the corresponding timestamps and send this data via UDP or it can receive CAN frames via UDP as well and pass them on to the CAN bus. > >>>> This allows for remote interaction with a CAN bus, as well as an accurate analyses of CAN traffic, as packets contain precise time stamps. > >>>> > >>>> An architectural design decision was to develop it as kernel module because of lower latencies and high throughput. > >>> > >>> Question: did you consider Packet MMAP? > >>> > >>> https://docs.kernel.org/networking/packet_mmap.html > >>> > >>> Most of the overhead comes from the syscall context switch between the > >>> user and kernel land and Packet MMAP is exactly designed to bypass > >>> this. Actually, a few months ago, I started to rewrite the can-utils's > >>> candump to use Packet MMAP, but I never finished it. > >> > >> No, at the time I did not consider Packet MMAP. From my understanding > >> Packet MMAP is used for userspace applications. But the module has to > >> modify the timestamps of the CAN frames as they appear on the interface, > >> which, as far as I know, is not possible from userspace. > >> Please correct me if I am mistaken, but because of that I do not think > >> Packet MMAP or any userspace application for that matter could actually > >> be used here. > > > > Can you explain this in more detail? The precise CAN timestamps are > > all available from the user land. Some drivers even have the hardware > > timestamps as generated by the device. Why do you need to *modify* the > > timestamps? > > > > I have to modify the timestamps, because I want the CAN-frames to have > the timestamps they had when they originally appeared on the "source" > device, which is not the same device I am modifying the timestamps on. > > An example setup for this would be, that we have two devices and one of > them, the "source" device, has a CAN-Bus we want to capture the traffic > from. > On that device we record the CAN-frames together with their timestamps. > Then all of this is sent to the second device and recreated there. > Meaning all the CAN-frames appear with the timestamps from when they > originally appeared on the "source" device. > > I hope this makes it a bit clearer what I am trying to accomplish. I think I now understand. Overall, what you are building is a CAN tunnel over UDP. I looked at the other similar tunneling devices, for example drivers/net/tun.c, but I can not find a precedent of a tunneling device which would overwrite the timestamp with a remote value. As far as I can see, the logic is that the timestamp represents the moment the packet reaches the *device* (or the device driver in case of software timestamps). The same logic applies to tunnel devices. Usually, if you want the timestamps from a remote device, you would capture the traffic (e.g. in a .pcap file) and get all the timestamps for that. I am not sure what your ultimate goal is. If you just want to let the community know about your work, then it is ok as-is. Overall, this is a nice student project. If you want your work to be merged upstream, I think the architecture should be adjusted to come with something more generice: a CAN tunnel device capable of taking remote timestamps as an input. If such a remote timestamp is added, maybe a new timestamp type would be needed? Something like: SOF_TIMESTAMPING_RX_REMOTE or SOF_TIMESTAMPING_RX_ORIGINE (c.f. https://www.kernel.org/doc/html/latest/networking/timestamping.html)? This way the user can choose between the timestamp from the tunnel device or from the remove device. But as I said, I could find no precedent even outside of the CAN subsystem. So expect to see a lot of push back. You will probably have to convince a lot of people of the need for this "remote timestamp". If you want to proceed further with this work, I suggest you first ask the net-dev mailing list opinion on whether such remote timestamping makes sense to them. > >>>> For example, my measurements show that the average time it takes a CAN frame to get processed by the module is just about 1/4 of the time it takes applications like socketcand or cannelloni. > >>>> > >>>> We have published the module on GitHub [3], and would appreciate your feedback and thoughts. > >>>> > >>>> If anyone is interested in this functionality for the same or similar use cases, please don't hesitate to contact us. > >>>> > >>>> Best regards > >>>> Matthias Unterrainer
