From: John Fastabend <john.r.fastabend@intel.com>
To: Roopa Prabhu <roopa@cumulusnetworks.com>,
"Varlese, Marco" <marco.varlese@intel.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Thomas Graf <tgraf@suug.ch>, Jiri Pirko <jiri@resnulli.us>,
"sfeldma@gmail.com" <sfeldma@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration
Date: Thu, 18 Dec 2014 11:21:30 -0800 [thread overview]
Message-ID: <5493293A.2000802@intel.com> (raw)
In-Reply-To: <54931969.7040209@cumulusnetworks.com>
On 12/18/2014 10:14 AM, Roopa Prabhu wrote:
> On 12/18/14, 10:02 AM, Varlese, Marco wrote:
>> Removed unnecessary content for ease of reading...
>>
>>>>>>>> +/* Switch Port Attributes section */
>>>>>>>> +
>>>>>>>> +enum {
>>>>>>>> + IFLA_ATTR_UNSPEC,
>>>>>>>> + IFLA_ATTR_LEARNING,
>>>>>>> Any reason you want learning here ?. This is covered as part of
>>>>>>> the bridge setlink attributes.
>>>>>>>
>>>>>> Yes, because the user may _not_ want to go through a bridge
>>>>>> interface
>>>>> necessarily.
>>>>> But, the bridge setlink/getlink interface was changed to accommodate
>>> 'self'
>>>>> for exactly such cases.
>>>>> I kind of understand your case for the other attributes (these are
>>>>> per port settings that switch asics provide).
>>>>>
>>>>> However, i don't understand the reason to pull in bridge attributes here.
>>>>>
>>>> Maybe, I am missing something so you might help. The learning attribute -
>>> in my case - it is like all other attributes: a port attribute (as you said, port
>>> settings that the switch provides per port).
>>>> So, what I was saying is "why the user shall go through a bridge to configure
>>> the learning attribute"? From my perspective, it is as any other attribute and
>>> as such configurable on the port.
>>>
>>> Thinking about this some more, i don't see why any of these attributes
>>> (except loopback. I dont understand the loopback attribute) cant be part of
>>> the birdge port attributes.
>>>
>>> With this we will end up adding l2 attributes in two places: the general link
>>> attributes and bridge attributes.
>>>
>>> And since we have gone down the path of using ndo_bridge_setlink/getlink
>>> with 'self'....we should stick to that for all l2 attributes.
>>>
>>> The idea of overloading ndo_bridge_set/getlink, was to have the same set of
>>> attributes but support both cases where the user wants to go through the
>>> bridge driver or directly to the switch port driver. So, you are not really going
>>> through the bridge driver if you use 'self' and ndo_bridge_setlink/getlink.
>>>
>> Roopa, one of the comments I got from Thomas Graf on my v1 patch
>> was that your patch and mine were supplementary ("I think Roopa's
>> patches are supplementary. Not all switchdev users will be backed
>> with a Linux Bridge. I therefore welcome your patches very
>> much")... I also understood by others that the patch made sense for
>> the same reason. I simply do not understand why these attributes
>> (and maybe others in the future) could not be configured directly
>> on a standard port but have to go through a bridge.
>>
> ok, i am very confused in that case. The whole moving of bridge
> attributes from the bridge driver to rtnetlink.c was to make the
> bridge attributes accessible to any driver who wants to set l2/bridge
> attributes on their switch ports. So, its unclear to me why we are
> doing this parallel thing again. This move to rtnetlink.c was done
> during the recent rocker support. so, maybe scott/jiri can elaborate
> more.
Not sure if this will add to the confusion or help. But you do not
need to have the bridge.ko loaded or netdev's attached to a bridge
to use the setlink/getlink ndo ops and netlink messages.
This was intentionally done. Its already used with NIC devices to
configure embedded bridge settings such as VEB/VEPA.
I think I'm just repeating Roopa though.
next prev parent reply other threads:[~2014-12-18 19:21 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-18 11:29 [RFC PATCH net-next v2 1/1] net: Support for switch port configuration Varlese, Marco
2014-12-18 11:41 ` Thomas Graf
2014-12-18 15:20 ` Varlese, Marco
2014-12-18 14:44 ` Roopa Prabhu
2014-12-18 14:55 ` Varlese, Marco
2014-12-18 15:16 ` Roopa Prabhu
2014-12-18 17:25 ` Varlese, Marco
2014-12-18 17:49 ` Roopa Prabhu
2014-12-18 18:02 ` Varlese, Marco
2014-12-18 18:14 ` Roopa Prabhu
2014-12-18 19:21 ` John Fastabend [this message]
2014-12-18 22:43 ` Arad, Ronen
2014-12-19 8:14 ` Jiri Pirko
2014-12-18 23:07 ` Roopa Prabhu
2014-12-18 23:26 ` Samudrala, Sridhar
2014-12-18 23:48 ` Roopa Prabhu
2014-12-19 5:14 ` B Viswanath
2014-12-19 8:27 ` Jiri Pirko
2014-12-19 9:01 ` B Viswanath
2014-12-19 9:22 ` B Viswanath
2014-12-19 9:35 ` Jiri Pirko
2014-12-19 9:23 ` Jiri Pirko
2014-12-19 9:35 ` B Viswanath
2014-12-19 9:55 ` Jiri Pirko
2014-12-19 10:53 ` B Viswanath
2014-12-19 16:22 ` Roopa Prabhu
2014-12-20 0:57 ` Williams, Kenneth
2014-12-19 14:50 ` Andy Gospodarek
2014-12-19 8:25 ` Jiri Pirko
2014-12-19 0:45 ` Thomas Graf
2014-12-18 15:47 ` Arad, Ronen
2014-12-18 16:14 ` John Fastabend
2014-12-18 17:17 ` Arad, Ronen
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=5493293A.2000802@intel.com \
--to=john.r.fastabend@intel.com \
--cc=jiri@resnulli.us \
--cc=linux-kernel@vger.kernel.org \
--cc=marco.varlese@intel.com \
--cc=netdev@vger.kernel.org \
--cc=roopa@cumulusnetworks.com \
--cc=sfeldma@gmail.com \
--cc=tgraf@suug.ch \
/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).