From: Jiri Pirko <jiri@resnulli.us>
To: Or Gerlitz <or.gerlitz@gmail.com>
Cc: Narendra_K@dell.com, netdev@vger.kernel.org,
bhutchings@solarflare.com, john.r.fastabend@intel.com
Subject: Re: [PATCH net-next] net: Add phys_port identifier to struct net_device and export it to sysfs
Date: Sun, 21 Jul 2013 09:24:55 +0200 [thread overview]
Message-ID: <20130721072455.GA1944@minipsycho.orion> (raw)
In-Reply-To: <CAJZOPZL7MVBphUvojJ7RjnF8EYVyMNgr4zta2_A8VZw7bKkRaQ@mail.gmail.com>
Sun, Jul 21, 2013 at 07:55:41AM CEST, or.gerlitz@gmail.com wrote:
>On Mon, Jul 15, 2013 at 6:34 PM, <Narendra_K@dell.com> wrote:
>[...]
>> It is implemented in this patch here -
>> [RFC,net-next] net: Include phys_port identifier in the RTM_NEWLINK
>> message http://patchwork.ozlabs.org/patch/255435/
>>
>> Please find the patch with the changes incorporated. If the changes look
>> good, i will incorporate them in the next version of the patch.
>>
>> [PATCH net-next ] Add phys_port identifier to struct net_device and export it to sysfs
>>
>> It is useful to know if network interfaces from NIC partitions
>> 'map to/use the' same physical port. For example, when creating
>> bonding in fault tolerance mode, if two network interfaces map to/use
>> the same physical port, it might not have the desired result. This
>> information is not available today in a standard format or it is not
>> present. If this information can be made available in a generic way
>> to user space, tools such as NetworkManager or Libteam or Wicked can
>> make smarter bonding decisions (such as warn users when setting up
>> configurations which will not have desired effect).
>>
>> The requirement is to have a generic interface using which
>> kernel/drivers can provide information/hints to user space about the
>> physical port number used by a network interface.
>>
>> The following options were explored -
>>
>> 1. 'dev_id' sysfs attribute:
>>
>> In addition to being used to differentiate between devices that share
>> the same link layer address, it is being used to indicate the physical
>> port number used by a network interface.
>>
>> As dev_id exists to differentiate between devices sharing the same
>> link layer address, dev_id option is not selected.
>>
>> 2. Re-using 'if_port' field in 'struct net_device':
>>
>> if_port field exists to indicate the media type(please refer to
>> netdevice.h). It seemed like it was also used to indicate the physical
>> port number.
>>
>> As re-using 'if_port' might possibly break user space, this option is
>> not selected.
>>
>> 3. Add a new field 'phys_port' to 'struct net_device' and export it to sysfs:
>>
>> The 'phys_port' will be a universally unique identifier, which
>> would be a MAC-48 or EUI-64 or a 128 bit UUID value, but not
>> restricted to these spaces. It will uniquely identify the physical
>> port used by a network interface. The 'length' of the identifier will
>> be zero if the field is not set for a network interface.
>>
>> This patch implements option 3. It creates a new sysfs attribute
>> 'phys_port' -
>>
>> /sys/class/net/<interface name>/phys_port
>
>Hi Narendra, John, Ben, Jiri,
>
>Before diving to the eswitch use cases of this patch/approach, I was
>wondering if/how the new
>phys_port field could be of use for drivers that just want to place
>there an INT saying if this interface
>is associated with port #N of the PCI device (e.g N={1,2}). I wasn't
>sure how this is supposted
>to be done if the semantics of the new field is the one mentioned
>above in the change long
>(MAC-48 or EUI-64 or a 128 bit UUID value). Both mlx4 and ipoib driver
>use the dev_id field and would
>be happily ported to the new interface once introduced in a way that
>allows to meet the integer requirement.
The value could be anything. But note that you have to have different
values for card1-port1,2 and card2-port1,2
>
>Or.
>
>> References: http://marc.info/?l=linux-netdev&m=136920998009209&w=2
>> References: http://marc.info/?l=linux-netdev&m=136992041432498&w=2
>>
>> Signed-off-by: Narendra K <narendra_k@dell.com>
>> ---
>> include/linux/netdevice.h | 14 ++++++++++++++
>> net/core/net-sysfs.c | 22 ++++++++++++++++++++++
>> 2 files changed, 36 insertions(+)
>>
>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>> index 0741a1e..17db7e5 100644
>> --- a/include/linux/netdevice.h
>> +++ b/include/linux/netdevice.h
>> @@ -1062,6 +1062,14 @@ struct net_device_ops {
>> bool new_carrier);
>> };
>>
>> +/* This structure holds a universally unique identifier to
>> + * identify the physical port used by a netdevice
>> + */
>> +struct phys_port_identifier {
>> + unsigned char port_id[MAX_ADDR_LEN];
>> + unsigned char port_id_len;
>> +};
>> +
>> /*
>> * The DEVICE structure.
>> * Actually, this whole structure is a big mistake. It mixes I/O
>> @@ -1181,6 +1189,11 @@ struct net_device {
>> * that share the same
>> link
>> * layer address
>> */
>> + struct phys_port_identifier phys_port; /* Universally unique
>> physical
>> + * port identifier,
>> MAC-48 or
>> + * EUI-64 or 128 bit
>> UUID,
>> + * length is zero if
>> not set
>> + */
>> spinlock_t addr_list_lock;
>> struct netdev_hw_addr_list uc; /* Unicast mac addresses
>> */
>> struct netdev_hw_addr_list mc; /* Multicast mac addresses
>> */
>> @@ -1633,6 +1646,7 @@ struct packet_offload {
>> #define NETDEV_NOTIFY_PEERS 0x0013
>> #define NETDEV_JOIN 0x0014
>> #define NETDEV_CHANGEUPPER 0x0015
>> +#define NETDEV_CHANGE_PHYS_PORT 0x0016
>>
>> extern int register_netdevice_notifier(struct notifier_block *nb);
>> extern int unregister_netdevice_notifier(struct notifier_block *nb);
>> diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
>> index 981fed3..b77ebe6 100644
>> --- a/net/core/net-sysfs.c
>> +++ b/net/core/net-sysfs.c
>> @@ -334,6 +334,27 @@ static ssize_t store_group(struct device *dev, struct
>> device_attribute *attr,
>> return netdev_store(dev, attr, buf, len, change_group);
>> }
>>
>> +static ssize_t show_phys_port(struct device *dev,
>> + struct device_attribute *attr, char *buf)
>> +{
>> + struct net_device *net = to_net_dev(dev);
>> + ssize_t ret = -EINVAL;
>> + unsigned char len;
>> +
>> + read_lock(&dev_base_lock);
>> + if (dev_isalive(net)) {
>> + len = net->phys_port.port_id_len;
>> + if (!len)
>> + ret = 0;
>> + else
>> + ret = sysfs_format_mac(buf,
>> net->phys_port.port_id,
>> + len);
>> + }
>> + read_unlock(&dev_base_lock);
>> +
>> + return ret;
>> +}
>> +
>> static struct device_attribute net_class_attributes[] = {
>> __ATTR(addr_assign_type, S_IRUGO, show_addr_assign_type, NULL),
>> __ATTR(addr_len, S_IRUGO, show_addr_len, NULL),
>> @@ -355,6 +376,7 @@ static struct device_attribute net_class_attributes[]
>> = {
>> __ATTR(tx_queue_len, S_IRUGO | S_IWUSR, show_tx_queue_len,
>> store_tx_queue_len),
>> __ATTR(netdev_group, S_IRUGO | S_IWUSR, show_group, store_group),
>> + __ATTR(phys_port, S_IRUGO, show_phys_port, NULL),
>> {}
>> };
>>
>> --
>> 1.8.0.1
>>
>> --
>> With regards,
>> Narendra K
>> Linux Engineering
>> Dell Inc.
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2013-07-21 7:25 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-17 18:10 [PATCH net-next] net: Add phys_port identifier to struct net_device and export it to sysfs Narendra_K
2013-06-17 18:47 ` John Fastabend
2013-06-19 14:29 ` Narendra_K
2013-06-19 15:36 ` Ben Hutchings
2013-06-19 18:53 ` Narendra_K
2013-06-19 19:34 ` Ben Hutchings
2013-06-19 21:37 ` Praveen_Paladugu
2013-06-21 17:11 ` John Fastabend
2013-06-25 17:33 ` Narendra_K
2013-06-28 16:33 ` John Fastabend
2013-06-28 17:09 ` Ben Hutchings
2013-07-02 14:40 ` Narendra_K
2013-07-11 20:39 ` Jiri Pirko
2013-07-15 15:34 ` Narendra_K
2013-07-21 5:55 ` Or Gerlitz
2013-07-21 7:24 ` Jiri Pirko [this message]
2013-07-21 11:14 ` Or Gerlitz
2013-07-21 14:48 ` Ben Hutchings
2013-07-21 20:29 ` Or Gerlitz
2013-07-21 20:50 ` Ben Hutchings
2013-07-22 11:46 ` Narendra_K
2013-07-22 11:49 ` Jiri Pirko
2013-07-22 15:48 ` Or Gerlitz
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=20130721072455.GA1944@minipsycho.orion \
--to=jiri@resnulli.us \
--cc=Narendra_K@dell.com \
--cc=bhutchings@solarflare.com \
--cc=john.r.fastabend@intel.com \
--cc=netdev@vger.kernel.org \
--cc=or.gerlitz@gmail.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).