[dpdk-dev] Common netlink parsing?

[dpdk-dev] Common netlink parsing?

[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.

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

Re: [dpdk-dev] Common netlink parsing?

[Thomas Monjalon]

25/04/2020 21:24, 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.
> 
> 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.

Re: [dpdk-dev] Common netlink parsing?

[Andrzej Ostruszka [C]]

On 25/04/2020 21:24, Stephen Hemminger wrote:
> 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