Re: [RTnet-developers] progress in real-time firewire project

[Jan K. <ki...@rt...>]

Zhang Yuchen wrote:
> Hi, 
> last week, I delved into the current firewire linux drivers, ie.,
> ohci1394+ieee1394. Then I realized the biggest non-real-time point here is
> the "task handover" between interrupt handler and the corresponding tasklet
> for the events, like a received packet.The handover is done in the way of
> "Bottomhalf", which is not considered to be real-time safe.  Both of the
> interrupt handler and the tasklets are defined and registered in ohci1394.
> The function hpsb_xxx, which is defined in ieee1394, for offering services
> to the various high-level applications, is invoked in the tasklets of
> ohci1394. There can be minimally 4 tasklets, respectively for 4 contexts: at
> (asynchronous transmission) request, at response, ar(asynchronous reception)
> request and ar response. When isochronous transaction is required, there
> will be more.  But the demuliplexing is done by hardware. In interrupt
> handler, the software reads the register of the hardware to get the context.

This sounds very interesting!

I think, for mapping Firewire on the Ethernet model (as a first step at 
least), only the asynchronous contexts are relevant. How do these 
request/response handshakes work? What is the difference to the xmit 
handlers of Ethernet drivers and their reception interrupt handlers? 
When I want to transmit a packet via Firewire, what steps has to be 
performed in software? On the other side, how much demultiplexing is 
done by the hardware on reception? MAC addresses, or also some higher 
layer addresses? How does the data path look like in that case?

In other words, what happens in-between:

at request  -
at response -    ?    - transmit payload to node X
ar request  -    ?    - receive payload from node Y
ar response -


Whenever you may find out some more details about the programming model 
of isochronous data, this would be interesting for future improvements.
Scenario A: Node 1 sends its sensor data regularly to Node 2-4.
Scenario B: All nodes exchanges their input data and output commands on 
a regular basis.
Scenario C: Application A on node 1 transmits its data every 10 ms to 
application B on node 2, application C on node 3 does the same to 
application D also on node 2.

Could those scenarios easily be mapped on isochronouse Firewire? On 
which abstraction level can the streams be multiplexed and demultiplexed?

> To change the bottomhalf handover, the stack manager mechanism seems to be
> usable.One option is to build a separate stack_manager for firewire, another
> is to arrange a new route for firewire in current stack_manager, which could
> be totally different from the other routes for ethernet. I would like to
> have your suggestions or questions for this.  

Cannot give you an advice yet as I do not fully understand the data 
paths. The job of the stack manager is to demultiplex the protocol type 
and forward the incoming packet to the respective protocol handler (IP, 
RTmac, user-defined protocols, ...). Do you have to do some work before 
this step for Firewire? Or what do you mean with different routes?

Generally, using two stack managers may be useful if you want to 
prioritise one over the other. Otherwise, having two tasks will likely 
only increase the overhead for handling incoming packets. A simple 
differentiation upon rtskb dequeuing which type of packet need special 
preparation (i.e. Firewire) should be more efficient. At some point, 
both the Ethernet and the Firewire path should become one again, at 
least for asynchronous traffic and in case there is no advanced 
high-layer hardware demultiplexing available.

> 
> Currently I lack the knowledge of rtai to understand the internal working of
> stack_manager. A simple questions is: when the "do_stacktask" of
> stack_manager is woke up and start running, will it be scheduled away from
> CPU, not because of the semaphore? Or will it be preempted by other
> real-time task? 
> 

The stack manager is by default running at the highest but one priority 
in the system (the TDMA output task has the highest one in a standard 
setup). Therefore, it is normally not interrupted. It's task is to find 
the recipient of a packet - either a user task, an internal service task 
(RTcfg), or some important handler running inside the stack manager's 
context (callback handlers, RTmac/TDMA, etc.). The stack manager is 
trigger by the signal of a driver which just placed a new packet inside 
the manager's queue. You may say, the stack manager is a heavy-weighted 
tasklet ;).

Jan