[PATCH 3/3] bridge: Add support for VLANs

David Ahern dsa at cumulusnetworks.com
Wed Nov 25 12:17:51 PST 2015


On 11/25/15 10:11 AM, David Ahern wrote:
> On 11/25/15 8:47 AM, Tobias Jungel wrote:
>>> diff --git a/include/netlink/route/link/bridge.h
>>> b/include/netlink/route/link/bridge.h
>>> index 16a4505f8b74..5dc6a367595c 100644
>>> --- a/include/netlink/route/link/bridge.h
>>> +++ b/include/netlink/route/link/bridge.h
>>> @@ -19,6 +19,22 @@
>>>   extern "C" {
>>>   #endif
>>>
>>> +/* maximum vlan id */
>>> +#define VLAN_N_VID        4096
>>> +
>>> +#define BITS_PER_BYTE        8
>>> +#define BITS_PER_LONG        (BITS_PER_BYTE *
>>> sizeof(unsigned long))
>>> +#define DIV_ROUND_UP(n,d)    (((n) + (d) - 1) / (d))
>>> +#define BITS_TO_LONGS(nr)    DIV_ROUND_UP(nr, BITS_PER_LONG)
>>> +#define BR_VLAN_BITMAP_LEN    BITS_TO_LONGS(VLAN_N_VID)
>>> +
>>> +struct bridge_vlan
>>> +{
>>> +    uint16_t                pvid;
>>> +    unsigned long           vlan_bitmap[BR_VLAN_BITMAP_LEN];
>>> +    unsigned long           untagged_bitmap[BR_VLAN_BITMAP_LEN];
>>> +};
>>> +
>>
>> Fine with me, even if I personnaly would rather opt for the kernels
>> compressed data structure, but this is probably just a matter of taste.
>
> A bitmap has better lookup qualities as well as a consistent memory
> footprint. No idea why the kernel implementation is a list. Roopa?
>

Ok, that was a stupid question. The kernel is tracking way more than vid 
and flags. bridge_vlan_info is just a temp struct for passing that data 
to userspace. Hence using a bitmap versus an array of bridge_vlan_info 
is userspace design choice.




More information about the libnl mailing list