[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150307024241.GB502@gospo.home.greyhouse.net>
Date: Fri, 6 Mar 2015 21:42:41 -0500
From: Andy Gospodarek <gospo@...ulusnetworks.com>
To: "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
Cc: Jiri Pirko <jiri@...nulli.us>, davem@...emloft.net,
netdev@...r.kernel.org
Subject: Re: [PATCH] team: add support to get speed via ethtool
On Fri, Mar 06, 2015 at 11:30:53AM -0800, Samudrala, Sridhar wrote:
>
> On 3/5/2015 11:16 PM, Jiri Pirko wrote:
> >Thu, Mar 05, 2015 at 10:48:35PM CET, sridhar.samudrala@...el.com wrote:
> >>With this patch ethtool <team> OR cat /sys/class/net/<team>/speed
> >>returns the speed of team based on member ports speed and state.
> >>
> >>Based on get speed support in bonding driver.
> >>
> >>Signed-off-by: Sridhar Samudrala <sridhar.samudrala@...el.com>
> >>---
> >>drivers/net/team/team.c | 25 +++++++++++++++++++++++++
> >>1 file changed, 25 insertions(+)
> >>
> >>diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
> >>index 9d3366f..e822803 100644
> >>--- a/drivers/net/team/team.c
> >>+++ b/drivers/net/team/team.c
> >>@@ -1954,6 +1954,30 @@ static int team_change_carrier(struct net_device *dev, bool new_carrier)
> >> return 0;
> >>}
> >>
> >>+static int team_ethtool_get_settings(struct net_device *dev,
> >>+ struct ethtool_cmd *ecmd)
> >>+{
> >>+ struct team *team = netdev_priv(dev);
> >>+ struct team_port *port;
> >>+ unsigned long speed = 0;
> >>+
> >>+ ecmd->duplex = DUPLEX_UNKNOWN;
> >>+ ecmd->port = PORT_OTHER;
> >>+
> >>+ mutex_lock(&team->lock);
> >>+ list_for_each_entry(port, &team->port_list, list) {
> >>+ if (port->linkup)
> >>+ speed += port->state.speed;
> >>+ if (ecmd->duplex == DUPLEX_UNKNOWN &&
> >>+ port->state.duplex != 0)
> >>+ ecmd->duplex = port->state.duplex;
> >>+ }
> >>+ ethtool_cmd_speed_set(ecmd, speed);
> >>+ mutex_unlock(&team->lock);
> >>+
> >>+ return 0;
> >>+}
> >Sridar, what exactly you are trying to achieve? I agree with DaveM that
> >this make no sense for soft devices. The fact bonding has it is a
> >mistake.
> >
> We are currently looking into the possibility of using team as a way to
> offload link aggregation support to switch hardware.
> To support LAG, a team device is created and the switch ports are added
> as members of the team. We are considering if we should create a new team
> mode specifically to support offload or the existing modes can be extended
> to enable offloading. Will appreciate any thoughts you have on this?
There is no real need to create an offload mode for teaming or bonding.
There is actually a similar thread happening right now to discuss how to
offload bonding to hardware, I would suggest browsing that and
discussing in that thread[1].
FWIW, we offload bonding right now without much issue by monitoring
netlink events. All the hardware really needs to know is the membership
information and the hash algorithm the user might like to set and both
of those are available on recent kernels via netlink. Based on the
hardware we are using and the in-kernel infrastructure that existed at
the time it was the proper choice.
1. [PATCH net-next 0/2] dsa: implement HW bonding
http://patchwork.ozlabs.org/patch/441907/
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists