netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael Chan" <mchan@broadcom.com>
To: "Stephen Hemminger" <shemminger@osdl.org>
Cc: davem@davemloft.net, herbert@gondor.apana.org.au,
	jgarzik@pobox.com, netdev@vger.kernel.org
Subject: Re: [PATCH 2.6.18 2/3] tg3: Convert to non-LLTX
Date: Mon, 05 Jun 2006 16:34:09 -0700	[thread overview]
Message-ID: <1149550449.13155.33.camel@rh4> (raw)
In-Reply-To: <20060605173159.33d81d59@localhost.localdomain>

On Mon, 2006-06-05 at 17:31 -0700, Stephen Hemminger wrote:
> On Mon, 05 Jun 2006 14:29:45 -0700
> "Michael Chan" <mchan@broadcom.com> wrote:
> 
> > On Mon, 2006-06-05 at 15:58 -0700, Stephen Hemminger wrote:
> > 
> > > 
> > > Since you are going more lockless, you probably need memory barriers.
> > 
> > No, we're not going more lockless. We're simply replacing the private
> > tx_lock with dev->xmit_lock by dropping the LLTX feature flag. The
> > amount of locking is exactly the same as before.
> 
> Those spin lock's were also acting as barriers.

Why is it different whether we use dev->xmit_lock right before entering
hard_start_xmit() without LLTX or a private tx_lock at the beginning of
hard_start_xmit() with LLTX? In both cases, we take one BH disabling
lock to serialize hard_start_xmit(). And in both cases, the spinlock
will provide the same barrier effect.

> Are you sure code is safe in the face of cpu reordering.
> 
Yes, hard_start_xmit() only touches the tx producer index and tx
completion handling only touches the tx consumer index.

There is actually one wrinkle but it has nothing to do with the locking
change in this patch. During the sequence of writing the tx descriptors
to memory and the MMIO write to tell the chip to DMA the new
descriptors, the MMIO can be re-ordered ahead of the writing of the tx
descriptors on the powerpc, for example. This will lead to DMAing stale
descriptor data. In earlier kernels, the ppc writel has a memory barrier
to prevent this but it was removed in recent kernels. We had a
discussion with Anton Blanchard and other folks at IBM and DaveM on this
and it was decided that the writel should provide the barrier instead of
drivers adding all kinds of barriers throughout the driver code.


  reply	other threads:[~2006-06-06  1:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-05 19:47 [PATCH 2.6.18 2/3] tg3: Convert to non-LLTX Michael Chan
2006-06-05 22:58 ` Stephen Hemminger
2006-06-05 21:29   ` Michael Chan
2006-06-06  0:31     ` Stephen Hemminger
2006-06-05 23:34       ` Michael Chan [this message]
2006-06-05 23:06   ` David Miller
2006-06-18  4:58 ` David Miller

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=1149550449.13155.33.camel@rh4 \
    --to=mchan@broadcom.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=jgarzik@pobox.com \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@osdl.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 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).