Message-ID: <9B0331B6EBBD0E4684FBFAEDA55776F918890AE2@HASMSX110.ger.corp.intel.com>
Date:	Sat, 13 Dec 2014 14:39:49 +0000
From:	"Rosen, Rami" <rami.rosen@...el.com>
To:	"Varlese, Marco" <marco.varlese@...el.com>,
	Roopa Prabhu <roopa@...ulusnetworks.com>,
	Jiri Pirko <jiri@...nulli.us>
CC:	John Fastabend <john.fastabend@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"stephen@...workplumber.org" <stephen@...workplumber.org>,
	"Fastabend, John R" <john.r.fastabend@...el.com>,
	"sfeldma@...il.com" <sfeldma@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [RFC PATCH net-next 1/1] net: Support for switch port
 configuration

Hi, all,

Regarding preferring using netlink sockets versus ethtool IOCTLs for setting kernel network attributes from userspace, I fully agree with Marco. The netlink API is much more structured and
much more geared towards this type of operation, than the IOCTL-based ethtool. 

Regards,
Rami Rosen
Software Engineer, Intel

-----Original Message-----
From: netdev-owner@...r.kernel.org [mailto:netdev-owner@...r.kernel.org] On Behalf Of Varlese, Marco
Sent: Friday, December 12, 2014 11:20
To: Roopa Prabhu; Jiri Pirko
Cc: John Fastabend; netdev@...r.kernel.org; stephen@...workplumber.org; Fastabend, John R; sfeldma@...il.com; linux-kernel@...r.kernel.org
Subject: RE: [RFC PATCH net-next 1/1] net: Support for switch port configuration

> -----Original Message-----
> From: Roopa Prabhu [mailto:roopa@...ulusnetworks.com]
> Sent: Thursday, December 11, 2014 5:41 PM
> To: Jiri Pirko
> Cc: Varlese, Marco; John Fastabend; netdev@...r.kernel.org; 
> stephen@...workplumber.org; Fastabend, John R; sfeldma@...il.com; 
> linux-kernel@...r.kernel.org
> Subject: Re: [RFC PATCH net-next 1/1] net: Support for switch port 
> configuration
> 
> On 12/11/14, 8:56 AM, Jiri Pirko wrote:
> > Thu, Dec 11, 2014 at 05:37:46PM CET, roopa@...ulusnetworks.com wrote:
> >> On 12/11/14, 3:01 AM, Jiri Pirko wrote:
> >>> Thu, Dec 11, 2014 at 10:59:42AM CET, marco.varlese@...el.com wrote:
> >>>>> -----Original Message-----
> >>>>> From: John Fastabend [mailto:john.fastabend@...il.com]
> >>>>> Sent: Wednesday, December 10, 2014 5:04 PM
> >>>>> To: Jiri Pirko
> >>>>> Cc: Varlese, Marco; netdev@...r.kernel.org; 
> >>>>> stephen@...workplumber.org; Fastabend, John R; 
> >>>>> roopa@...ulusnetworks.com; sfeldma@...il.com; linux- 
> >>>>> kernel@...r.kernel.org
> >>>>> Subject: Re: [RFC PATCH net-next 1/1] net: Support for switch 
> >>>>> port configuration
> >>>>>
> >>>>> On 12/10/2014 08:50 AM, Jiri Pirko wrote:
> >>>>>> Wed, Dec 10, 2014 at 05:23:40PM CET, marco.varlese@...el.com
> wrote:
> >>>>>>> From: Marco Varlese <marco.varlese@...el.com>
> >>>>>>>
> >>>>>>> Switch hardware offers a list of attributes that are 
> >>>>>>> configurable on a per port basis.
> >>>>>>> This patch provides a mechanism to configure switch ports by 
> >>>>>>> adding an NDO for setting specific values to specific attributes.
> >>>>>>> There will be a separate patch that extends iproute2 to call 
> >>>>>>> the new NDO.
> >>>>>> What are these attributes? Can you give some examples. I'm 
> >>>>>> asking because there is a plan to pass generic attributes to 
> >>>>>> switch ports replacing current specific 
> >>>>>> ndo_switch_port_stp_update. In this case, bridge is setting that attribute.
> >>>>>>
> >>>>>> Is there need to set something directly from userspace or does 
> >>>>>> it make rather sense to use involved bridge/ovs/bond ? I think 
> >>>>>> that both will be needed.
> >>>>> +1
> >>>>>
> >>>>> I think for many attributes it would be best to have both. The 
> >>>>> in kernel callers and netlink userspace can use the same driver ndo_ops.
> >>>>>
> >>>>> But then we don't _require_ any specific bridge/ovs/etc module.
> >>>>> And we may have some attributes that are not specific to any 
> >>>>> existing software module. I'm guessing Marco has some examples 
> >>>>> of
> these.
> >>>>>
> >>>>> [...]
> >>>>>
> >>>>>
> >>>>> --
> >>>>> John Fastabend         Intel Corporation
> >>>> We do have a need to configure the attributes directly from 
> >>>> user-space
> and I have identified the tool to do that in iproute2.
> >>>>
> >>>> An example of attributes are:
> >>>> * enabling/disabling of learning of source addresses on a given 
> >>>> port (you can imagine the attribute called LEARNING for example);
> >>>> * internal loopback control (i.e. LOOPBACK) which will control 
> >>>> how the flow of traffic behaves from the switch fabric towards an 
> >>>> egress port;
> >>>> * flooding for broadcast/multicast/unicast type of packets (i.e.
> >>>> BFLOODING, MFLOODING, UFLOODING);
> >>>>
> >>>> Some attributes would be of the type enabled/disabled while other 
> >>>> will
> allow specific values to allow the user to configure different 
> behaviours of that feature on that particular port on that platform.
> >>>>
> >>>> One thing to mention - as John stated as well - there might be 
> >>>> some
> attributes that are not specific to any software module but rather 
> have to do with the actual hardware/platform to configure.
> >>>>
> >>>> I hope this clarifies some points.
> >>> It does. Makes sense. We need to expose this attr set/get for both 
> >>> in-kernel and userspace use cases.
> >>>
> >>> Please adjust you patch for this. Also, as a second patch, it 
> >>> would be great if you can convert ndo_switch_port_stp_update to 
> >>> this new
> ndo.
> >> Why are we exposing generic switch attribute get/set from userspace 
> >> ?. We already have specific attributes for learning/flooding which 
> >> can be extended further.
> > Yes, but that is for PF_BRIDGE and bridge specific attributes. There 
> > might be another generic attrs, no?
> I cant think of any. And plus, the whole point of switchdev l2 
> offloads was to map these to existing bridge attributes. And we 
> already have a match for some of the attributes that marco wants.
> 
> If there is a need for such attributes, i don't see why it is needed 
> for switch devices only.
> It is needed for any hw (nics etc). And, a precedence to this is to do 
> it via ethtool.
> 
> Having said that, am sure we will find a need for this in the future.
> And having a netlink attribute always helps.
> 
> Today, it seems like these can be mapped to existing attributes that 
> are settable via ndo_bridge_setlink/getlink.
> 
> >
> >> And for in kernel api....i had a sample patch in my RFC series 
> >> (Which i was going to resubmit, until it was decided that we will 
> >> use existing api around
> >> ndo_bridge_setlink/ndo_bridge_getlink):
> >> http://www.spinics.net/lists/netdev/msg305473.html
> > Yes, this might become handy for other generic non-bridge attrs.
> >
> >> Thanks,
> >> Roopa
> >>
> >>
> >>

The list I provided is only a subset of the attributes we will need to be exposed. I do have more and I'm sure that more will come in the future. As I mentioned in few posts earlier, some attributes are generic and some are not. 

I did not consider ethtool for few reasons but the main one is that I was under the impression that netlink was preferred in many circumstances over the ethotool_ops. Plus, all the cases I have identified so far are going to nicely fit into the setlink set of operations.

--
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
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists