Re: [RTnet-developers] Running an RTNET node over a non-rt network.

[Jan K. <jan...@we...>]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > Hi Gilles,
>  >=20
>  > Gilles Chanteperdrix wrote:
>  > > Hi,
>  > >=20
>  > > I am asked to run a real-time networking application on a non real=
-time
>  > > network, so, I naturally thought about using RTnet.
>  > >=20
>  > > But unless I am completely mistaken, it is not what RTnet is origi=
nally
>  > > made for. As far as I understood, in an RTnet network, the non rea=
l-time
>  > > trafic is tunneled through the real-time traffic by adding an rtma=
c
>  > > header with the RTMAC_FLAG_TUNNEL flag set. But since the other no=
des on
>  > > the network I am on are non-rt, they do not understand the rtmac h=
eader.
>  >=20
>  > Before I misunderstand your patch: you run RTmac/TDMA on a non-RT
>  > network and you then need to use the tunnel (also) between RT and no=
n-RT
>  > nodes? Have you considered the rtnetproxy as platform for your solut=
ion
>  > as well? Or do you see your approach as a potential replacement for =
the
>  > proxy?
>=20
> My aim is to run an RTnet node on a non real-time network, in order for=

> real-time applications to avoid loosing determinism when they transmit
> or receive packets over network. But I would like the rest of the syste=
m

Keep in mind: Concurrent access of RT and non-RT to the same NIC for
transmitting data may require some tweaking to manage non-RT traffic
bursts. Even more problematic: receiving non-RT traffic over an RT-NIC
can easily toast your systems determinism (message dispatching...). You
will have to enforce some kind of traffic shaping towards the RTnet node
as well.

> to continue working as if RTnet was not there. I have tried rtnetproxy,=

> but with rtnetproxy, arp requests/replies do not work, so that my non
> real-time applications do not work.

I guess ARP forwarding was not yet a use case for rtnetproxy. One could
solve this by injecting incoming ARP replies into the Linux stack as
well. Another open issue is forwarding UDP packets to non-RTnet ports.

>=20
> So far, I have only tried to get the non real-time stuff working, so I
> am using the NOMAC discipline, and I suspect the patch I sent does not

Hmm, NoMAC is for demo purpose, not originally developed to solve real
problems. BTW, how do you want to demux incoming packets if you kill the
RTmac header?

> work with anything else. I even suspect that it does not work at all,
> since I am getting kernel bugs, and am not sure whether they are due to=

> this patch, or to my real-time ethernet driver implementation.
>=20
> Anyway, I am open to any better solution.
>=20

I really recommend going the rtnetproxy path, adding the missing
features to that module and/or establishing more hooks in the stack.

Jan