From: Chris Leech <christopher.leech@intel.com>
To: David Miller <davem@davemloft.net>
Cc: "Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"gospo@redhat.com" <gospo@redhat.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH] netdev: storage address support
Date: Mon, 27 Apr 2009 15:28:00 -0700 [thread overview]
Message-ID: <20090427222800.GA14396@cleech-lnx.jf.intel.com> (raw)
In-Reply-To: <20090427.030103.88777540.davem@davemloft.net>
On Mon, Apr 27, 2009 at 03:01:03AM -0700, David Miller wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Fri, 24 Apr 2009 01:03:50 -0700
>
> > 2) Server Provided MAC Address (SPMA)
> > The server indicates to the FCF the address it would like to use for FCoE
> > traffic. It's expected that SPMA capable interfaces will have a storage
> > dedicated MAC address programed into EPROM, flash, or other non-volatile
> > storage which the driver will be able to provide to the FCoE stack.
> >
> > This adds a net_device_ops function to query a driver for a dedicated storage
> > address.
> >
> > If ndo_get_storage_address is implemented, then the address will also be
> > exposed as a sysfs attribute. In order to do that, a new optional attrs group
> > is added to the net_device, with the visibility of each attribute protected by
> > a call to netdev_show_optional_attr().
>
> This should be what is currently provided in netdev->perm_addr[]
>
> I really see no difference.
There seems to be some desire to use separate MAC address for LAN and
SAN traffic on a converged network, even when using the server provided
addressing mode for FCoE. So I'm looking at a device that has an extra
MAC address in it's EEPROM, that's intended to be used for SAN traffic
only.
At first glance Jiri's "list of device addresses" patch seems to be
heading towards a more general approach to having multiple MAC
addresses, without providing any sort of intent on how they should be
used. But given that it's trying to solve a bonding + bridging issue,
the addresses involved seem fairly dynamic and I'm not sure how it
differs much from the existing uc_list.
Ignoring the issue of intended use for the moment, if an ethernet driver
wanted to advertise several MAC addresses to the system how should it go
about that?
- Chris
next prev parent reply other threads:[~2009-04-27 22:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-24 8:03 [PATCH] netdev: storage address support Jeff Kirsher
2009-04-27 10:01 ` David Miller
2009-04-27 22:28 ` Chris Leech [this message]
2009-04-28 1:48 ` David Miller
2009-04-28 8:30 ` Jiri Pirko
2009-04-28 9:12 ` David Miller
2009-04-28 10:18 ` Jiri Pirko
2009-04-28 11:25 ` 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=20090427222800.GA14396@cleech-lnx.jf.intel.com \
--to=christopher.leech@intel.com \
--cc=davem@davemloft.net \
--cc=gospo@redhat.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=linux-scsi@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