RFC: Pacing support in vcan?

RFC: Pacing support in vcan?

[David Jander]

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.

Re: RFC: Pacing support in vcan?

[Oliver Hartkopp]

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?

Regards,
Oliver

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

Re: RFC: Pacing support in vcan?

[David Jander]

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.