> -----Original Message----- > From: Jan Kiszka <jan.kis...@siemens.com> > Sent: Freitag, 15. November 2019 14:36 > 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 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 socket pool once the data > >>>> was transferred to userspace. > >>> > >>> I suppose all pools can exchange rtskb, so this is just a matter of > >>> which pool > >> size is limiting. > >>> If I want to recvmmsg 100 messages, will I get at most 16 (socket > >>> pool size), or will a single slot be used and exchanged with the drivers? > >> > >> One packet, one rtskb. So you have both the device and the socket > >> pool as limiting factors. > > > > I guess this is different to the sendpath as the device "pushes up" > > the rtskb's, > > Actually, commit 91b3302284fd "aligned" TX to RX path. But the documents > still state something else. And I doubt now that this commit was going in the > right direction. > > In fact, it introduced a way for competing transmitters to starve each other > by exhausting the now shared device pool for TX. > > > And the recvmmsg call then picks up the packets that are available? > > (having some trouble following the path in the kernel sources) > > The point of the ownership transfer on RX is that, when receiving only with > one queue (RTnet can't handle more in fact, though it should by now...), we > first need to parse the packet content in order to dispatch it. That makes the > packet first owned by the device (formerly the RX pool), and once the actual > owner is known, it is transferred - or dropped if the recipient has no free > buffer.
Right, but if I open up a packetsocket with ETH_P_802_EX1, rt_stack_deliver will try to match the incoming packets, so somewhere the eth packet needs to be dissected, is that rt_eth_type_trans? means the valid values for a packet socket would be ETH_P_802_2, ETH_P_802_3, and the protocols >= 0x600 from 802.3. > > > > > We have some legacy application that ran on an imx28, and we have to > > keep the protocols for now, They are almost exclusively UDP/IP4 but > there's one message for distributing timestamps with a 802.2 SNAP packet. > > (had some technical/implementation reasons, cant remember now). > > Currently I use an ETH_P_ALL packet socket for that reason, but looking at > the code it seems beneficial to drop that. > > > > - there seems to be copies of rtskb made > > - the packets are not consumed, but kicked up further in the stack > > ETH_P_ALL is a kind of snooping mode, therefore the copies. You rather > want to register on the desired (non-IP) type(s). See above, seems the only usable types are ETH_P_802_2 and ETH_P_802_3? > > What I would want is a socket that simply drains everything, packets > > in use are ETH_P_IP, ETH_P_ARP and whatever is necessary to > send/receive those 802.2 SNAP packets. > > IP and ARP will be handled by RTnet, the other types is what you need > packet sockets for. I use neither IP or ARP from RtNet, and I don’t have the choice right now, Our timesync is via an external wire, and I gotta burst out everything at that point. This is no cleanroom design. Further, a tftp server is hooked into the RT connection via a TUN device, So packets not for the RT Application (udp port range) go to that device. > > I see ETH_P_802_EX1 used for such packets in examples, but I don’t see > how your stack identifies such packets? > > rt_packet_bind -> rtdev_add_pack. Dispatching is done in rt_stack_deliver, > in rt-kernel thread context. Yes, and I fail to see anything supported outside ETH_P_802_2 and ETH_P_802_3 and the protocols from 803. Nowhere will a eth packet be dissected and classified as ETH_P_802_EX1 or ETH_P_SNAP, What packets would end up in such a socket? > > - I don’t know which ETH_P type to use, theres ETH_P_802_2, > ETH_P_802_EX1, ETH_P_SNAP potentially others. > > - Those constants seems to be largely missing in xenomais sources, so I > don’t know how you would test for a match. > > You can register any value you like with AF_PACKET, just like in Linux. > Matching is not done by a switch-case, rather via a hashed list via the > values. That's for faster lookup, values are still compared afterwards. > > > - Easiest for me would be a ETH_P_ALL_CONSUME type, buffers just end > there when such a socket is open (feasible, would be accepted upstream?) > > I think you are better of with target subscriptions. Then all unknown packets > will simply be dropped, and that much earlier. Unknown packets need to be forwarded to the TUN device. (To put it another way, I had a deep direct queue to the network device before, and software/protocols grew around that) Regards, 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 ________________________________
