Hi Kurt, On Thursday 11 March 2010 17:46, Kurt Van Dijck wrote: > 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". When going through this thread, I think you are right and things become clearer. > > > > 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()). This really makes poll/select unusable. I really like the idea (of the esd CAN driver) that multiple applications can use/share one CAN interface without really interfering. Up to now I was not really aware of SocketCAN's shared txqueue. > > 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)? Well, since SocketCAN does not use the socket's queue for sending i mean the latter. But with a shared queue it could take forever when an other process keeps it filled.
> > > > 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 For now I am already glad to have to current implementation "documented". The current implementation is simple and keeps some ballast out of SocketCAN. > 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 This would be cool and will allow using poll/select with expected behavior. > * 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? Matthias _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
