Hi Stephen,
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Wednesday, February 3, 2016 11:36 AM
> To: Lu, Wenzhuo
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 2/7] lib/librte_ether: support l2 tunnel
> config
>
> On Tue, 2 Feb 2016 14:57:00 +0800
> Wenzhuo Lu <wenzhuo.lu at intel.com> wrote:
>
> > +/**
> > + * l2 tunnel configuration.
> > + */
> > +struct rte_eth_l2_tunnel {
> > + enum rte_eth_l2_tunnel_type l2_tunnel_type;
> > + uint16_t ether_type;
> > +};
>
> Building an API with an indirect (structure) parameter with only two elements
> seems like overkill. If you are building it to support future features, that
> won't
> work because it will break ABI.
>
> Why not just?
>
> int
> rte_eth_dev_etag_enable(uint8_t port_id, uint16_t ether_type)
I'm trying to make the rte ops can support future features, because there're
some similar technology 802.1Qbg, 802.1Qbh, 802.1BR, VN-tag.
And after applying all the patches in this patch set, the struct
rte_eth_l2_tunnel will be like this,
struct rte_eth_l2_tunnel {
enum rte_eth_l2_tunnel_type l2_tunnel_type;
uint16_t ether_type;
uint32_t tunnel_id; /* port tag id for e-tag */
};
If we want to support a new type of tunnel which can be described by ether type
and tunnel id, we need not to extend this structure. We
only need to add new value for l2_tunnel_type. I think it's not an ABI change.
And I think using a l2 tunnel to cover all these tunnels can make interface
simple :)