netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Willy Tarreau <willy@w.ods.org>
To: Jay Vosburgh <fubar@us.ibm.com>
Cc: "David S. Miller" <davem@redhat.com>,
	Willy Tarreau <willy@w.ods.org>,
	jgarzik@pobox.com, marcelo@conectiva.com.br, netdev@oss.sgi.com,
	bonding-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2.4.22-pre9-bk : bonding bug fixes
Date: Thu, 31 Jul 2003 07:03:39 +0200	[thread overview]
Message-ID: <20030731050339.GA24641@alpha.home.local> (raw)
In-Reply-To: <200307310022.h6V0MGjK012821@death.ibm.com>

Hi Jay !

On Wed, Jul 30, 2003 at 05:22:15PM -0700, Jay Vosburgh wrote:
 
> 	I've been looking at Willy's fixes, and the typo (first patch)
> and locking fix (third patch) both look good to me.  The second patch
> (the dead code warning) points out a real problem, in that the code in
> question really has no function, but the patch probably doesn't go far
> enough for a final solution (the variable that code would set,
> arp_target_hw_addr, is referenced in other places, but ends up always
> being NULL because the dead code is the only place it was ever set).
> 
> 	A more proper solution would be to simply delete the dead code
> and the arp_target_hw_addr variable, and replace the variable
> references with NULL.  This means that all of the ARP probes sent will
> be sent out as broadcasts, which is what's already happening, this
> just makes the code clearer.  Patch follows (which replaces Willy's
> second patch).
> 
> 	Does this sound reasonable to everybody?

Perfectly reasonable to me. My patch was not intended to fix it but to allow
anybody to comment on this code, which would not have been possible if I removed
it myself ;-)

IMHO, ARP probes should always be sent with broadcast addresses. We could
think about switching to unicast when we get a reply, but we must switch back
to broadcast as soon as we lose a target. This would complexify the magic which
is not absolutely necessary here.

I might send other fix propositions later (2.4.23-pre) for the ARP behaviour
(better IP source address selection, etc...) because I don't like it very much
when drivers try to find their information themselves and stick to it for all
their life (eg: my_ip). I'd like to dynamically lookup the valid source IP at
each probe (which is not *that* frequent in fact).

Cheers,
Willy

  reply	other threads:[~2003-07-31  5:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-30 14:06 [PATCH] 2.4.22-pre9-bk : bonding bug fixes Willy Tarreau
2003-07-30 23:49 ` David S. Miller
2003-07-31  0:22   ` Jay Vosburgh
2003-07-31  5:03     ` Willy Tarreau [this message]
2003-07-31 18:50 ` Jeff Garzik

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=20030731050339.GA24641@alpha.home.local \
    --to=willy@w.ods.org \
    --cc=bonding-devel@lists.sourceforge.net \
    --cc=davem@redhat.com \
    --cc=fubar@us.ibm.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    --cc=netdev@oss.sgi.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).