From: Stefan Assmann <sassmann@redhat.com>
To: Ben Hutchings <bhutchings@solarflare.com>
Cc: netdev <netdev@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
davem@davemloft.net, Andy Gospodarek <gospo@redhat.com>,
"Rose, Gregory V" <gregory.v.rose@intel.com>,
"Duyck, Alexander H" <alexander.h.duyck@intel.com>,
Casey Leedom <leedom@chelsio.com>,
Harald Hoyer <harald@redhat.com>
Subject: Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
Date: Tue, 20 Jul 2010 13:47:03 +0200 [thread overview]
Message-ID: <4C458CB7.3030508@redhat.com> (raw)
In-Reply-To: <1279624844.2110.3.camel@achroite.uk.solarflarecom.com>
On 20.07.2010 13:20, Ben Hutchings wrote:
> On Tue, 2010-07-20 at 12:50 +0200, Stefan Assmann wrote:
>> From: Stefan Assmann <sassmann@redhat.com>
>>
>> Reserve a bit in struct net_device to indicate whether an interface
>> generates its MAC address randomly, and expose the information via
>> sysfs.
>> May look like this:
>> /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/net/eth0/ifrndmac
>>
>> By default the value of ifrndmac is 0. Any driver that generates the MAC
>> address randomly should return a value to 1.
>
> The name should incorporate 'address', not 'mac', for consistency with
> the generic 'address' attribute.
We can call it "ifrndhwaddr" if that's more consistent.
>
> What about devices that 'steal' MAC addresses from slave devices?
> Currently I believe udev has special cases for them but ideally these
> drivers would indicate explicitly that their addresses are not stable
> identifiers (even though they aren't random).
It's really up to the driver to decide whether it makes sense to set the
flag or not. The question is what should udev do with these MAC address
stealing devices apart from ignoring them? Sorry I have no higher
insight into it.
This flag has the purpose to allow udev to explicitly handle devices
that generate their MAC address randomly and generate a persistent
rule based on the device path instead of the MAC address.
I'm open for suggestions but I'm not sure we can handle both cases with
a single flag.
JFYI this is an alternative approach to changing the kernel name of VFs
to vfeth. The advantage of this way should be that we don't break any
user-space applications that rely on network interfaces being names
"ethX". Actually this goes in the direction of "fixing udev" which was
what you asked for in your comment on my first patch concering vfeth. :)
>
> [...]
>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>> index b626289..2ea0298 100644
>> --- a/include/linux/netdevice.h
>> +++ b/include/linux/netdevice.h
>> @@ -845,6 +845,7 @@ struct net_device {
>> #define NETIF_F_FCOE_MTU (1 << 26) /* Supports max FCoE MTU, 2158 bytes*/
>> #define NETIF_F_NTUPLE (1 << 27) /* N-tuple filters supported */
>> #define NETIF_F_RXHASH (1 << 28) /* Receive hashing offload */
>> +#define NETIF_F_RNDMAC (1 << 29) /* Interface with random MAC address */
> [...]
>
> This is not really a feature, and we are running out of real feature
> bits. Can you find somewhere else to put this flag?
Actually Dave Miller suggested to put it there. What other place is
there to put it?
Stefan
--
Stefan Assmann | Red Hat GmbH
Software Engineer | Otto-Hahn-Strasse 20, 85609 Dornach
| HR: Amtsgericht Muenchen HRB 153243
| GF: Brendan Lane, Charlie Peters,
sassmann at redhat.com | Michael Cunningham, Charles Cachera
next prev parent reply other threads:[~2010-07-20 11:47 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-20 10:50 [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address Stefan Assmann
2010-07-20 11:20 ` Ben Hutchings
2010-07-20 11:47 ` Stefan Assmann [this message]
2010-07-20 11:58 ` Alex Badea
2010-07-20 12:17 ` Stefan Assmann
2010-07-20 20:18 ` David Miller
2010-07-21 8:10 ` Stefan Assmann
2010-07-21 13:54 ` Ben Hutchings
2010-07-22 12:50 ` [PATCH net-next] sysfs: add attribute to indicate hw address assignment type Stefan Assmann
2010-07-22 14:07 ` Ben Hutchings
2010-07-22 14:47 ` Stefan Assmann
2010-07-25 3:50 ` David Miller
2010-07-20 12:07 ` [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address Ben Hutchings
2010-07-20 12:41 ` Stefan Assmann
2010-07-20 14:29 ` Ben Hutchings
2010-07-20 20:17 ` David Miller
2010-07-20 21:18 ` Stephen Hemminger
2010-07-20 21:20 ` David Miller
2010-07-21 6:26 ` Harald Hoyer
2010-07-21 6:34 ` David Miller
2010-07-21 6:47 ` Harald Hoyer
2010-07-21 15:07 ` Andy Gospodarek
2010-07-21 16:34 ` Casey Leedom
2010-07-21 17:28 ` Stephen Hemminger
2010-07-21 17:32 ` David Miller
2010-07-21 18:29 ` Casey Leedom
2010-07-21 18:39 ` David Miller
2010-07-21 19:25 ` Casey Leedom
2010-07-21 18:43 ` Rose, Gregory V
2010-07-21 18:48 ` David Miller
2010-07-21 18:50 ` David Miller
2010-07-21 19:02 ` Rose, Gregory V
2010-07-21 19:33 ` David Miller
2010-07-21 19:35 ` Rose, Gregory V
2010-07-22 7:12 ` Ian Campbell
2010-07-22 6:53 ` Stefan Assmann
2010-07-23 0:26 ` Casey Leedom
2010-07-23 8:08 ` Stefan Assmann
2010-07-23 16:35 ` Casey Leedom
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=4C458CB7.3030508@redhat.com \
--to=sassmann@redhat.com \
--cc=alexander.h.duyck@intel.com \
--cc=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--cc=gospo@redhat.com \
--cc=gregory.v.rose@intel.com \
--cc=harald@redhat.com \
--cc=leedom@chelsio.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.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).