Re: help on tg3 polling extension
Yes, It wastes CPU cycles if there is other process running. However, as it being a dedicated router, it should not be a problem. The process of packets is the only task it is supposed to do. Compared to NAPI, click polling will disable Nic interrupts during its operation, even there is no any packets in the rx buffer. This destroys latency if you only recheck the RX buffer using timer interrupts. Even with HZ=1000, on gigabit links your packet latency will be terrible. We've tried this before. The latency incurred will be a problem on all Nics, or just on tg3? What's the overhead cause this latency? Since the Click will use CPU exclusively and poll the status all the time, why there will be terrible latency? It's driver agnostic. Since the timer ticks only as fast as the HZ supported on the platform, the lowest latency you can obtain from timer based rechecking is 1 HZ. So you're not using a timer, and will just poll like crazy until some packets arrive? That sounds like a waste of cpu cycles to me. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: help on tg3 polling extension
From: Qinghua(Kevin) Ye [EMAIL PROTECTED] Date: Wed, 6 Jul 2005 11:36:40 -0600 Compared to NAPI, click polling will disable Nic interrupts during its operation, even there is no any packets in the rx buffer. This destroys latency if you only recheck the RX buffer using timer interrupts. Even with HZ=1000, on gigabit links your packet latency will be terrible. We've tried this before. The latency incurred will be a problem on all Nics, or just on tg3? What's the overhead cause this latency? Since the Click will use CPU exclusively and poll the status all the time, why there will be terrible latency? It's driver agnostic. Since the timer ticks only as fast as the HZ supported on the platform, the lowest latency you can obtain from timer based rechecking is 1 HZ. So you're not using a timer, and will just poll like crazy until some packets arrive? That sounds like a waste of cpu cycles to me. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: help on tg3 polling extension
From: Qinghua(Kevin) Ye [EMAIL PROTECTED] Date: Wed, 6 Jul 2005 14:12:29 -0600 Yes, you are right. Click acturally will release the CPU to OS at interval. Other processes will be responded at this interval. It is not Click's right to make this kind of decision, that is what we have the process scheduler for. The goal of polling extension is to reduce the interrupt overhead and improve the throughput, especailly the small packets. NAPI does solve this problem to some extend. And the extent to which NAPI does not solve this problem is??? Please propose something that solves this problem better and still respects the other processes and resources in the system. If not use polling, how can I make use of all the CPUs to process packets? Can I make all of the CPUs run SOFTIRQ and IRQ code simultaneously? It seems there is only one ksoftirqd process busy dealing with process, while the other ksoftirqd is idle in my system. There is one ksoftirqd for each cpu in the system. All the network card interrupts are arriving at that one cpu on your machine, so the other ksoftirqd doesn't have any work to do. If ksoftirqd is running very often, this means that network processing is consuming an enormous amount of your cpu. So it gets scheduled to a process and thus the packet processing is properly shared with other processes on the system and nobody is starved out. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: help on tg3 polling extension
In my SMP platform, there is no other processes running. The usage of CPUs are 100% and 0%. How could I make Nic interrupts not arrive at only one CPU, or balance the interrupt between two CPUs? This doesn't work. If you try to split up the work for one network card amongst multiple cpus, you'll get SMP cache line movements for shared data between the processors and performance will go down. In my case, there are two Nics on the board. Can I bind the interrupt of each Nic to one of the CPUs? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: help on tg3 polling extension
From: Qinghua(Kevin) Ye [EMAIL PROTECTED] Date: Tue, 5 Jul 2005 16:19:27 -0600 Compared to NAPI, click polling will disable Nic interrupts during its operation, even there is no any packets in the rx buffer. This destroys latency if you only recheck the RX buffer using timer interrupts. Even with HZ=1000, on gigabit links your packet latency will be terrible. We've tried this before. The other difference is its reusage of packet buffer. It implements its own buffer recycle scheme. So once there are some packets received by tg3_rx_poll(), it will refill the DMA ring by tg3_rx_refill() by allocate buffer from its recycle queue. And once the packet is send out by tg3_tx_queue(), and cleaned by tg3_tx_clean, it will be collected into recycle queue. This is interesting as a generic facility usable by drivers. It needn't be CLICK specific. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
