A special feature is the possibility to receive and send in parallel without holding the complete buffer.

This makes it possible to send and receive messages up to 4GB, even if the hardware doesn't have enough memory to hold it at once.

This reduces the costs of memory in the embedded hardware.
For large amount of data only, it reduces transfer time down to the transfer time of the component with slower speed. Especially the time delay for the switch is same for small and big messages.

This feature has some limits:

Only avaible when PDU_COP_CTRL_DATA::NumSendCycles == 1 only
The ComParam CP_RC21Handling != 0 (UDS-NRC == BRR (busyRepeatRequest) ) could not be supported in combination with the feature of unlimited buffer.
In this case the message is stored anyway.
Only avaible when D-PDU API Link is not in PDU_IOCTL_SUSPEND_TX_QUEUE mode.
Please have a look at transaction_save_flash.

Performance calculation:

In this testcase, using a VCAN, an amount of 100.000 bytes are transferred in ISOTP Address Mode Extended. In ISOTP means this 6 bytes netto per CAN-FRAME.
The total time was 223 ms.<br I tried to use sendmmsg to send a complete ISOTP block at once, but it was a little slower. Don't know what is going on inside Linux ? With real hardware it might be longer depending on the driver and hardware.

Description	Measurement
The average time between each CAN frame	~13usec
Transfer rate (including tcp/ip and ISOTP)	~450kb/sec

In the picture you can see the DoIP-GW, which transfers data from Ethernet to a VCAN interface using the ISOTP protocol.