RE: RTnet sendmmsg and ENOBUFS

2019-11-15 Thread Lange Norbert via Xenomai
> -Original Message- > From: Jan Kiszka > Sent: Freitag, 15. November 2019 14:36 > To: Lange Norbert ; Xenomai > (xenomai@xenomai.org) > Subject: Re: RTnet sendmmsg and ENOBUFS > > NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR > ATTACHMENTS. >

Re: RTnet sendmmsg and ENOBUFS

2019-11-15 Thread Jan Kiszka via Xenomai
On 15.11.19 13:37, Lange Norbert wrote: I suppose the receive path works similarly. RX works by accepting a global-pool buffer (this is where incoming packets first end up in) filled with data in exchange to an empty rtskb from the socket pool. That filled rtskb is put into the

RE: RTnet sendmmsg and ENOBUFS

2019-11-15 Thread Lange Norbert via Xenomai
> > > > >> > >>> I suppose the receive path works similarly. > >>> > >> > >> RX works by accepting a global-pool buffer (this is where incoming packets > >> first end up in) filled with data in exchange to an empty rtskb from the > socket > >> pool. That filled rtskb is put into the socket pool

Re: RTnet sendmmsg and ENOBUFS

2019-11-15 Thread Jan Kiszka via Xenomai
On 15.11.19 11:10, Lange Norbert via Xenomai wrote: -Original Message- From: Jan Kiszka Sent: Donnerstag, 14. November 2019 19:18 To: Lange Norbert ; Xenomai (xenomai@xenomai.org) Cc: Philippe Gerum (r...@xenomai.org) Subject: Re: RTnet sendmmsg and ENOBUFS NON-ANDRITZ SOURCE

Re: RTnet sendmmsg and ENOBUFS

2019-11-14 Thread Jan Kiszka via Xenomai
On 14.11.19 19:18, Jan Kiszka wrote: On 14.11.19 18:55, Lange Norbert wrote: According to the code in __rtdm_fd_sendmmsg, that’s not what happens, ENOBUFS would be returned instead, And the amount of sent packets is lost forever. if (datagrams > 0 && (ret == 0 || ret == -EWOULDBLOCK)) { /*

Re: RTnet sendmmsg and ENOBUFS

2019-11-14 Thread Jan Kiszka via Xenomai
ia Xenomai Sent: Mittwoch, 13. November 2019 18:53 To: Jan Kiszka ; Xenomai (xenomai@xenomai.org) Subject: RE: RTnet sendmmsg and ENOBUFS NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR ATTACHMENTS. -Original Message- From: Jan Kiszka Sent: Mittwoch, 13. November 2019 18:39 To: Lan

RE: RTnet sendmmsg and ENOBUFS

2019-11-14 Thread Lange Norbert via Xenomai
e- > From: Xenomai On Behalf Of Lange > Norbert via Xenomai > Sent: Mittwoch, 13. November 2019 18:53 > To: Jan Kiszka ; Xenomai > (xenomai@xenomai.org) > Subject: RE: RTnet sendmmsg and ENOBUFS > > NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR > ATTACHMENTS. > &

RE: RTnet sendmmsg and ENOBUFS

2019-11-13 Thread Lange Norbert via Xenomai
> -Original Message- > From: Jan Kiszka > Sent: Mittwoch, 13. November 2019 18:39 > To: Lange Norbert ; Xenomai > (xenomai@xenomai.org) > Subject: Re: RTnet sendmmsg and ENOBUFS > > NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR > ATTACHMENTS. >

Re: RTnet sendmmsg and ENOBUFS

2019-11-13 Thread Jan Kiszka via Xenomai
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

RTnet sendmmsg and ENOBUFS

2019-11-13 Thread Lange Norbert via Xenomai
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