All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Feldman <sfeldma@gmail.com>
To: roopa <roopa@cumulusnetworks.com>
Cc: "Jiří Pírko" <jiri@resnulli.us>, Netdev <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH net-next] rocker: check for BRIDGE_FLAGS_SELF in bridge setlink handler
Date: Wed, 4 Mar 2015 08:24:33 -0800	[thread overview]
Message-ID: <CAE4R7bC_okmfXSSYe3YKoHwKWOjPO1xju06LsSvNgZzsymBqCw@mail.gmail.com> (raw)
In-Reply-To: <54F6C788.2010201@cumulusnetworks.com>

On Wed, Mar 4, 2015 at 12:51 AM, roopa <roopa@cumulusnetworks.com> wrote:
> On 3/3/15, 11:02 PM, Scott Feldman wrote:
>>
>> On Tue, Mar 3, 2015 at 4:15 PM,  <roopa@cumulusnetworks.com> wrote:
>>>
>>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>>
>>> With the recent addition of the NETIF_F_HW_SWITCH_OFFLOAD flag
>>> on rocker ports, the second command (bridge link set) below will turn off
>>> learning in the rocker hw (Scott/Jiri, need some confirmation from
>>> you that this is indeed a problem and if the below patch is ok).
>>>
>>> ip link set dev swp1 master br0
>>> bridge link set dev swp1 learning off master
>>> bridge link set dev swp1 learning_sync on self
>>>
>>> This patch fixes rocker to ignore learning setting when 'master'
>>> is set. This makes it possible to set/unset learning in kernel and bridge
>>> driver independently.
>>>
>>> The below command will continue to set learning on in both kernel and
>>> rocker
>>> hw:
>>> bridge link set dev swp1 learning on
>>>
>>> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
>>> ---
>>>   drivers/net/ethernet/rocker/rocker.c |    3 +++
>>>   1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/net/ethernet/rocker/rocker.c
>>> b/drivers/net/ethernet/rocker/rocker.c
>>> index e5a15a4..d7c31d2 100644
>>> --- a/drivers/net/ethernet/rocker/rocker.c
>>> +++ b/drivers/net/ethernet/rocker/rocker.c
>>> @@ -3769,6 +3769,9 @@ static int rocker_port_bridge_setlink(struct
>>> net_device *dev,
>>>          struct nlattr *attr;
>>>          int err;
>>>
>>> +       if (flags && !(flags & BRIDGE_FLAGS_SELF))
>>> +               return 0;
>>> +
>>>          protinfo = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg),
>>>                                     IFLA_PROTINFO);
>>>          if (protinfo) {
>>
>>
>> NACK on this patch.  This is the problem with netlink creeping into
>> ndo ops: it's too tempting to push work-arounds down to driver.
>
> netlink has already crept into the driver. You do parse the netlink message
> right below.
> The patch actually does not touch the message. It is just using one of the
> args already passed to the handler.
>
>> In this case, you're making the driver check to see if it's SELF when
>> it's already SELF by definition.
>>
>> Rocker setlink wasn't broken prior to the NETIF_F_HW_SWITCH_OFFLOAD
>> patches.
>>   Now it is,
>
> sure, I can submit a patch to remove the flag on rocker ports if thats what
> you prefer.

I don't want that either.  I haven't figured out why I need
NETIF_F_HW_SWITCH_OFFLOAD at the moment, but if this is supposed to be
a flag that's set on switchdev driver ports, then it should be set on
rocker ports.


>> but this isn't the right fix.
>>
>> Can we revisit this so these two commands only hit MASTER:
>>
>>     bridge link set dev swp1 learning on
>>     bridge link set dev swp1 learning on master
>>
>> And this one hits SELF:
>>
>>      bridge link set dev swp1 learning on self
>
>
> For the above to work you just need to remove the feature flag in the driver
> (i can submit a patch).
>
> The reason why it is useful to have it the way it currently is:
>
> the setlink request does not always only contain the 'learning' flag.
> It handles vlans too. I dont see rocker parsing vlans yet ie IFLA_AF_SPEC
> (or did i miss it ?)

Yes, you missed it.  See
br_setlink->br_afspec->br_vlan_info->nbp_vlan_add->__vlan_add->__vlan_vid_add

The bridge is already calling into the driver to tell it which vlans
are on which port.

This works when doing vlans outside of bridge driver also.  One
interface for both bridge and stand-alone vlans.

I see no reason to parse netlink in the driver's setlink/dellink other
than getting the SELF flags.

  reply	other threads:[~2015-03-04 16:24 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-04  0:15 [PATCH net-next] rocker: check for BRIDGE_FLAGS_SELF in bridge setlink handler roopa
2015-03-04  4:15 ` John Fastabend
2015-03-04  7:02 ` Scott Feldman
2015-03-04  8:51   ` roopa
2015-03-04 16:24     ` Scott Feldman [this message]
2015-03-05  0:31       ` roopa
2015-03-05  8:02     ` Jiri Pirko
2015-03-05 14:55       ` roopa
2015-03-05 20:06         ` Scott Feldman
2015-03-05 20:43           ` roopa
2015-03-05 21:40             ` roopa
2015-03-06  9:52             ` Scott Feldman
2015-03-08 14:19               ` roopa
2015-03-08 23:17                 ` Scott Feldman
2015-03-09  0:20                   ` roopa
     [not found]                   ` <CAJieiUhHdXOZjWkb4s_GviLwzq5Gct-1o8xv8b-JeM46S4e-dg@mail.gmail.com>
2015-03-09  6:40                     ` Jiri Pirko
2015-03-09 15:59                       ` Arad, Ronen
2015-03-09 16:07                         ` Jiri Pirko
2015-03-10  0:51                           ` Arad, Ronen
2015-03-10  6:39                             ` Jiri Pirko
2015-03-10  8:02                               ` Arad, Ronen
2015-03-10  8:28                                 ` Jiri Pirko
2015-03-16 22:01                                   ` John Fastabend
2015-03-17  7:00                                     ` Jiri Pirko
2015-03-17 14:31                                       ` John Fastabend
2015-03-17 20:27                                         ` roopa
2015-03-18  0:16                                           ` John Fastabend
2015-03-18  6:29                                             ` roopa
2015-03-18 15:24                                               ` John Fastabend
2015-03-18 16:55                                                 ` John Fastabend
2015-03-19  5:03                                                 ` roopa
2015-03-19  5:49                                                 ` Scott Feldman
2015-03-19 13:29                                                   ` roopa
2015-03-19 13:59                                                     ` John Fastabend
     [not found]                         ` <CAJieiUhcdfGitY7rbG11Vt_Beemz8dy3=gKtvbyVLS8O0DkgNw@mail.gmail.com>
2015-03-09 23:23                           ` Roopa Prabhu
2015-03-05  8:36 ` Jiri Pirko
2015-03-05 15:01   ` roopa
2015-03-05 15:09     ` roopa

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=CAE4R7bC_okmfXSSYe3YKoHwKWOjPO1xju06LsSvNgZzsymBqCw@mail.gmail.com \
    --to=sfeldma@gmail.com \
    --cc=davem@davemloft.net \
    --cc=jiri@resnulli.us \
    --cc=netdev@vger.kernel.org \
    --cc=roopa@cumulusnetworks.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.