Zhang Yuchen wrote: > 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?
The stack manager is not running at the frequency of TDMA, it has nothing directly to do with this. The manager is a worker task which simply goes through all jobs pending in its queue as long as it becomes empty. Then it will wait on further events from the drivers again. Events arriving while some previous is just being handled are defered until the current one is completed, that's independent of any TDMA 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. The question is how much time is spent in those tasklets. If it can be significant (some 10 us), then moving these jobs to a preemptible task is better. If there are just a few lines, e.g. like the xmit cleanup code in Ethernet drivers, then merging them into the interrupt context can be ok. But the linux developers may have had some reasons for pushing these jobs to tasklets... In case you will go the tasklet-to-stack-manager way, setting up a new stack manager could be wise in order to create a different kind of event queue (compared to the rtskb queue of the stack manager). 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
