Re: [RFC] tulip: Support for byte queue limits
From: Grant Grundler <hidden>
Date: 2013-07-12 18:14:04
On Fri, Jul 12, 2013 at 11:01 AM, George Spelvin [off-list ref] wrote:
quoted
Hi George, While you are right that functionally it doesn't matter, my preference would be to have nothing between the wmb() and iowrite() that kicks off the TX. This marginally helps kick off the TX process consistently slightly sooner. On modern HW, probably irrelevant, but not on the HW these chips are used on.I'll revise it. It just made sense to me to put it next to the other bookkeeping line of tp->cur_tx++. Should I move them both below the iowrite()?
I would prefer that. I agree it's better to keep those two lines of code together. Just keep in mind this is a nit and it's not critical to accepting your change. So whatever you submit, I'll probably ACK.
quoted hunk ↗ jump to hunk
As in:--- a/drivers/net/ethernet/dec/tulip/tulip_core.c +++ b/drivers/net/ethernet/dec/tulip/tulip_core.c@@ -702,11 +702,11 @@ tulip_start_xmit(struct sk_buff *skb, struct net_device *dev) tp->tx_ring[entry].status = cpu_to_le32(DescOwned); wmb(); - tp->cur_tx++; - /* Trigger an immediate transmit demand. */ iowrite32(0, tp->base_addr + CSR1); + tp->cur_tx++; + netdev_sent_queue(dev, skb->len); spin_unlock_irqrestore(&tp->lock, flags); return NETDEV_TX_OK;
Yup - looks good.
quoted
Lastly, given I haven't powered up a system in two years which has tulip, any one want to take over maintainer for tulip driver? It's basically obsolete with a few rare patches like this one coming in.I'm not up to it myself, sorry.
No worries. Just wanted to advertise to anyone who bothers to read about tulip patches. :) cheers, grant