want blocking writes, but eventually get: errno 105 (No buffer space available)

want blocking writes, but eventually get: errno 105 (No buffer space available)

[ajneu]

Hi,

I'm trying to figure out how the blocking behaviour of socketcan works.

My test-program blocks (in write) in the beginning (the 1st few
program-runs), but then after a number of program-restarts I eventually get:
   errno 105 (No buffer space available)
which is not acceptable, since I want to block (in the write), and not get
any error!!

* What does the program do?
It does continuous blocking writes in a loop.
To get it to block, I'm have no other participants on the bus! (so I'm in
Error-Passive).


* My config:
  sudo ip link set can0 down
  sudo ip link set can0 txqueuelen 10
  sudo ip link set can0 up type can bitrate 250000


1st program run:
~> block on 33'rd write (32 frames queued)

2nd program run:
~> block on 7'th write (6 frames queued)

3rd program run:
~> block on 7'th write (6 frames queued)

4rd program run:
~> when trying 3'rd write: errno 105 (No buffer space available)
   (so 2 frames queued)

PLEASE: could sombody explain these numbers !
They don't make sense to me.


Details:
=========

I'm using PEAK USB Adapter (PCAN-USB FD) for normal CAN Frames (standard
format), and lsmod shows peak_usb as it should.

I'm using this setting:

// Write should block, when socketcan's own queue is full.
// To have this behaviour (and not get error ENOBUFS) set SO_SNDBUF to its
minimum value.
// See https://rtime.felk.cvut.cz/can/socketcan-qdisc-final.pdf#page=21
const int sndbuf = 0;
if (setsockopt(sock_fd, SOL_SOCKET, SO_SNDBUF, &sndbuf, sizeof(sndbuf)) < 0) {
 std::cerr << "Error setting SO_SNDBUF in setsockopt" <<
std::strerror(errno) << '\n';
 return -1;
}


Do I have to set txqueuelen to something else, in order to avoid getting
errno 105 (No buffer space available)?

Thanks.
ajneu

Re: want blocking writes, but eventually get: errno 105 (No buffer space available)

[ajneu]

ajneu <ajneu1 <at> gmail.com> writes:

>    errno 105 (No buffer space available)
This is ENOBUFS

ajneu <ajneu1 <at> gmail.com> writes:


> * My config:
>   sudo ip link set can0 down
>   sudo ip link set can0 txqueuelen 10
>   sudo ip link set can0 up type can bitrate 250000
> 
> 1st program run:
> ~> block on 33'rd write (32 frames queued)
> 
> 2nd program run:
> ~> block on 7'th write (6 frames queued)
> 
> 3rd program run:
> ~> block on 7'th write (6 frames queued)
> 
> 4rd program run:
> ~> when trying 3'rd write: errno 105 (No buffer space available)
>    (so 2 frames queued)
> 
> PLEASE: could sombody explain these numbers !
> They don't make sense to me.

Above if you sum the queued frames, I get: 32+6+6+2 = 46 queued


I've checked it for other values of txqueuelen:

sudo ip link set can0 down
sudo ip link set can0 txqueuelen 1
sudo ip link set can0 up type can bitrate 250000
~> queued: 32+5 == 37

sudo ip link set can0 down
sudo ip link set can0 txqueuelen 2
sudo ip link set can0 up type can bitrate 250000
~> queued: 32+6 == 38

sudo ip link set can0 down
sudo ip link set can0 txqueuelen 10
sudo ip link set can0 up type can bitrate 250000
~> queued: 32+6+6+2 == 46

sudo ip link set can0 down
sudo ip link set can0 txqueuelen 46
sudo ip link set can0 up type can bitrate 250000
~> queued: 32+6+6+6+6+6+6+6+6+2 == 82



So this is the general formula:

For txqueuelen == N, i.e.

sudo ip link set can0 down
sudo ip link set can0 txqueuelen N
sudo ip link set can0 up type can bitrate 250000
~> queued: N + 36


Please can someone explain this...
(And also how I can get guaranteed blocking behaviour. ;)  )

Thanks.
ajneu

Re: want blocking writes, but eventually get: errno 105 (No buffer space available)

[Oliver Hartkopp]

On 06/22/2016 05:00 PM, ajneu wrote:
> ajneu <ajneu1 <at> gmail.com> writes:
>
>>    errno 105 (No buffer space available)
> This is ENOBUFS
>
> ajneu <ajneu1 <at> gmail.com> writes:
>
>
>> * My config:
>>   sudo ip link set can0 down
>>   sudo ip link set can0 txqueuelen 10
>>   sudo ip link set can0 up type can bitrate 250000
>>
>> 1st program run:
>> ~> block on 33'rd write (32 frames queued)
>>
>> 2nd program run:
>> ~> block on 7'th write (6 frames queued)
>>
>> 3rd program run:
>> ~> block on 7'th write (6 frames queued)
>>
>> 4rd program run:
>> ~> when trying 3'rd write: errno 105 (No buffer space available)
>>    (so 2 frames queued)
>>
>> PLEASE: could sombody explain these numbers !
>> They don't make sense to me.
>
> Above if you sum the queued frames, I get: 32+6+6+2 = 46 queued
>
>
> I've checked it for other values of txqueuelen:
>
> sudo ip link set can0 down
> sudo ip link set can0 txqueuelen 1
> sudo ip link set can0 up type can bitrate 250000
> ~> queued: 32+5 == 37
>
> sudo ip link set can0 down
> sudo ip link set can0 txqueuelen 2
> sudo ip link set can0 up type can bitrate 250000
> ~> queued: 32+6 == 38
>
> sudo ip link set can0 down
> sudo ip link set can0 txqueuelen 10
> sudo ip link set can0 up type can bitrate 250000
> ~> queued: 32+6+6+2 == 46
>
> sudo ip link set can0 down
> sudo ip link set can0 txqueuelen 46
> sudo ip link set can0 up type can bitrate 250000
> ~> queued: 32+6+6+6+6+6+6+6+6+2 == 82
>
>
>
> So this is the general formula:
>
> For txqueuelen == N, i.e.
>
> sudo ip link set can0 down
> sudo ip link set can0 txqueuelen N
> sudo ip link set can0 up type can bitrate 250000
> ~> queued: N + 36
>
>
> Please can someone explain this...
> (And also how I can get guaranteed blocking behaviour. ;)  )

If you check proto_ops in Linux there are some sendmsg implementations 
that implement waiting for the queue to be able to take new messages.
Some others do not implement that waiting.

The question is whether blocking write (and probably write outdated 
content) is what you want for CAN.

Regards,
Oliver

Re: want blocking writes, but eventually get: errno 105 (No buffer space available)

[ajneu]

ajneu <ajneu1 <at> gmail.com> writes:

> My test-program blocks (in write) in the beginning (the 1st few
> program-runs), but then after a number of program-restarts I eventually get:
>    errno 105 (No buffer space available)
> which is not acceptable, since I want to block (in the write), and not get
> any error!!

One way that I can eliminate this problem (that I've discovered), is ...
if at the program-start I use libsocketcan to issue can_do_stop() followed
by can_do_start(). 

(Libsocketcan seems more and more important, the longer I think about it.)

Re: want blocking writes, but eventually get: errno 105 (No buffer space available)

[Tom Evans]

On 23/06/16 01:18, ajneu wrote:
> ajneu <ajneu1 <at> gmail.com> writes:
>
>> My test-program blocks (in write) in the beginning (the 1st few
>> program-runs), but then after a number of program-restarts I eventually get:
>>     errno 105 (No buffer space available)
>> which is not acceptable, since I want to block (in the write), and not get
>> any error!!

Very old news. CAN is implemented "sort of like IP-over-Ethernet, and so has 
inherited the buffering from that system. So there's a NETBUF queue. When that 
one overflows you get ENOBUFS. So you can change it with:

     setsockopt(pSkt->skt, SOL_SOCKET, SO_SNDBUF, &sndbuf, sizeof(sndbuf));

Other details here:

http://socket-can.996257.n3.nabble.com/Solving-ENOBUFS-returned-by-write-td2886.html

Search for ENOBUFS in this as well:

http://rtime.felk.cvut.cz/can/socketcan-qdisc-final.pdf

 > 1st program run:
 > ~> block on 33'rd write (32 frames queued)

You'll have the Network queue, the "tx_queue_len" in the driver, as well as 
however many physical message buffers there are in your hardware, which looks 
to be "32".

Tom