Re: [RTnet-developers] rtnet w. interrupts disabled

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

Tom Schouten wrote:
> On Mon, Jan 19, 2009 at 09:27:58AM +0100, Jan Kiszka wrote:
>> Tom Schouten wrote:
>>> Hello,
>>>
>>> Is it planned to have rtnet operate without network device interrupts?
>> Not yet.
>>
>>> I.e. a non-blocking recv() call would query the card directly without 
>>> buffering, leaving all read timing up to the application.
>> Note that this gets "tricky" if there is additional protocol handling
>> required (like ARP, ICMP, UDP, RTmac, TDMA etc.) or if more than one
>> thread is receiving data at the same time. The model only works
>> straightforward if you do plain Ethernet access with users that all
>> expect the polling mode.
>>
> 
> Yes.  We would use it only for exclusive raw ethernet access with a 
> dedicated segment and completely predictable traffic.
> 
>>> If not planned, maybe you have some advice on how to implement this?
>>> I'm currently looking into modifying the eepro100 driver, but maybe
>>> there is a more highlevel way?
>> A definitely needs a high level handling as well because you always go
>> through the stack to access a driver. As a first step, you may want to
>> study Linux' NAPI interface and check what might be applicable to RTnet.
>> Then I would suggest posting your ideas about an extended driver
>> interface here so that we can discuss how to integrate it best into the
>> stack.
>>
> 
> Thanks for the hints.
> 
>> Out of curiosity: What is your scenario, your cycle frequency so that
>> you may need polling?
>>
> 
> We're at 8 kHz now with multiple packets per clock, but would like to get 
> as high as the hardware allows.  Since we know when the packets arrive, an 
> interrupt doesn't add anything useful.  It reduces determinism and even 
> causess trouble in some hardware configurations (interrupt arrives before 
> pci bus transfer is ready, leading to delayed packets.)

Yep, I see.

> 
> I was wondering if it makes sense to split RTnet into stack + HAL, or to add 
> some kind of hook that allows the stack to be bypassed, or adds a 
> plugin inbetween stack and HAL.
> 
> Instead of adding the suggested interrupt-less feature to the highlevel 
> code, it could be part of the raw packet HAL which we would then use 
> directly.

First of all, the stack is already fairly modular. You don't need to
load IP support, you don't need to insmod RTmac etc. Then, unless you
want to start hacking your application inside kernel space (generally
not recommended, e.g. when you need a non-GPL license), you still need
some user interface. And that's one feature the stack core provides.
Another is the management, of the device state and of buffer pools. So
there is not much to gain by cutting everything away above the driver,
but quite some stuff to be re-invented.

Jan