Messages in this thread | | | From | "Varlese, Marco" <> | Subject | RE: [RFC PATCH net-next 1/1] net: Support for switch port configuration | Date | Thu, 11 Dec 2014 12:02:36 +0000 |
| |
> -----Original Message----- > From: Jiri Pirko [mailto:jiri@resnulli.us] > Sent: Thursday, December 11, 2014 11:01 AM > To: Varlese, Marco > Cc: John Fastabend; netdev@vger.kernel.org; > stephen@networkplumber.org; Fastabend, John R; > roopa@cumulusnetworks.com; sfeldma@gmail.com; linux- > kernel@vger.kernel.org > Subject: Re: [RFC PATCH net-next 1/1] net: Support for switch port > configuration > > Thu, Dec 11, 2014 at 10:59:42AM CET, marco.varlese@intel.com wrote: > >> -----Original Message----- > >> From: John Fastabend [mailto:john.fastabend@gmail.com] > >> Sent: Wednesday, December 10, 2014 5:04 PM > >> To: Jiri Pirko > >> Cc: Varlese, Marco; netdev@vger.kernel.org; > >> stephen@networkplumber.org; Fastabend, John R; > >> roopa@cumulusnetworks.com; sfeldma@gmail.com; linux- > >> kernel@vger.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@intel.com wrote: > >> >> From: Marco Varlese <marco.varlese@intel.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. > > Thanks. > >
I was thinking of leaving the get side of things implemented via sysfs rather than implementing an NDO for it. Would this not be appropriate?
- - - Marco Varlese
| |