On Sun, Jun 27, 2010 at 10:38 PM, Jack <jack.bearmas...@gmail.com> wrote:
> > > On Sat, Jun 26, 2010 at 1:45 AM, Jack <jack.bearmas...@gmail.com> wrote: > >> >> 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 >> > > I added the check of the done bit of the next descriptor if current one was > not done, according to ath9k's codes. Unfortunately, i got the same result. > And i found that if i set the rx buffer number to 1000+, there would be > exactly 1000 packets received, even if i sent 10000 packets or more. But if > setting the rx buffer number to 50, there would be only 70 packets received > continuously, and about 8 packets not received discontinuously. (I made some > bytes of the tx packets as a counter, and i got pkt0, pkt1, ....., ptk69, > and then the ptk101, ptk114, ptk150, .....) > > So any suggestions or discussions? > Thank you. > > -- > Best wishes > Jack.B > Today, i found that there would be only 1000 RXOK interrupt occured, that's why only 1000 packets received. I suspected that it 's because the latency of VxWorks jobQueue is much more than the Linux tasklet. So the card could not get the next descriptor when the job function processed too slow. I'm going to move part codes of rxbuf_setup() to the ath5k_intr(), setting the next descriptor earlier, to reduce the influence brought by the high latency. -- Jack
_______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
