Common netlink parsing?
While adding error handling to tap device, I noticed we already have two places rolling their own netlink message handling (tap and mlx5) and now with proposed IF proxy there is a third.
Netlink is non-trivial and easy to get wrong and doing error handling also requires work. There should be a common library for this.
My preference would be to use pre-existing code (libmnl) but the DPDK maintainers seem to have an aversion to taking a dependency on any external code and reinvent everything (see RCU etc).
25/04/2020 21:24, Stephen Hemminger:
Quoted 10 lines
While adding error handling to tap device, I noticed we already have two places rolling their own netlink message handling (tap and mlx5) and now with proposed IF proxy there is a third.
Netlink is non-trivial and easy to get wrong and doing error handling also requires work. There should be a common library for this.
My preference would be to use pre-existing code (libmnl) but the DPDK maintainers seem to have an aversion to taking a dependency on any external code and reinvent everything (see RCU etc).
We should avoid reinventing wheels.
About RCU, I think it was said no library meets the same requirements. Honnappa, any comment?
About libmnl, it was used in mlx5 some time ago.
It has been removed when it was thought it is not required anymore. Maybe you could demonstrate libmnl benefit by integrating it with the tap PMD first.
Quoted 6 lines · Stephen Hemminger
While adding error handling to tap device, I noticed we already have two places rolling their own netlink message handling (tap and mlx5) and now with proposed IF proxy there is a third.
Netlink is non-trivial and easy to get wrong and doing error handling also requires work. There should be a common library for this.
Right. I was looking at this but eventually decided to go with implementation using macros defined in system headers. However some of these macros are there with "backward compatibility" notes e.g.:
/* backwards compatibility for userspace */
#define IFLA_RTA(r) ((struct rtattr*)(((char*)(r)) + ... #define IFLA_PAYLOAD(n) NLMSG_PAYLOAD(n,sizeof(struct ifinfomsg))
So I'm not that sure what will be their fate (possible removal?).
There is some considerable overlap between these macros and libmnl when it comes to handling of messages/attributes, so I decided to go with macros instead of introducing external dependency. However I'm open to change if that would be the general consensus.
With regards
Andrzej Ostruszka