Support for other netlink sockets / packages

[stv0g]

I am currently considering to use the google/nftables package in my existing project Gont which already heavily depends on vishvananda/netlink.

To avoid code duplication and overhead, I would like to use a single netlink socket in my code.

Can we extend google/nftables to rely on a netlink socket interface to make it comaptible with other netlink packages?

[stapelberg]

mdlayher/netlink is a low-level netlink library, vishvananda/netlink is a high-level netlink library. They are not replacements for each other.

Overall, I don’t think pulling these 2 libraries into your program’s transitive dependency closure should result in any issue. If you think otherwise, please describe in detail what the problem is.

[stv0g]

Hi Michael,

I am aware the that vishvandas package is a high level library. However, it’s also contains a low level package to manage no sockets and messages:

https://github.com/vishvananda/netlink/tree/master/nl

For my usecase in Gont, I maintain several netlink sockets belonging to different network namespaces within a single process. Basically, every simulated network node is represented by a dedicated network namespace. And the more complex the user defined topology gets, the more netlink sockets I need to open.

Opening the netlink socket in a foreign network namespace requires me to lock the ago routine which opens the socket to a Linux thread. If possible, I would like to avoid locking the Go routines as much as possible, as it limits the Go schedulers abilities.

After some more analysis, I have realized that vishvandas nl package creates a dedicated netlink socket for each netlink family. So using their lower layer netlink code would not reduce the number of open netlink sockets in my process.

However it would allow me to the handle the netlink socket indepedently from nftables.Conn.Flush() and therefore limit the number of opened sockets and therefore locking of Go routines.

Cheers, Steffen

[stapelberg]

Thanks for elaborating!

It sounds like the presence of multiple netlink libraries is not a problem in your binary, as long as you can choose which one is being used.

Would it work to add a new entrypoint to the nftables package that allows users to optionally “bring their own netlink socket”? Maybe this is what you meant all along. I wouldn’t mind such a change (but I’m not necessarily looking to replace our current netlink usage with a different package).

[stv0g]

It sounds like the presence of multiple netlink libraries is not a problem in your binary, as long as you can choose which one is being used.

Yes, exactly :)

I am currently looking into how such an interface could look like. I guess in the simplest case its just a net.Conn. This would leave all the netlink message construction and parsing to mdlayhers netlink library and simply use an existing socket.

E.g.

func (c *Conn) FlushToConn(c *net.Conn) error {

}

Or we could introduce an interface which abstracts netlink.Conn. But this seems to more invasive as it would also require interfaces for the netlink messages.