All of lore.kernel.org
 help / color / mirror / Atom feed
* [Xenomai-help] gigabit rate packet processing with xenomai
@ 2006-03-28  8:09 emin ak
  2006-03-28 16:38 ` Jan Kiszka
  0 siblings, 1 reply; 4+ messages in thread
From: emin ak @ 2006-03-28  8:09 UTC (permalink / raw)
  To: xenomai

Dear All;
I'am new with xenomai (and also adeos), firstly I would like to thank 
who contributed to this project for this  high quality job. I have an
project that needs gigabit rate ethernet packet processing in user
space and need your recommendations.
I want to archive this with minimal kernel level device driver changes.
 According to my plan, I'll create a realtime user level thread and
this thread sleeps (with the mutex machanism in the native api) until
receiving a valid ethernet packet on ethernet interface that is
working regular linux domain. After receiving the packet, ethernet
driver releases the lock and sends packet to user level thread (with
shared memory or an other way).With this way, I have left the device
driver in linux domain, I'll only need to add locking and shared
memory system in the device driver.Does this system work? Does the
user level thread affect the functionallty of ethernet interface?Do I
need to implement all my user space thread and kernel level driver in
primaly domain?
Thanks again and B/regards.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Xenomai-help] gigabit rate packet processing with xenomai
  2006-03-28  8:09 [Xenomai-help] gigabit rate packet processing with xenomai emin ak
@ 2006-03-28 16:38 ` Jan Kiszka
  2006-03-30 15:24   ` emin ak
  0 siblings, 1 reply; 4+ messages in thread
From: Jan Kiszka @ 2006-03-28 16:38 UTC (permalink / raw)
  To: emin ak; +Cc: xenomai

[-- Attachment #1: Type: text/plain, Size: 1900 bytes --]

emin ak wrote:
> Dear All;
> I'am new with xenomai (and also adeos), firstly I would like to thank 
> who contributed to this project for this  high quality job. I have an
> project that needs gigabit rate ethernet packet processing in user
> space and need your recommendations.
> I want to archive this with minimal kernel level device driver changes.
>  According to my plan, I'll create a realtime user level thread and
> this thread sleeps (with the mutex machanism in the native api) until

In general, mutexes are not the right mechanism to wait on a specific
event, they are used to synchronise concurrent access to resources. What
you are likely looking for are e.g. semaphores.

> receiving a valid ethernet packet on ethernet interface that is
> working regular linux domain. After receiving the packet, ethernet
> driver releases the lock and sends packet to user level thread (with
> shared memory or an other way).With this way, I have left the device
> driver in linux domain, I'll only need to add locking and shared
> memory system in the device driver.Does this system work? Does the

Not very well (which means: not deterministically). You need to put the
driver under Xenomai control to achieve predictable latencies.

> user level thread affect the functionallty of ethernet interface?Do I
> need to implement all my user space thread and kernel level driver in
> primaly domain?

Yep, but you might be lucky: there is one Gigabit Ethernet driver
already available with RTnet (Realtek 8169). If you are only looking for
deterministic packet processing in an arbitrary network, you just have
to load the RTnet core and the rt_r8169 driver, and then you can
register your protocol types for sending and receiving (via rt-packet
sockets). There are also examples available with RTnet. Feel free to ask
for more details on the RTnet list.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Xenomai-help] gigabit rate packet processing with xenomai
  2006-03-28 16:38 ` Jan Kiszka
@ 2006-03-30 15:24   ` emin ak
  2006-03-30 21:01     ` Jan Kiszka
  0 siblings, 1 reply; 4+ messages in thread
From: emin ak @ 2006-03-30 15:24 UTC (permalink / raw)
  To: Jan Kiszka; +Cc: xenomai

Dear All;
Thanks for the answers firstly.
I'am using linux (and also xenomai ) for a powerpc (PQ3/MPC8540) and
will use on chip gigabit ethernet controller (tsec) that is not
supported on rt-net yet (maybe untill I'll write one:)
In my opinion and my basic tests shows that context switch times and
system call latecies in linux decrease user space performance
significally even with highest RT_FIFO priority and this reasons
prevent my gigabit rate data processing in user space.
I think I'll firstly choose un-deterministical way, write a realtime
user space thread that process the data coming from linux ethernet
driver, if it fails, I'll adapt the driver for rt-net or wait for the
up-coming realtime-preemptive patch.
Thanks again.


2006/3/28, Jan Kiszka <jan.kiszka@domain.hid>:
> emin ak wrote:
> > Dear All;
> > I'am new with xenomai (and also adeos), firstly I would like to thank
> > who contributed to this project for this  high quality job. I have an
> > project that needs gigabit rate ethernet packet processing in user
> > space and need your recommendations.
> > I want to archive this with minimal kernel level device driver changes.
> >  According to my plan, I'll create a realtime user level thread and
> > this thread sleeps (with the mutex machanism in the native api) until
>
> In general, mutexes are not the right mechanism to wait on a specific
> event, they are used to synchronise concurrent access to resources. What
> you are likely looking for are e.g. semaphores.
>
> > receiving a valid ethernet packet on ethernet interface that is
> > working regular linux domain. After receiving the packet, ethernet
> > driver releases the lock and sends packet to user level thread (with
> > shared memory or an other way).With this way, I have left the device
> > driver in linux domain, I'll only need to add locking and shared
> > memory system in the device driver.Does this system work? Does the
>
> Not very well (which means: not deterministically). You need to put the
> driver under Xenomai control to achieve predictable latencies.
>
> > user level thread affect the functionallty of ethernet interface?Do I
> > need to implement all my user space thread and kernel level driver in
> > primaly domain?
>
> Yep, but you might be lucky: there is one Gigabit Ethernet driver
> already available with RTnet (Realtek 8169). If you are only looking for
> deterministic packet processing in an arbitrary network, you just have
> to load the RTnet core and the rt_r8169 driver, and then you can
> register your protocol types for sending and receiving (via rt-packet
> sockets). There are also examples available with RTnet. Feel free to ask
> for more details on the RTnet list.
>
> Jan
>
>
>
>


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Xenomai-help] gigabit rate packet processing with xenomai
  2006-03-30 15:24   ` emin ak
@ 2006-03-30 21:01     ` Jan Kiszka
  0 siblings, 0 replies; 4+ messages in thread
From: Jan Kiszka @ 2006-03-30 21:01 UTC (permalink / raw)
  To: emin ak; +Cc: xenomai

[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]

emin ak wrote:
> Dear All;
> Thanks for the answers firstly.
> I'am using linux (and also xenomai ) for a powerpc (PQ3/MPC8540) and
> will use on chip gigabit ethernet controller (tsec) that is not
> supported on rt-net yet (maybe untill I'll write one:)
> In my opinion and my basic tests shows that context switch times and
> system call latecies in linux decrease user space performance
> significally even with highest RT_FIFO priority and this reasons
> prevent my gigabit rate data processing in user space.
> I think I'll firstly choose un-deterministical way, write a realtime
> user space thread that process the data coming from linux ethernet
> driver, if it fails, I'll adapt the driver for rt-net or wait for the
> up-coming realtime-preemptive patch.

If you can live with a certain amount of deadline misses, this is
probably the most reasonable approach. And preempt-rt will further
improve the quality of service but will still not be able to /guarantee/
networking latencies (the network stack is not explicitly included in
the latency improvements under preempt-rt, resource allocation remains
nondeterministic).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2006-03-30 21:01 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-03-28  8:09 [Xenomai-help] gigabit rate packet processing with xenomai emin ak
2006-03-28 16:38 ` Jan Kiszka
2006-03-30 15:24   ` emin ak
2006-03-30 21:01     ` Jan Kiszka

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.