Re: [PATCH net-next v3 19/26] switchdev: add new swdev_port_bridge_getlink

[Scott Feldman <sfeldma@gmail.com>]

On Sat, Apr 4, 2015 at 9:56 AM, Arad, Ronen <ronen.arad@intel.com> wrote:
>
>
>>-----Original Message-----
>>From: sfeldma@gmail.com [mailto:sfeldma@gmail.com]
>>Sent: Thursday, April 02, 2015 1:10 AM
>>To: netdev@vger.kernel.org
>>Cc: jiri@resnulli.us; roopa@cumulusnetworks.com; linux@roeck-us.net;
>>f.fainelli@gmail.com; Samudrala, Sridhar; Arad, Ronen
>>Subject: [PATCH net-next v3 19/26] switchdev: add new
>>swdev_port_bridge_getlink
>>
>>From: Scott Feldman <sfeldma@gmail.com>
>>
>>Like bridge_setlink, add swdev wrapper to handle bridge_getlink and call into
>>port driver to get port attrs.  For now, only BR_LEARNING and BR_LEARNING_SYNC
>>are returned.  To add more, we'll probably want to break away from
>>ndo_dflt_bridge_getlink() and build the netlink skb directly in the swdev
>>code.

[cut]

>
> swdev_port_bridge_getlink and the function it wraps
> ndo_dflt_bridge_getlink are only useful when all you need is to return
> a set of brport attributes.
> When a switchdev driver supports VLAN filtering without being enslaved
> to a bridge this no longer works. ndo_dflt_bridge_getlink will end up in
> a netlink RTM_NEWLINK message without the VLAN filtering info which is
> maintained internally by the switchdev driver.
> The driver will have to duplicate the code in ndo_dflt_bridge_getlink in
> order to return a single RTM_NEWLINK message per port.
> Can we break ndo_dflt_bridge_getlink to components that could be used
> by such driver?
> It would be useful to have one function that could fill the
> IFLA_PROTINFO and another one for the IFLA_AF_SPEC.

I couldn't find a consumer of the RTM_NEWLINK msg returned from
RTM_GETLINK that wants the VLAN part of afspec.  Did I miss one?

-scott