From: Jay Vosburgh <jv@jvosburgh.net>
To: Hangbin Liu <liuhangbin@gmail.com>
Cc: netdev@vger.kernel.org, Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Nikolay Aleksandrov <razor@blackwall.org>,
Simon Horman <horms@kernel.org>, Cosmin Ratiu <cratiu@nvidia.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCHv2 net] bonding: use permanent address for MAC swapping if device address is same
Date: Wed, 23 Apr 2025 09:27:40 -0700 [thread overview]
Message-ID: <511373.1745425660@famine> (raw)
In-Reply-To: <aAXhiW6n-ftxAr9M@fedora>
Hangbin Liu <liuhangbin@gmail.com> wrote:
>On Sun, Apr 20, 2025 at 10:10:24PM -0700, Jay Vosburgh wrote:
>> >I'm not familiar with infiniband devices. Can we use eth_random_addr()
>> >to set random addr for infiniband devices? And what about other device
>> >type? Just return error directly?
>>
>> Infiniband devices have fixed MAC addresses that cannot be
>> changed. Bonding permits IB devices only in active-backup mode, and
>> will set fail_over_mac to active (fail_over_mac=follow is not permitted
>> for IB).
>>
>> I don't understand your questions about other device types or
>> errors, could you elaborate?
>>
>
>I mean what if other device type enslaves, other than ethernet or infiniband.
>I'm not sure if we can set random mac address for these devices. Should we
>ignore all none ethernet device or devices that don't support
>ndo_set_mac_address?
Devices without ndo_set_mac_address are already handled; they
are limited to active-backup mode and fail_over_mac is set to active
(just like Infiniband).
I'm not aware of any network device types other than Ethernet
(which to bonding is anything with dev->type == ARPHRD_ETHER) or
Infiniband in use with bonding. If there are any, and the driver
supports ndo_set_mac_address, and it fails for a random MAC if they try
to use fail_over_mac=follow, then I'll look forward to the bug report.
If you're thinking of devices that are type ARPHRD_ETHER but
aren't actual ethernet (virtual devices, veth, et al, perhaps?), then
I'm not sure why those would require fail_over_mac=follow, as its reason
for existence is for multiport devices that can't handle multiple ports
programmed to the same MAC, which shouldn't matter for virtual devices
or single port physical devices.
-J
---
-Jay Vosburgh, jv@jvosburgh.net
next prev parent reply other threads:[~2025-04-23 16:27 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-01 9:06 [PATCHv2 net] bonding: use permanent address for MAC swapping if device address is same Hangbin Liu
2025-04-04 21:36 ` Jay Vosburgh
2025-04-07 9:34 ` Hangbin Liu
2025-04-14 6:06 ` Hangbin Liu
2025-04-16 1:15 ` Jay Vosburgh
2025-04-16 2:52 ` Hangbin Liu
2025-04-18 4:16 ` Jay Vosburgh
2025-04-18 7:39 ` Hangbin Liu
2025-04-21 4:24 ` Hangbin Liu
2025-04-21 5:10 ` Jay Vosburgh
2025-04-21 6:11 ` Hangbin Liu
2025-04-23 16:27 ` Jay Vosburgh [this message]
2025-04-24 3:22 ` Hangbin Liu
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=511373.1745425660@famine \
--to=jv@jvosburgh.net \
--cc=andrew+netdev@lunn.ch \
--cc=cratiu@nvidia.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liuhangbin@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=razor@blackwall.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.