On 2017-12-06 09:15, Stéphane Ancelot wrote: > Hi, > > I have done an application that does this thing. > > the application manages a stack of frames with priorities. high > priorities frame are sent at synchronised time (each ms, synchronised by > external clock) and then if there is enough remaining time, low priority > frames. (ethercat bus application) > > The job is not done in driver, but in realtime application process. > > I have 2 stacks => Input / ouput packets > > I managed to link this task with an internal software switch that > permits to embed ethernet packets in ethercat (EoE) > > From my viewpoint, I don't understand the added value doing this on > driver side ?
In general, it helps a lot in such discussions to have some basic benchmark numbers for the existing the new pattern at hand, even if the latter is just a proof-of-concept hack. Jan > > Regards, > > S.Ancelot > > > Le 05/12/2017 à 15:38, Lange Norbert a écrit : >> Hello, >> >> I would like to involve the RTDM Maintainers for discussing an >> addition to the RTDM drivermodel. >> This work would be done by Phillipe Gerum as part of a contract, he is >> also better suited to outline the necessary changes, >> should nothing stand against the proposal itself. >> >> - Problem description >> >> To be compatible with existing software, Ethernet packets will be >> polled at synchronized events. >> The application ideally would give the kernel/rtnet stack the >> responsibility and freedom to do this in an efficient manner, >> and be able to directly express the intend to poll all currently >> available packets. >> >> Similarly, but less time-critical thus important, sending multiple >> packets in a burst would be a requirement. >> >> Lastly Linux has this functionality in form of recvmmsg and sendmmsg, >> which would be a good fit in terms of existing interface, atleast if >> used in non-blocking mode. >> >> - Hypothetical Proposal >> >> Adding the necessary interfaces to RTDM and RTNet >> to allow non-blocking bulk receive/send, and offering functions not >> unlike the mentioned recvmmsg and sendmmsg. >> >> - Potential issues >> >> Copying of multiple packets would be done in RTDM context, potentially >> blocking resources for each packet or the whole duration. >> For our usecase it would for example not matter if the involved >> ethernet driver instance is not able to handle IRQs during this time, >> but it should not significantly affect worst-case task switch times in >> general, or block reception on other physical interfaces (Ethernet or >> otherwise). >> >> recvmmsg and timeouts (blocking) are likely to be problematic, but >> blocking mode is not required or wanted. >> >> - Open questions to the RTDM maintainers >> >> What would be the requirements of adding similar functionality to >> recvmmsg to RTNet / RTDM, >> and would there be any caveats that would prohibit addition from side >> of the RTDM maintainers? >> >> Other than that, a mmap based approach is also an option, but that's a >> somewhat more involved solution for both kernel and userspace as far >> as I understood. >> >> Kind regards >> >> Norbert Lange >> >> >> ##################################################################################### >> >> 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. >> Thank You. >> 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 >> ##################################################################################### >> >> >> >> _______________________________________________ >> Xenomai mailing list >> Xenomai@xenomai.org >> https://xenomai.org/mailman/listinfo/xenomai > _______________________________________________ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
