socket send fail,txlen=2,send len=-1,errno=(105)No buffer space available

错误

write: No buffer space available
write(s, &frame, sizeof(struct can_frame)) 的输出结果为-1；

原因

由于缓冲队列空间不足;

临时办法

echo 1000 > /sys/class/net/can0/tx_queue_len

root@super:/sys/class/net/can1# cat tx_queue_len 10

root@super:/sys/class/net/can1# echo 1000 > tx_queue_len

root@super:/sys/class/net/can1# cat tx_queue_len 1000

最终办法

虚拟机需要接ECU或者应用软件

read/write的语义：为什么会阻塞？

先从write说起：

ssize_t write(int fd, const void *buf, size_t count);

首先，write成功返回，只是buf中的数据被复制到了kernel中的TCP发送缓冲区。至于数据什么时候被发往网络，什么时候被对方主机接收，什么时候被对方进程读取，系统调用层面不会给予任何保证和通知。

write在什么情况下会阻塞？当kernel的该socket的发送缓冲区已满时。对于每个socket，拥有自己的send buffer和receive buffer。从Linux 2.6开始，两个缓冲区大小都由系统来自动调节（autotuning），但一般在default和max之间浮动

已经发送到网络的数据依然需要暂存在send buffer中，只有收到对方的ack后，kernel才从buffer中清除这一部分数据，为后续发送数据腾出空间。接收端将收到的数据暂存在receive buffer中，自动进行确认。但如果socket所在的进程不及时将数据从receive buffer中取出，最终导致receive buffer填满，由于TCP的滑动窗口和拥塞控制，接收端会阻止发送端向其发送数据。这些控制皆发生在TCP/IP栈中，对应用程序是透明的，应用程序继续发送数据，最终导致send buffer填满，write调用阻塞。

一般来说，由于接收端进程从socket读数据的速度跟不上发送端进程向socket写数据的速度，最终导致发送端write调用阻塞。

而read调用的行为相对容易理解，从socket的receive buffer中拷贝数据到应用程序的buffer中。read调用阻塞，通常是发送端的数据没有到达。