[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54827641.9040208@gmail.com>
Date: Fri, 05 Dec 2014 19:21:37 -0800
From: John Fastabend <john.fastabend@...il.com>
To: "Arad, Ronen" <ronen.arad@...el.com>
CC: Netdev <netdev@...r.kernel.org>,
Roopa Prabhu <roopa@...ulusnetworks.com>,
Scott Feldman <sfeldma@...il.com>,
Jirí Pírko <jiri@...nulli.us>,
Jamal Hadi Salim <jhs@...atatu.com>,
Benjamin LaHaise <bcrl@...ck.org>, Thomas Graf <tgraf@...g.ch>,
"stephen@...workplumber.org" <stephen@...workplumber.org>,
John Linville <linville@...driver.com>,
"nhorman@...driver.com" <nhorman@...driver.com>,
Nicolas Dichtel <nicolas.dichtel@...nd.com>,
"vyasevic@...hat.com" <vyasevic@...hat.com>,
Florian Fainelli <f.fainelli@...il.com>,
"buytenh@...tstofly.org" <buytenh@...tstofly.org>,
Aviad Raveh <aviadr@...lanox.com>,
"David S. Miller" <davem@...emloft.net>,
"shm@...ulusnetworks.com" <shm@...ulusnetworks.com>,
Andy Gospodarek <gospo@...ulusnetworks.com>
Subject: Re: [PATCH 2/3] bridge: offload bridge port attributes to switch
asic if feature flag set
On 12/05/2014 07:06 PM, Arad, Ronen wrote:
>
>
>> -----Original Message-----
>> From: John Fastabend [mailto:john.fastabend@...il.com]
>> Sent: Friday, December 05, 2014 6:46 PM
>> To: Arad, Ronen
>> Cc: Roopa Prabhu; Scott Feldman; Netdev; Jirí Pírko; Jamal Hadi Salim;
>> Benjamin LaHaise; Thomas Graf; stephen@...workplumber.org; John
>> Linville; nhorman@...driver.com; Nicolas Dichtel; vyasevic@...hat.com;
>> Florian Fainelli; buytenh@...tstofly.org; Aviad Raveh; David S. Miller;
>> shm@...ulusnetworks.com; Andy Gospodarek
>> Subject: Re: [PATCH 2/3] bridge: offload bridge port attributes to switch asic
>> if feature flag set
>>
>> On 12/05/2014 05:04 PM, Arad, Ronen wrote:
>>> I have another case of propagation which is not covered by the proposed
>> patch.
>>> A recent patch introduced default_pvid attribute for a bridge (so far
>> supported only via sysfs and not via netlink).
>>> When a port joins a bridge, it inherits a PVID from the default_pvid of the
>> bridge.
>>> The bridge driver propagates that to the newly created net_bridge_port.
>> This is done in br_vlan.c:
>>>
>>> int nbp_vlan_init(struct net_bridge_port *p) {
>>> int rc = 0;
>>>
>>> if (p->br->default_pvid) {
>>> rc = nbp_vlan_add(p, p->br->default_pvid,
>>> BRIDGE_VLAN_INFO_PVID |
>>> BRIDGE_VLAN_INFO_UNTAGGED);
>>> }
>>>
>>> return rc;
>>> }
>>>
>>> When L2 switching is offloaded to the HW, this PVID setting need to be
>> propagated. However, it does not come via ndo_bridge_setlink. The
>> proposed propagation at br_setlink or an up level one at rtnetlink are not
>> capable of handling this case.
>>> One possible way for handling that is to replace the call to
>>> nbp_vlan_add with a call to a new function let's say int
>>> br_propagate_vlan_add(struct net_bridge_port *port, u16 vid, u16 flags)
>> This function will compose a netlink message with VLAN filtering information
>> (i.e. AF_SPEC with VLAN_INFO) and call br_setlink - leveraging the offload
>> support proposed by Roopa.
>>>
>>
>> No, we shouldn't be crafting netlink messages in the kernel just re-inject
>> them into an interface. Really the setlink/dellink interface should be cleaned
>> up so that it no longer consumes raw netlink messages.
>>
>> Then either (a) add another parameter to the setlink ops or (b) create a new
>> op for it.
>>
>> I think cleaning up the setlink/dellink hooks is on the TBD list already.
>>
> This would be a lot cleaner even though there could be loss of
> flexibility. Fixed argument interface will not be extensible.
> Will the non-Netlink based driver setlink/dellink hooks be TLV based
> or take a pointer to a single struct with some indication of what is
> actually populated there?
There shouldn't be any loss of flexibility, we can add new attributes
and new ops as we need them.
I had assumed it would be basic structures and additional ndo ops as
needed but I've not coded anything up.
>>> If this is an acceptable course of action, I could work on such patch.
>>>
>>>
>>
>> [...]
>>
>> Thanks,
>> John
>>
>> --
>> John Fastabend Intel Corporation
--
John Fastabend Intel Corporation
--
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
Powered by blists - more mailing lists