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

Lange Norbert norbert.lange at andritz.com
Wed Dec 6 09:53:17 CET 2017


>-----Original Message-----
 >From: Stéphane Ancelot [mailto:sancelot at numalliance.com]
 >Sent: Mittwoch, 06. Dezember 2017 09:15
 >To: Lange Norbert; Xenomai (xenomai at xenomai.org)
 >Cc: jan.kiszka at siemens.com
 >Subject: Re: [Xenomai] RTDM/RTNet - proposal to support sending/receiving
 >multiple packets with one systemcall
 >
 >EMAIL from a NON-ANDRITZ SOURCE: as a security measure, please exercise
 >caution with email content and any links or attachments.
 >
 >
 >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

Hello,

Looking at the priorities, the system is roughly:
[irqs]
[rtnet/rtdm]
[rt-application]

We have a couple GBit ethernet connections which each could receive 1500 Packets per ms (worst case). Any attempt to restrict the impact of a loaded connection (whether on purpose or in error) would have to be done at the driver side.
So disabling irqs on packet reception and being able to pull out available ones would need to be done on the driver level.

Our previous software (on a RT "Taskscheduler") did this by priming only a fixed amount of DMA receive buffers, which means there was a *bounded* amount of data to inspect, a *bounded* number of IRQS (0) and a *bounded* number of system calls,
with excess data dropped as early as possible - by the hardware, instead being passed down and rejected later.

Thus we could easily guarantee latencies and available CPU time for the RT applications, which is the primary point here (better performance is an advantage too): making everything more predictable.

Probably should explain that there is work do be done in the RTNet side, which is not the issue here. There is however work needed for RTDM to even *allow* modifying the behavior, and the basic question is: how and what could/should be done so upstreaming is easily doable.

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.
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
#####################################################################################



More information about the Xenomai mailing list