Hi Marc,
I had an additional idea on this patch to prevent the unintentional
setting of 'zero' by common applications.
Will send a V2 patchset including all my (five) suggestions for can-next
later today.
Thanks,
Oliver
On 06.03.22 20:34, Oliver Hartkopp wrote:
The N_As value describes the time a CAN frame needs on the wire when
transmitted by the CAN controller. Even very short CAN FD frames need
arround 100 usecs (bitrate 1Mbit/s, data bitrate 8Mbit/s).
Having N_As to be zero (the former default) leads to 'no CAN frame
separation' when STmin is set to zero by the receiving node. This 'burst
mode' should not be enabled by default as it could potentially dump a high
number of CAN frames into the netdevice queue from the soft hrtimer context.
This does not affect the system stability but is just not nice and
cooperative.
With this N_As (frame_txtime) value the 'burst mode' is disabled by default.
For testing or (preformance) measurements the frame tx time can be set to
zero by setting the frame_txtime value in the CAN_ISOTP_OPTS sockopts.
Signed-off-by: Oliver Hartkopp <socketcan@xxxxxxxxxxxx>
---
include/uapi/linux/can/isotp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/can/isotp.h b/include/uapi/linux/can/isotp.h
index c55935b64ccc..3e6e20028969 100644
--- a/include/uapi/linux/can/isotp.h
+++ b/include/uapi/linux/can/isotp.h
@@ -140,11 +140,11 @@ struct can_isotp_ll_options {
/* default values */
#define CAN_ISOTP_DEFAULT_FLAGS 0
#define CAN_ISOTP_DEFAULT_EXT_ADDRESS 0x00
#define CAN_ISOTP_DEFAULT_PAD_CONTENT 0xCC /* prevent bit-stuffing */
-#define CAN_ISOTP_DEFAULT_FRAME_TXTIME 0
+#define CAN_ISOTP_DEFAULT_FRAME_TXTIME 50000 /* 50 micro seconds */
#define CAN_ISOTP_DEFAULT_RECV_BS 0
#define CAN_ISOTP_DEFAULT_RECV_STMIN 0x00
#define CAN_ISOTP_DEFAULT_RECV_WFTMAX 0
#define CAN_ISOTP_DEFAULT_LL_MTU CAN_MTU
