RFC: Pacing support in vcan?

[David Jander <david@protonic.nl>]

Hi all,

I suspect this must have been brought up before, but I can't find discussion
about this topic... sorry if I missed that.

Currently the VCAN driver is infinitely fast, which is probably fine for most
simple applications and testing simple CAN code. Unfortunately I have had a
few cases where this is a problem. For example when testing software
implementations of transport protocols, where a producer generates can frames
basically as fast as possible. Two or more consumers receiving this stream are
just a little bit slower (in processing data) than the producer, so I would
start losing frames. Of course the TP takes care of this, but since that is
what I am trying to test/debug, this can be bothersome.

So the question is whether a proposal to introduce optional pacing of vcan
would be accepted?

Maybe something like (optional) virtual bitrate simulation?
I understand that other "loopback" interfaces, like "lo" don't have this and
don't want this, but in those cases we usually deal with TCP/IP anyway.
AFAICS, CAN is a little bit different in this aspect, as it is usually used
without a transport-protocol to take care of pacing, and software often assumes
that it runs fast enough to receive all frames at "wire-speed", so that
software can't deal with an infinitely fast interface.

I also understand that increasing RX-queue length can mitigate or solve these
problems most of the times, but that is of course no scalable solution.

Best regards,

-- 
David Jander
Protonic Holland.