[Xenomai] RTDM/RTNet - proposal to support sending/receiving multiple packets with one systemcall

Stéphane Ancelot sancelot at numalliance.com
Wed Dec 6 09:15:08 CET 2017


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 ?

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 at xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai




More information about the Xenomai mailing list