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@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
