> > 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?
> > 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. Click implements this. I just need to implement the polling extension. > - > 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 > - 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
