Re: [PATCH net-next RFC v2 2/3] ipv4: add support for light weight tunnel encap attributes

[roopa <roopa@cumulusnetworks.com>]

On 6/19/15, 10:17 AM, Robert Shearman wrote:
>
> No need for that - use the example of how RTA_MULTIPATH is used for 
> ipv4/ipv6:
>
> +----------------------+
> | RTA_MULTIPATH        |
> +----------------------+
> | +------------------+ |
> | | struct rtnexthop | |
> | +------------------+ |
> | | RTA_GATEWAY, etc.| |
> | +------------------+ |
> +----------------------+
>
> You could do similar for RTA_ENCAP where the type is stored in the 
> data prior to the nested attributes starting. E.g.:
>
> +----------------------+
> | RTA_ENCAP            |
> +----------------------+
> | +------------------+ |
> | | struct rtencap   | |
> | +------------------+ |
> | | MPLS_IPTUNNEL_DST| |
> | +------------------+ |
> +----------------------+
>
> struct rtencap {
>     __u16 rte_type;
> };
I did think about that...but today the rtnextop seems like it was 
written a struct initially and then extended with attributes only 
because the struct could not be extended (I maybe wrong). But half the 
fields are in a struct and the others are attributes. It gets confusing.
And i was trying to avoid that.