On Tue. 4 Mai 2021 at 01:26, Ayoub Kaanich <kayoub5@xxxxxxxx> wrote: > > Hi, > > > As Vincent pointed out, the device should not receive the CAN frame that > > has not been acked. > > We are not talking about traditional off-the-shelf devices. > The use case here is for specialized hardware in CAN logging, that dumps whatever happens in the network to a log file. > Example: https://technica-engineering.de/en/produkt/capture-module-can-combo/ I am not used to those devices. By "whatever happens in the network" do you mean that any cancelled transmission due to an error flag (including but not limited to ACK error flags) is logged? How do you plan to use the struct can{,fd}_frame to record those incomplete transmissions? For example, how do you plan to use Socket CAN API to log a frame cancelled due to a bit error in the middle of the data segment (i.e. sent a recessive bit but monitored dominant one)? > > Sure - Do struct can_fd_frames have a different ARP header type? > > I assume you mean “Pcap Linklayer” or “DLT”, and the answer is no. > can_fd_frames and can_frames share the same type, and they only keep enough bytes stored in the file to cover used data. > Unused data bytes are not store in the file to save disk space. > So there is no way in PCAP format, to tell them apart. This is my point. Here you took the *decision* to save disk space instead of blindly following the Socket CAN "philosophy" of using the MTU to differentiate between classical and FD frames. But you are treating the struct can{,fd}_frame as if it had a flexible array for the dada field which is not the case. So you are having this issue because you are using a modified version of the Socket CAN API to begin with. I am not saying this is a bad choice. I do like this approach :) Back to the Socket CAN API itself, one reason I would also like the kernel to use such an FDF flag is as follows: on other ethernet protocols, the developper does not need to allocate a message buffer of the size of the MTU. It is fine to only allocate a buffer able to contain the size of frames expected by the application. In Socket CAN, even if I have an application which only sends and receives FD frames with a data length of 8, I am still forced to use an additional 56 bytes because of this MTU design. This is the same as your PCAP issue: the current Socket CAN API does not allow you to save the bytes. I do not think this has currently a big overhead. But I am still curious to see the figures: does anyone know how much ressources are lost by memcpying those padding bytes? However, with the upcoming CAN XL (which will have an MTU of 2KiB), I think we will eventually need to use an approach in which the MTU and the type of the frames get decorelated (i.e. make the data array a flexible size array). > And even on the mcp251xfd, where I receive the CAN frame, there's no way > to tell if this frame has been acked or not. The mcp251xfd behavior is interesting. Do you also receive the ACK error flag? Does the controller retry to send the frame until it gets acknowledged? Are you still able to send frames and receive the echo if there is a single node on the network? Yours sincerely, Vincent
