[Xenomai] Odp: RtNet and Interrupts

[Xenomai] Odp: RtNet and Interrupts

[Mariusz Janiak]

Dnia Piątek, 17 Lutego 2017 11:18 Norbert Lange <nolange79@gmail.com> napisał(a) 
> Hello,
> 
> I wonder if the Rtnet Stack is driven at packet level, ie. if after
> every one received packet( or even buffer) an IRQ is received.
> I worked on a Project where a similar Problem with Ethernet
> communication had to be solved, and I just queued up enough receive
> buffers and just picked up anything that arrived at the start of a
> timeslot.
> 
> On 100Mbit and a 1ms timeslot, I calculated a max. of 150 received
> pakets. Not that realtime communication can get anywhere close to
> that, but you have to deal with worst cases and guarantee that your
> system aint missing the cpu time spend in IRQs for other things - even
> if you just decide to drop all those packets, the IRQ overhead would
> be there.
> 
> So is Rtnet using "polling" at timeslots, or irqs?

Hi,

As far as I know, RTnet is interrupt driven stack, it means that after reception of each packet the interrupt is generated and handled by the NIC driver. This is one of the reasons why porting of the RT driver  to new NICs is so problematic, especially now when new drivers support NAPI.

> Kind Regards,
> Norbert
> 
> PS.
> Complete unrelated, but are there any big companies using Xenomai /
> Rtnet that can be named?

I know that Universities use it a lot in the field of robotics (eg. SOEM + OROCOS). There is a port of the RTnet stack for microcontrolers if you are interested (RTnet Embedded)

https://bitbucket.org/mariuszjaniak/rtnet-embedded

Best regards,
Mariusz



> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] RtNet and Interrupts

[Norbert Lange]

2017-02-17 11:45 GMT+01:00 Mariusz Janiak <mariuszjaniak@wp.pl>:
> Dnia Piątek, 17 Lutego 2017 11:18 Norbert Lange <nolange79@gmail.com> napisał(a)
>> Hello,
>>
>> I wonder if the Rtnet Stack is driven at packet level, ie. if after
>> every one received packet( or even buffer) an IRQ is received.
>> I worked on a Project where a similar Problem with Ethernet
>> communication had to be solved, and I just queued up enough receive
>> buffers and just picked up anything that arrived at the start of a
>> timeslot.
>>
>> On 100Mbit and a 1ms timeslot, I calculated a max. of 150 received
>> pakets. Not that realtime communication can get anywhere close to
>> that, but you have to deal with worst cases and guarantee that your
>> system aint missing the cpu time spend in IRQs for other things - even
>> if you just decide to drop all those packets, the IRQ overhead would
>> be there.
>>
>> So is Rtnet using "polling" at timeslots, or irqs?
>
> Hi,
>
> As far as I know, RTnet is interrupt driven stack, it means that after reception of each packet the interrupt is generated and handled by the NIC driver. This is one of the reasons why porting of the RT driver  to new NICs is so problematic, especially now when new drivers support NAPI.

Seems to be a bad Idea, I guess most RT communication is continuous,
means there is not a question whether packets arrived but only how
much of them.If I worked with irqs in the project above, the weak ARM
CPU wouldn`t be able to do anything else.
No efforts in using something similar to "New API"? (who comes up with
such names...)

>
>> Kind Regards,
>> Norbert
>>
>> PS.
>> Complete unrelated, but are there any big companies using Xenomai /
>> Rtnet that can be named?
>
> I know that Universities use it a lot in the field of robotics (eg. SOEM + OROCOS). There is a port of the RTnet stack for microcontrolers if you are interested (RTnet Embedded)
>
> https://bitbucket.org/mariuszjaniak/rtnet-embedded

Actually I am, sounds like you know about "RTnet Embedded" =).

The reason I ask is that I want to push this at the company I work,
unfortunately higher ups typically are most impressed if some rich
companies are using it (and claims that it is the most popular thing
ever).

>
> Best regards,
> Mariusz

Thanks, Norbert