On Wed, Mar 10, 2010 at 04:22:30PM +0100, Matthias Fuchs wrote: > Hi, > > I played a little with various ways to manipulate tx/rxqueuesizes with > SocketCAN. > I ended up with some questions: > > 1) Does setsockopt(... ,SOL_SOCKET, SO_SNDBUF, ....) have any impact on > CAN_RAW sockets? > My result: no! I _think_ that SO_SNDBUF sets the tx queue of the socket, not the net_device. CAN_RAW sockets however do queue directly into the net_device. So, I think a more precise answer would be "yes, but you never use it". > > 2) Does setsockopt(... ,SOL_SOCKET, SO_RCVBUF, ....) have any impact on > CAN_RAW sockets? > Yes, that's also used by candump to prevent losing rx frames. > > 1+2 brings me to the conclusion that setsockopt(..., SO_RCVBUF, ...) > configures receive > behavior and "ip link set can0 txqueuelen <whatever>" configures tx behavior. > Did I miss > anything? > > 3) Do we have a way to make write() on CAN_RAW sockets block when there is > no more buffer space? Typical behavior is returning ENOBUFS. I haven't tried > to > use select() for sending. Does this work? poll() and select() would not work, since ENOBUFS comes from the net_device. I have struggled with the ENOBUFS too. Try to look at it this way: poll()/select() only work well if you know you're the _only_ user using the file (reason: if more users use the same fd, user A can write between B's calls to poll() & write()).
You can be the only user of the socket, but not the only user of the net_device. This does in no way address you question. I just try to explain some phenomena that took some time for me to understand properly. > > 4) Do we have a way to flush the txqueue and block until all messages are on > the bus? > fsync() does not seem to be the right choice. You mean: flush the socket's queue, not the netdev's queue (the latter is shared)? > > 5) Is there any special reason why read/write can only handle single messages? > Is it just because nobody asked? It should be possible with our > fixed size stuct can_frame. It could even speed thing up. > > Matthias Each single point you raise is IMO an issue that can be improved. (maybe 3. is really difficult to provide system-wide). This would imply a serious modification in CAN_RAW: * use socket's own queueing when net_device ENOBUFS * hrtimer() based wakeup to retry flush the socket's queue * trigger waitqueue when own message is received. * big thing: on bus-off, everything must be dropped, errors sent, ... Right? Kurt _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
