First, thanks for your reply :) On Fri, Jun 25, 2010 at 4:33 PM, Bruno Randolf <b...@einfach.org> wrote:
> hello! > > first of all i would say, we are not 100% sure if we do this correctly on > ath5k... > > more comments below: > > On Fri June 25 2010 02:32:52 Jack wrote: > > Hi everyone: > > > > i'm trying to migrate the ath5k to VxWorks 6.7. The target is to realize > > the basic rx & tx function on the VxWorks, with the Atheros AR5414a card. > > > > Now, the card can be successfully initialized and i can send or receive > 10 > > packets. > > > > The problem is, i found that it only can receive about 20 packets, and > then > > it will stop the rx. > > i added the logMsg() in the ath5k_tasklet_rx() and proc_rx_status() > > functions(in the VxWorks, i use the jobqueue instead of the tasklet > > mechanism in Linux). And i found that after receiving about 20 packets, > it > > would be failed when checking the "done" bit of the rx descriptor again > and > > again(sometimes just once, sometimes up to 30+ times). > > except the rxdp check failure, it also would be failed at the position of > > "bail if HW is still using self-linked descriptor" , again and again, > too. > > thats not clear to me. isnt "rxdp check failure" and "bail if HW is still > using self-linked descriptor" the same case? > > Sorry, that's a stupid mistake :p > i compared the different of the performance, between the ath5k under > Linux > > and my migration code under the Vxworks. I found that, under Linux, it > wil > > deal with just one packet in one tasklet after a RXOK interrupt, as > follow: > > intr > > > > ath5k_tasklet_rx > > > > (in the while loop) > > deal with the packet > > and meet a "rxdp bail" > > > > another intr or tasklet > > > > But in the VxWorks, it will deal couples of packets in one tasklet(a job > in > > the job queue, exactly), as follow: > > intr, intr, intr(about 20 intrs, if send 100 packets) > > > > ath5k_tasklet_rx > > > > (in the while loop) > > deal with the packet > > deal with the packet > > deal with the packet > > .........(about 30 packets received if send 100 packets) > > and meet a "done" bit not set, or a "rxdp bail" > > > > stopped > > > > I guess that in the VxWorks, the job queue is scheduled much slowly than > > the tasklet under Linux. So couples of interrupts come before the first > > schedule of job queue happened. And when they met a "done" bit not set or > > a "rxdp bail", the while() loop break, while no interrupt to make the > > job(ath5k_tasklet_rx) scheduled. > > hmm, but these two cases should only be met at the end of the queue, at the > last received descriptor. > But in fact, i printed the descriptor address out when those two cases happened, found that sometimes it was the end of the descriptor queue, but sometimes not -- that's the problem, i don't know why :( > > So i added the "self schedule" in the ath5k_tasklet_rx, but no positive. > > > > So can anyone give any suggestions? And any discussion will be > appreciated. > > Thank you very much! > > > > BTW: i disabled the cache under the VxWorks because i doubted that it was > > introduced by cache problem while doing the DMA issues. > > the HAL and ath9k have a check of the done bit of the next descriptor for > the > following reason (drivers/net/wireless/ath/ath9k/recv.c:786): > > /* > * On some hardware the descriptor status words could > * get corrupted, including the done bit. Because of > * this, check if the next descriptor's done bit is > * set or not. > * > * If the next descriptor's done bit is set, the current > * descriptor has been corrupted. Force s/w to discard > * this descriptor and continue... > */ > > i was wondering if we need to have something similar in ath5k too. it would > be > interesting to check if it helps in your case. > > yeap, i got the similar idea today, and added the test for "done" bit of the next descriptor. But because the limitation of time, i did not discard current descriptor yet, so i'll try it tomorrow. another thing is that we consider moving ath5k from tasklets to threaded > interrupt handlers, in which case we might also have more latency and > similar > issues as you face in VxWorks, now. so your results can be relevant for the > improvement of ath5k too. > In the VxWorks, the network card driver uses jobQueue as the bottom-half of the interrupt, and the scheduler of this job queue, tNet0, has a low priority. I suspected that this low priority would cause more latency, so i'm going to make my own job queue scheduler with high enough priority after solving this problem. While i have no idea about the "threaded interrupt handlers", perhaps i need some kinds of "charging". so i must do some "google" tomorrow :p > > bruno > -- Best wishes Jack.B
_______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
