> -----Original Message----- > From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Jiri Pirko > Sent: Thursday, December 11, 2014 1:09 PM > To: Varlese, Marco > Cc: John Fastabend; net...@vger.kernel.org; > step...@networkplumber.org; Fastabend, John R; > ro...@cumulusnetworks.com; sfel...@gmail.com; linux- > ker...@vger.kernel.org > Subject: Re: [RFC PATCH net-next 1/1] net: Support for switch port > configuration > > Thu, Dec 11, 2014 at 01:02:36PM CET, marco.varl...@intel.com wrote: > >> -----Original Message----- > >> From: Jiri Pirko [mailto:j...@resnulli.us] > >> Sent: Thursday, December 11, 2014 11:01 AM > >> To: Varlese, Marco > >> Cc: John Fastabend; net...@vger.kernel.org; > >> step...@networkplumber.org; Fastabend, John R; > >> ro...@cumulusnetworks.com; sfel...@gmail.com; linux- > >> ker...@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.varl...@intel.com wrote: > >> >> -----Original Message----- > >> >> From: John Fastabend [mailto:john.fastab...@gmail.com] > >> >> Sent: Wednesday, December 10, 2014 5:04 PM > >> >> To: Jiri Pirko > >> >> Cc: Varlese, Marco; net...@vger.kernel.org; > >> >> step...@networkplumber.org; Fastabend, John R; > >> >> ro...@cumulusnetworks.com; sfel...@gmail.com; linux- > >> >> ker...@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.varl...@intel.com > wrote: > >> >> >> From: Marco Varlese <marco.varl...@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? > > I believe that it is preferred to have both get and set exposed via ndo and > netlink. It can be exposed via sysfs as well, but it is "nice to have" > not "must have" >
I'll add the get ndo to my patch now. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
