Re: [Xenomai] packet_mmap raw socket usable from Xenomai?

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 02/01/2014 06:58 PM, Michael Haberler wrote:
> I am looking into ethernet I/O from a RT thread, but am willing to
> tradeoff some latency against using stock linux drivers

The tradeoff is not about latency. It is about determinism. You can not
expected bounded latencies when in secondary mode and without preempt_rt.

> 
> also I'd like to use a common method across RT-PREEMPT and Xenomai
> thread styles to keep the number of moving parts low
> 
> One method which looks promising is the PACKET_TX_RING/PACKET_RX_RING
> methods of the packet_mmap raw sockets; it seems packet read is
> possible with only shared memory r/w and a transmit entails a
> sendto() socket call passing a reference to the packet in the
> transmit ring (so skbufs arent used except in the driver per se) - I
> do assume though that sendto() will cause a domain switch even if it
> is just a notification to the driver
> 
> am I blundering down a dead end? Is RTnet my only option even if I
> dont need the IP and above stack, and the low latency RTnet
> provides?

RTnet will allow you to use send/recv service without leaving primary
mode, any other method based on Linux system calls will cause a thread
to switch to secondary mode, and loose determinism.

> 
> if not - is it conceivable to handle this sendto() driver
> notification via an RTDM driver? I dont need RX notification because
> the shm test is cheap and threads are cyclic anyway

I do not think RTnet implement packets mapped in user-space. That said,
user-space mapped packets are useful for a high throughput, if you only
care about having bounded latencies, packets copied from user-space to
kernel-space do just fine (they have a higher latency due to the copy,
but the latency remains bounded).

Regards.

-- 
                                                                Gilles.