netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jay Vosburgh <fubar@us.ibm.com>
To: Jiri Pirko <jiri@resnulli.us>
Cc: netdev@vger.kernel.org, davem@davemloft.net, andy@greyhouse.net,
	stephen@networkplumber.org, psimerda@redhat.com, dcbw@redhat.com
Subject: Re: [patch net-next V2] bond: have random dev address by default instead of zeroes
Date: Fri, 25 Jan 2013 09:53:07 -0800	[thread overview]
Message-ID: <21365.1359136387@death.nxdomain> (raw)
In-Reply-To: <20130125072221.GB1659@minipsycho.orion>

Jiri Pirko <jiri@resnulli.us> wrote:

>Fri, Jan 25, 2013 at 07:37:13AM CET, jiri@resnulli.us wrote:
>>Fri, Jan 25, 2013 at 02:35:01AM CET, fubar@us.ibm.com wrote:
>>>Jiri Pirko <jiri@resnulli.us> wrote:
>>>
>>>>Makes more sense to have randomly generated address by default than to
>>>>have all zeroes. It also allows user to for example put the bond into
>>>>bridge without need to have any slaves in it.
>>>>
>>>>Also note that this changes only behaviour of bonds with no slaves. Once
>>>>the first slave device is enslaved, its address will be used (no change
>>>>here).
>
>
>Also, this is not entirely true now. Example:
>
>eth1 has 52:54:00:b8:30:0b
>
># ip link add bondx address 22:33:44:55:66:77 type bond
># ip link set eth1 master bondx
>
>Now both bondx and eth1 has 22:33:44:55:66:77
>
>Shouldn't both have 52:54:00:b8:30:0b ?

	This is the way bonding has worked for as long as I can recall.
The MAC of the first slave is assigned to the master, unless the bond
has had its MAC manually set to something prior to the first slave being
added.  If the bond's MAC has been set manually, then that MAC is used
instead of the first slave's MAC.

	Your patch doesn't appear to change that behavior, but it does
substitute a random MAC in place of the all zeroes MAC used previously
(and tests a flag to determine if the MAC has been manually set instead
of checking for the all zeroes MAC).

	I know of customers that rely on this behavior to explicitly set
the MAC of the bond (for filtering or accounting purposes).  It probably
should be documented more clearly, but I don't think it should be
changed.

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com

  reply	other threads:[~2013-01-25 17:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-24 20:01 [patch net-next V2] bond: have random dev address by default instead of zeroes Jiri Pirko
2013-01-25  1:35 ` Jay Vosburgh
2013-01-25  6:37   ` Jiri Pirko
2013-01-25  7:22     ` Jiri Pirko
2013-01-25 17:53       ` Jay Vosburgh [this message]
2013-01-25 17:56         ` Pavel Simerda
2013-01-25 18:31           ` Jay Vosburgh
2013-01-25 19:42             ` Pavel Simerda
2013-01-25 20:00             ` Jiri Pirko
2013-01-29 17:54             ` Dan Williams
2013-01-25 18:08         ` Jiri Pirko

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=21365.1359136387@death.nxdomain \
    --to=fubar@us.ibm.com \
    --cc=andy@greyhouse.net \
    --cc=davem@davemloft.net \
    --cc=dcbw@redhat.com \
    --cc=jiri@resnulli.us \
    --cc=netdev@vger.kernel.org \
    --cc=psimerda@redhat.com \
    --cc=stephen@networkplumber.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).