Re: RFC: Pacing support in vcan?

[David Jander <david@protonic.nl>]

On Mon, 1 May 2017 12:04:05 +0200
Oliver Hartkopp <socketcan@hartkopp.net> wrote:

> Hi David,
> 
> On 05/01/2017 09:24 AM, David Jander wrote:
> 
> > 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?  
> 
> you can already add a queueing discipline to the virtual CAN interface.
> 
> See
> 
> http://rtime.felk.cvut.cz/can/socketcan-qdisc-final.pdf
> 
> chapter 3.3.
> 
> Does this help in your setup?

Ha! Yes, this is indeed what I was looking for.... somehow I didn't expect it
to be possible with queuing disciplines. Shows that I still have far too
little experience with that corner of the Linux networking stack :-)
Thanks!

> > 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,
> >  

Best regards,

-- 
David Jander
Protonic Holland.