On Tuesday 29 April 2014 17:54:12 Stefan Wahren wrote: > > As far as I know it's also not mandatory. > > > > If the hardware interfaces require calling sleeping functions, it > > may not actually be possible, but if you can use it, it normally > > provides better performance. > > As i understood NAPI is good for high load on 1000 MBit ethernet, but > the QCA7000 has > in best case only a 10 MBit powerline connection. Additionally these > packets must be transfered > over a half duplex SPI. So i think the current driver implementation > isn't a bottle neck. Ok, makes sense. What is the slowest speed you might see then? You already have a relatively small queue of at most 10 frames, but if this goes below 10 Mbit, that can still be noticeable bufferbloat. Try adding calls to netdev_sent_queue, netdev_completed_queue and netdev_reset_queue to let the network stack know how much data is currently queued up for the tx thread. On a related note, there is one part I don't understand: +netdev_tx_t +qcaspi_netdev_xmit(struct sk_buff *skb, struct net_device *dev) +{ + u32 frame_len; + u8 *ptmp; + struct qcaspi *qca = netdev_priv(dev); + u32 new_tail; + struct sk_buff *tskb; + u8 pad_len = 0; + + if (skb->len < QCAFRM_ETHMINLEN) + pad_len = QCAFRM_ETHMINLEN - skb->len; + + if (qca->txq.skb[qca->txq.tail]) { + netdev_warn(qca->net_dev, "queue was unexpectedly full!\n"); + netif_stop_queue(qca->net_dev); + qca->stats.queue_full++; + return NETDEV_TX_BUSY; + } You print a 'netdev_warn' message here when the queue is full, expecting this to be rare. If the device is so slow, why doesn't this happen all the time? Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html