I try to answer part of your questions. > 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 firewire asyn. transaction, one request packet must specify the offset addr. in the destination node, while one response packet must contain the same tlabel (transaction label) as in its previous request packet. In the PHY layer of Firewire, which is implemented in hw, the received request and response packets are demultiplexed into different FIFOs:AR request FIFO, AR response FIFO. Further, the request packet is demultiplexed to different high-level applications based on its offset addr.( The high-level applications, like eth1394, should be registerred with a certain range of addr. beforehand.) The demultiplexing of response packet is done by finding the counterpart in the list of already-sent-request packets. If we only consider asyn. transaction, then we will have one of the 4 tasklets to wake up in the interrupt handler: dma_trm_tasklet for AT request and AT response; dma_rcv_tasklet for AR request and AR response. To my understanding, we can put all the 4 tasklets as 4 entries of one big real-time task, like stack manager, and use a sem. to trigger. Now, my question is: since the stack manager, once it has been woke up, will not be preempted until it reaches the communication end in the application, the later arrived events will be simply blocked, right? If this is true, then can I say it is another reason for using TDMA as media access control, since when one event arrives, no events will come in next one cycle? Ok, in Firewire, we also have the similiar situation, especially for asyn. See, in hw, the 4 DMA controllers (AR req. AR resp. AT req. AT resp) are running in parallel, so one event could be blocked when cpu is busy with another earlier event. Here we need a "event queue", not the rxqueue for packet in current stack manager. At least, this is what I have found in current Firewire linux drivers: the interrupt handler only reads the event register in hw and wakeup the event-related tasklet. The dma_rcv_tasklet will move the data from dma mapped area to another buffer, while the dma_trm_tasklet will pend the sent packet to a certain list for future ack (maybe). Concerned about this, I am a little confused about how to do firewire in current stack manager. It seems we have two options: one is to merge the dma_xxx_tasklet into interrupt handler, so we can move the packet out from dma mapped area and append it to a rxqueue, then it is the same as current stack manager. Another is we have to do some differentiation when the sem. is triggered, so the firewire event can be handled in a different way. I would like to have your suggestions or questions for this. Best regards, Yuchen -----Original Message----- From: Jan Kiszka [mailto:[EMAIL PROTECTED] Sent: 2004年11月15日 18:16 To: Zhang Yuchen Cc: rtnet-developers Subject: Re: [RTnet-developers] progress in real-time firewire project 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 ------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ RTnet-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/rtnet-developers
