linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nishant Sarmukadam <nishants@marvell.com>
To: Lennert Buytenhek <buytenh@wantstofly.org>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	Pradeep Nemavat <pnemavat@marvell.com>
Subject: Re: [PATCH 2/4] mwl8k: Add timestamp information for tx packets
Date: Thu, 21 Apr 2011 13:45:00 +0530	[thread overview]
Message-ID: <1303373700.24017.44.camel@localhost.localdomain> (raw)
In-Reply-To: <20110421073439.GV1897@wantstofly.org>


On Thu, 2011-04-21 at 00:34 -0700, Lennert Buytenhek wrote:
> On Tue, Apr 19, 2011 at 06:36:41PM +0530, Nishant Sarmukadam wrote:
> 
> > > > > > Timestamp tx packets using a HW micro-second timer.
> > > > > > This timestamp will be compared to the current timestamp
> > > > > > in the hardware and if the difference is greater than 500ms,
> > > > > > the packet will be dropped.
> > > > > 
> > > > > Why don't you do this entirely in the firmware?
> > > > > 
> > > > > When a packet is put into the TX ring by the host, give it a timestamp
> > > > > of zero.
> > > > > 
> > > > > When the firmware gets a TX interrupt, have it walk the TX ring from
> > > > > the last TX entry where a timestamp was written to (i.e. keep a separate
> > > > > index for this), and timestamp all TX ring entries that are marked as
> > > > > being FW OWNED but don't have a timestamp yet (and update your index).
> > > > > 
> > > > > Then when the time comes to process the TX packet (i.e. it has reached
> > > > > the head of the TX queue), compare the timestamp with the current time.
> > > > 
> > > > Since firmware cannot access host memory directly, it needs additional
> > > > dma operations to read all descriptors, then check the ownership bit and
> > > > update the timestamp for the descriptors. It can easily take about 1us
> > > > per descriptor for this and it can hit the peak throughput by about
> > > > 2.5%.
> > > 
> > > That DMA needs to happen anyway, whether you have the host timestamp
> > > the packets or not, so this doesn't seem to be an applicable argument.
> > 
> > Currently, firmware downloads a small fixed number of descriptors at a
> > given time from any tx queue as it does not have memory to download all
> > the descriptors from a host queue.
> > 
> > Assume that the total tx buffers available in firmware is X and host tx
> > queue size is 2X and that the host queue is completely backlogged. In
> > this case, the firmware needs to download the descriptors from the head
> > of the host queue to transmit corresponding packets and it needs to
> > download the descriptors at the tail of the host queue to timestamp
> > them. But, firmware cannot transmit the packets associated with
> > descriptors from the tail since there are packets in host queue which
> > were queued earlier to these packets. This effectively results in each
> > descriptor being downloaded twice - once for timestamp and once for
> > transmission.
> 
> Point taken, but if the firmware has N buffers in its H/W TX ring,
> does the host really need to have 2N buffers in its F/W TX ring?

Yes, we have confirmed this and 2N buffers are needed in the host for
peak throughput. 
> 
> There is another issue in that mwl8k H/W reports that a packet has been
> transmitted OK even before the packet is attempted to be transmitted
> (i.e. firmware marks the packet as transmitted as soon as the DMA for
> the packet data completes), which sounds like a good candidate for
> fixing at the same time.
> 
Since, this issue is generic and needs to be addressed irrespective of
the current patch set, we prefer handling this in a separate patch.

> 
> > This will significantly affect the peak throughput performance.
> 
> Does that mean that you've implemented this and tried it out? :-)

Yes, we have recently done some profiling experiments in the firmware to
confirm this. 


  reply	other threads:[~2011-04-21  8:18 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-19  5:42 [PATCH 1/4] mwl8k: Do not stop tx queues Nishant Sarmukadam
2011-04-19  5:42 ` [PATCH 2/4] mwl8k: Add timestamp information for tx packets Nishant Sarmukadam
2011-04-19  7:54   ` Lennert Buytenhek
2011-04-19 10:08     ` Nishant Sarmukadam
2011-04-19 10:31       ` Lennert Buytenhek
2011-04-19 13:06         ` Nishant Sarmukadam
2011-04-21  7:34           ` Lennert Buytenhek
2011-04-21  8:15             ` Nishant Sarmukadam [this message]
2011-04-19  5:42 ` [PATCH 3/4] mwl8k: Reserve buffers for tx management frames Nishant Sarmukadam
2011-04-19  5:42 ` [PATCH 4/4] mwl8k: Enable life time expiry for tx packets in the hardware Nishant Sarmukadam
2011-04-19  7:48 ` [PATCH 1/4] mwl8k: Do not stop tx queues Lennert Buytenhek
2011-04-19 10:08   ` Nishant Sarmukadam
2011-04-19 10:26     ` Lennert Buytenhek
2011-04-19 13:05       ` Nishant Sarmukadam

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=1303373700.24017.44.camel@localhost.localdomain \
    --to=nishants@marvell.com \
    --cc=buytenh@wantstofly.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=pnemavat@marvell.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).