[libnl][netlink] bridge support

Nicolas Planel nicolas.planel at enovance.com
Fri Oct 4 18:03:12 EDT 2013



   Hi All, Thomas,


1/

I am currently working to implements python binding support on libnl.
Ultimately our goal is to implement an openstack L2 agent to use libnl API calls instead of fork()/execve() brctl commands.


2/ 
Basically libnl internal state didn't reflect the reality

 
So I have done some basic testing and see that the libnl is not supporting already instantiated bridge device.
For example :

# brctl addbr foo

# run testing-bridge.c

	int r = rtnl_link_get_kernel(sk, 0, intf, &link);
	int is_bridge = rtnl_link_is_bridge(link);

// rtnl_link_bridge_has_ext_info() response false too, see below


is_bridge is always false 
   as link->l_af_ops is NULL
   basically because ifi->ifi_family == UNSPEC

In this case link_msg_parser() cannot call af_lookup_and_alloc() with right family value, and after nlmsg_parse()


3/ Workaround/Solution ?

 3.1/ Implements link_info_ops for bridge too
      add io_parse() callback
         override the link->l_family
         set link->l_af_ops
      
      move callback() from af_ops to link_info_ops

      => May conflicts with vlan/vxlan ....

 3.2/ On kernel side : set the ifi_family for every link based on flags (for bridge dev->flags & ...BRIDGE...)

      => very ugly

 3.3/ On link_msg_parser()

      af_lookup_and_alloc()
      ...
      nlmsg_parse()
      ...
      if (tb[IFLA_LINKINFO]) {
        ...
        kind = ...
        ...
	if (!af_ops && (af_ops = af_lookup_and_alloc(link, kind))) {
		link->l_af_ops = af_ops;
	}
      }



Let me know what do you think about this and how we can go forward with this.


Regards,

Nicolas PLANEL








More information about the libnl mailing list