All of lore.kernel.org
 help / color / mirror / Atom feed
From: Casey Leedom <leedom@chelsio.com>
To: netdev@vger.kernel.org
Subject: PATCH 1/2] Remove obsolete comment about the lack of a TX Timer Callback -- which we ...
Date: Tue, 29 Jun 2010 15:53:39 -0700	[thread overview]
Message-ID: <201006291553.39333.leedom@chelsio.com> (raw)

>From fab966adc65f1b500e261867b3cb26bf35482b36 Mon Sep 17 00:00:00 2001
From: Casey Leedom <leedom@chelsio.com>
Date: Tue, 29 Jun 2010 15:14:38 -0700
Subject: [PATCH 1/2] Remove obsolete comment about the lack of a TX Timer Callback -- which we
 now _do_ have ...


Signed-off-by: Casey Leedom <leedom@chelsio.com>
---
 drivers/net/cxgb4vf/sge.c |   13 +------------
 1 files changed, 1 insertions(+), 12 deletions(-)

diff --git a/drivers/net/cxgb4vf/sge.c b/drivers/net/cxgb4vf/sge.c
index f857d20..5c4a81d 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
-- 
1.7.0.4


                 reply	other threads:[~2010-06-29 22:57 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201006291553.39333.leedom@chelsio.com \
    --to=leedom@chelsio.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.