From 64bb336c8f4de8b281d0d44f2ec2c900b9b28466 Mon Sep 17 00:00:00 2001 From: Casey Leedom <leedom@chelsio.com> Date: Tue, 29 Jun 2010 12:53:39 +0000 Subject: [PATCH] cxgb4vf: Remove obsolete comment about the lack of a TX Timer Callback Remove obsolete comment about the lack of a TX Timer Callback -- which we now _do_ have ... Signed-off-by: Casey Leedom <leedom@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net> --- drivers/net/cxgb4vf/sge.c | 13 +------------ 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/drivers/net/cxgb4vf/sge.c b/drivers/net/cxgb4vf/sge.c index f857d20e1d302..5c4a81dae19a1 100644 --- a/drivers/net/cxgb4vf/sge.c +++ b/drivers/net/cxgb4vf/sge.c @@ -1301,18 +1301,7 @@ int t4vf_eth_xmit(struct sk_buff *skb, struct net_device *dev) * wait for acks to really free up the data the extra memory * is even less. On the positive side we run the destructors * on the sending CPU rather than on a potentially different - * completing CPU, usually a good thing. We also run them - * without holding our TX queue lock, unlike what - * reclaim_completed_tx() would otherwise do. - * - * XXX Actually the above is somewhat incorrect since we don't - * XXX yet have a periodic timer which reclaims TX Descriptors. - * XXX What's our plan for this? - * XXX - * XXX Also, we don't currently have a TX Queue lock but - * XXX that may be the result of not having any current - * XXX asynchronous path for reclaiming completed TX - * XXX Descriptors ... + * completing CPU, usually a good thing. * * Run the destructor before telling the DMA engine about the * packet to make sure it doesn't complete and get freed -- 2.30.2