[dpdk-dev] [PATCH v2 2/7] lib/librte_ether: support l2 tunnel config

Lu, Wenzhuo wenzhuo.lu at intel.com
Wed Feb 3 09:08:16 CET 2016


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 :)



More information about the dev mailing list