> -----Original Message----- > From: Jan Kiszka <jan.kis...@siemens.com> > Sent: Mittwoch, 13. November 2019 18:39 > To: Lange Norbert <norbert.la...@andritz.com>; Xenomai > (xenomai@xenomai.org) <xenomai@xenomai.org> > Subject: Re: RTnet sendmmsg and ENOBUFS > > NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR > ATTACHMENTS. > > > On 13.11.19 16:10, Lange Norbert via Xenomai wrote: > > Hello, > > > > for one of our applications, we have (unfortunatly) a single ethernet > connection for Realtime and Nonrealtime. > > > > We solve this by sending timeslices with RT first, then filling up the > > remaining space. When stressing the limits (quite possibly beyond if > accounting for bugs), the sendmmsg call over a raw socket returns ENOBUFS > (even with a single small packet). > > I was expecting this call to just block until the resouces are available. > > Blocking would mean that the sites which make buffers available again had to > signal this. The original design idea was to avoid such overhead and rather > rely on the applications to schedule their submissions properly and > preallocate resources accordingly.
Ok. In other words, this is the same behaviour as using MSG_DONTWAIT (with a different errno value) > > > > > Timeslices are 1 ms, so that could be around 12Kbyte total or ~190 60Byte > packets (theoretical max). > > > > What variables are involved (whats the xenomai buffer limits, are they > shared or per interface) and choices do I have? > > > > - I could send the packages nonblocking and wait or drop the remaining > > myself > > - I could deal with ENOBUFS the same way as EAGAIN (is there any > > difference actually) > > - I could raise the amount of internal buffer somehow > > Check kernel/drivers/net/doc/README.pools > > > > > Also while stresstesting I get these messages: > > > > [ 5572.044934] hard_start_xmit returned 16 [ 5572.054989] > > hard_start_xmit returned 16 [ 5572.064007] hard_start_xmit returned 16 > > [ 5572.067893] hard_start_xmit returned 16 [ 5572.071739] > > hard_start_xmit returned 16 [ 5572.075586] hard_start_xmit returned 16 > > [ 5575.096116] hard_start_xmit returned 16 [ 5579.377038] > > hard_start_xmit returned 16 > > This likely comes from NETDEV_TX_BUSY signaled by the driver. Check the > one you use for reasons. May include "I don't have buffers left". Yes it does, I was afraid this would indicate some leaked buffers. Norbert ________________________________ This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. ANDRITZ HYDRO GmbH Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation Firmensitz/ Registered seat: Wien Firmenbuchgericht/ Court of registry: Handelsgericht Wien Firmenbuchnummer/ Company registration: FN 61833 g DVR: 0605077 UID-Nr.: ATU14756806 Thank You ________________________________
